5 Things That Can Go Wrong with Manual Content Migration

Doing a migration yourself is certainly a good option. Like all other approaches for managing content migration, there are always things that can go wrong with manual content migrations.

If you ask me, there are 7 important ingredients for a successful content migration. These 7 ingredients are:

• Connector to the source system (export)
• Connector to the target system (import)
• A sophisticated migration tool that handles the Extract, Transform and Load process
• A person that is experienced in the chosen migration tool
• Migration experience
• Involvement of business
• A reporting and audit trail

If you have all the 7 ingredients inhouse and your migration is technically quite simple (because you can use the upgrade path of the source for instance, or your source system has very little documents or pages) doing a migration yourself is certainly a good option. But like all other approaches for managing content migration, there are always things that can go wrong with manual content migrations. Here are a few:

PA’s do the job

Project owners will never copy paste content from one system to the other because this work is too simple for them. Instead, they will outsource it to their PA’s. These PA’s lack the knowledge and will make errors as the work is very error-prone. As a result, after the migration metadata will be incorrect and pages or documents appear on the wrong spot in the new system.

Double entry

It causes 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. And this is sometimes forgotten.

Testing can go awry

Because juniors that may lack the necessary experience are responsible for the migration, content can end up in the wrong location on the new system. This leads to excessive costs because your development team can’t test the migration. They don’t know why is content ended up in the wrong place. Is it because of bad metadata or is because of a system error?

Delay

In my view, understanding the source system and the specifics (read exceptions) of that source system is one of the main reasons for migration delays. There is no one that knows the source better than yourselves, so no problem there. But lack of understanding the target system and underestimating learning time is an important reason one for delays.

Writing code

There are development teams that write lines of code to handle (part of) the Extract, Transform and Load process. This should be limited because otherwise, you have to manage the code development as a product instead of one-off code.

--------------------------------------------------------------------------

Content Migration Approaches

Manual migration is one of the scenarios for content migration. Unfortunately, I have hardly ever seen this go right. There are scenarios that can be more appropriate for your situation. Learn about these in our latest white paper.