6 reasons why a cut-and-paste migration is problematic

by Corné van Leuveren, on Mar 12, 2014 1:50:20 PM

Even for those who've been through a web migration before, the announcement of an upcoming migration project can make the palms a little sweaty. They're often complex, involve many parts of the business, and are poorly understood. 

Any immediate way to make the situation easier is seen as an improvement, one of which is cutting out the technical migration issues and simply resorting to a manual migration, AKA cut and paste.

They say work smarter not harder; and certainly cut and paste is easier, but is it smarter?

Perceived benefits

A cut-and-paste migration offers some perceived benefits:

  • No requirement to interface with the source system for extraction.
  • No requirement to interface with the target system for import.
  • No understanding required of the underlying technical architecture of the systems.
  • Option for enrichment via human intuition during migration.

However there are six big issues that come with this approach.

slow1.    Slow

Manual migration offers no benefits from economies of scale and ramping up the number of people doing the job only goes so far. Either you outsource the tedious cut-and-paste work to students paid minimum wage, offshore to a processing company who doesn't understand your brand and message, or tie up your valuable internal resources on this labor-intensive task.

2.    Inflexible

During migration projects it's extremely common to receive a change to the spec which results in content model changes. In a manual migration this means redoing the content already migrated, or accepting it as collateral damage in your new system. In an automated migration this is easily handled by simply reconfiguring the tooling and reloading the content overnight.

3.    Double entry

A manual migration can take weeks or months, during which any content already migrated must be maintained in two systems. All updates, deletes, and creation must be logged and replicated across both systems until the last piece of content is moved and the DNS flipped. The alternative is a long content freeze in which your end users receive few updates. This is not a problem in automated migrations since the tooling is configured and tested for a period of time until the actual migration occurs rapidly and the content is moved.

4.    Little added value

Manual migration doesn't easily facilitate consistent improvement of the content set en masse. By setting specific business rules during the initial phases it's extremely quick and easy to improve the content. Areas such as syntax checking, spell checking, metadata enrichment, keyword and entity detection, schema transformations, and on-the-fly data conversions are all possible in an automated migration.

5.    Single environment

Any well designed system implementation will have a number of environments for Development, Testing, Acceptance, and Production. At different stages they'll all need to be filled with content to fulfill their designed purpose:

  • Development: needs a minimum of content so development teams can test their work in progress.
  • Testing: needs a relatively large set of content so testing teams can test thoroughly and find edge cases.
  • Acceptance: needs a complete or nearly complete set of content for User Acceptance Testing.
  • Production: needs the full set of content.

In an automated migration it's as simple as changing the target system configuration in the tools and unleashing the data stream. To achieve this in a manual migration it's difficult without performing partial migrations to non-prod environments, or pushing the burden to an internal IT and infrastructure department to do database copies.

6.    Relationship loss

Cut-and-paste migrations tend to treat your content purely as pages, when really content is made up of objects such as editorial content, downloads, metadata, and users. All of these objects have interconnected relations. In an automated migration all of these relationships are preserved and reconnected after the individual components have been migrated. In a manual migration each of these connections requires clicking through the system GUI.

Consider the situation where pages link directly to each other in the body field: the manual migrator must create all the pages first then go back then create all the internal links to reference the new pages. In an automated migration resolving these links is a standard part of the process.


6 steps to a successful web content management migration

Topics:Web MigrationContent Migration


Xillio blog

On this blog, you will find more information about Xillio, our products, and market developments.

Subscribe to updates