The advent of a new generation of modern content solutions and the desire of many organizations to cut the number of content systems is driving organizations to look seriously how to update their content management infrastructure. In many cases, modernization goes hand in hand with content migration from on-premise orlegacy ECM systems to a newer content suite, either in the cloud or on-premise.
What are content migration approaches? There are 5 scenarios for content migrations, all having their benefits and issues:
- Do it yourself - Manually
- Do it yourself - Semi-manually
- Do it yourself - Build your own tool
- Having it done - Buy a tool
- Having it done - Outsourced Migration-as-a-Service
Scenario 1: Do it yourself - Manually
There is no one that knows the source better than you. So, if the migration is technically quite simple (because you can use the upgrade path of the ECM system for instance), you have the staff, the knowledge and you have a small number of documents, this is certainly a very good scenario. You can use the systems’ user interface to drag and drop the content.
One caution: Your senior employees will never do the hard work, they will likely outsource it to junior counterparts. As this work is repetitive and tedious, there is a high risk of errors in the process. This is one of the things that can go wrong with manual content migrations.
- Scenario 2: Do it yourself - Semi-manually
Besides the manual migration, you could use a specific end-user based automated migration tool for extracting and importing content to and from the source or target system. Most of these tools offer a migration solution to one specific target system, you mostly see them for file shares to SharePoint or Share-Point to SharePoint.
- One caution: The total licenses fee can become high if many users are needed.
- Scenario 3: Do it yourself - Build your own tool
When organizations have large in-house IT organizations or a history of building their own tools, we often see that migrations are created by building sets of scripts that will do the migration.
- Be careful with the lines of code you are writing. It should be limited otherwise you have to manage the code development as a product instead of one-off code. You don’t want to build your own migration product.
- Scenario 4: Having it done – Buy a tool
Because of the high volume of migrations, there are many software platforms, specifically built for migrations. These platforms are often used by consultancy agencies, specialized in migration and need extended training to use. This is a very common scenario and the advantages are obvious. You have outsourced your headache. You make them responsible. The caution here is: there is a very high chance that you pay for lots and lots of non-value-add extra’s, as non-specialized consultancy agencies are driven by billable hours. In addition, you pay for the software and you need someone who is able to handle the tool. Most consulting firms will tell you they have the experience, but ask tough questions on how regularly they do these migrations, and how many people on the team assigned to you have actually participated in those projects.
- Scenario 5: Having it done – Outsourced Migration-as-a-Service
This scenario has the main benefits of scenario 4 (outsourcing your headache) against potential lower costs. This migration as a service scenario has a lot of potential as it solves one of the main problem points for a migration, i.e. lack of knowledge with the tool to handle with your exceptions.
- In this scenario, you can assume that the person handling the tool does this every day and as such you avoid paying for all the extra training costs. This makes the project budget more predictable and reliable. One caution: be aware that the external party needs to understand your specifics and your source system. Scoping the assignment and making agreements about this is essential to avoid running in RFC processes and thus overrun budget or time.
Whitepaper Content Migration Approaches