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. In this blog, Xillio CEO Rikkert Engels sets out his 7 important ingredients for a successful content migration, as well as defining some of the pitfalls to avoid. 

 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 who is experienced in the chosen migration tool
• Migration experience
• Involvement of business
• A reporting and audit trail

If you have all the 7 ingredients in-house 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 few documents or pages), handling the migration yourself is certainly a viable option.

However, like all other approaches for managing content migration, there are always things that can go wrong with manual content migrations. Here are a few pitfalls:

PAs do the job

Project owners will never copy and paste content from one system to the other because this work is too simple for them. Instead, they will outsource it to their PAs. Yet often these PAs lack 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 will appear in the wrong spot in the new system.

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 is flipped. And this is often forgotten.

Testing can go awry

Because juniors who may lack the necessary experience are often made 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 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. No one knows the source better than yourselves, so no problem there. But a lack of understanding of the target system and underestimating learning time are important reasons 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. Some scenarios can be more appropriate for your situation. Learn about these in our white paper or reach out to speak with one of our experts.