While many of our clients are embracing modern interfaces for new ECM systems, migrating the content from a legacy ECM can often be a difficult effort due to the complexity and cost of a migration. Over the last 21 years, TSG has migrated applications and content for clients from a variety of legacy ECM envrionments (even homegrown solutions). This post will address some of the more common migration complexities and our best practices to reduce the cost and effort for legacy ECM migration.
Reasons why migrating is difficult and some of the ways to reduce risk
- Requirements change – when migrating to an ECM system with a modern interface, clients often see the requirements of the new interface evolve over the course of the project. The migration team must then adapt to the changing requirements to migrate new fields or develop new logic to populate attributes that aren’t in the old system. The best way to adapt to these changes is to use a configurable migration tool, such as OpenMigrate. Doing so will ease the pain of adapting to new requirements by allowing these changes to take place at a configuration layer when possible, instead of writing custom code. For example OpenMigrate provides easy ways to update dates, replace bad attributes values with the correct data, and map old data structures into the modern object models the new ECM system requires.
- Workflows, lifecycles, users, and renditions need to be migrated – our clients have found that it’s not just documents and metadata that must be migrated, but every state that is associated with the documents as well. This can be easy or hard depending on a company’s understanding of their own systems complexity and source system. The tool you use to migrate your documents must be able to migrate these extra pieces. TSG has extensive experience migrating from the most complex environments and if the connector does not already exist, it can be easily created. Even if it is a homegrown solution, many times we will configure a database connector or even against an API layer to pull all required components.
- Speed is a factor – when migrating, there are many ways speed can become an issue. For some clients the consideration is time until the new system is released, but for others the consideration is how many documents per second the migration tool can move.
- For speed of the migration, a migration needs to be multi-threaded to allow the highest throughput the system will allow. Benchmarks from the production servers should always be done when possible to get the best estimate of how long a migration will take.
- When the largest consideration is time until the new system is released, TSG often recommends a delta migration approach over a “big bang” migration. Using a delta approach to move smaller chunks of content at a time lessens the risk associated with moving everything at once and turning the old system off. If system up-time is a worry, the delta migration approach will allow the migration team to migrate during off hours to minimize impact on the business.
- User Training and adoption – Many times the most difficult part of a migration is the one that is most commonly overlooked. Many clients have found when migrating to a new system training users to use the new system is harder than the physical migration itself. Often, users are comfortable with the old system and may not be keen on changing their processes and workflows. TSG’s experience with clients has shown that creating pilot groups to get familiar with the system and provide feedback before the system is “turned on” for everyone is immensely helpful. These pilot users can then act as trainers and ambassadors for the new system to create excitement and help with the transition.
Conclusion
There is a lot to think about when migrating content because every migration presents its own unique challenges and requirements. While it’s not easy, hopefully the above client experiences provide methodologies, tips, and tools that can make the process as accurate and stress-free as possible.
Leave a Reply