Migrating content between disparate ECM systems can be a larger than expected challenge, are you ready?
Enterprises today are often faced with multiple content platforms and repositories without a unifying strategy or technology to make the data actionable. They need the ability to quickly and easily access and repurpose information and make it available through self-service channels.
KENNETH CHIN, VICE PRESIDENT, GARTNER RESEARCH
There are many reasons one may find themselves facing a large content migration between disparate Enterprise Content Management (ECM) systems. Whether it is part of a strategic consolidation effort, result of a recent acquisition or divestiture, or simply upgrading to newer infrastructure and technology to avoid renewing licenses for legacy systems, large content migrations can seem daunting. Even worse, they can sneak up on teams due to insufficient planning. However, with proper planning and leveraging creative yet reliable processes and tools content migrations can be performed efficiently and transparently to your end users.
Here at Perficient, we created a dedicated content migration practice after witnessing several painful experiences at customers caused by underestimating the effort required for content migrations. The two terms we like to use when discussing these efforts are “Transition” and “Migration”. The transition is the complete move from one ECM system to another. The transition includes everything – moving ingestion channels, associated application development, end user roll-out and the content migration. The content migration is one key component of the overall transition. Many times organizations feel cornered into planning the transition around the migration, but if you do things right you should actually be able to plan the migration to best support the overall transition.
When planning and scoping a large content migration, it should be done hand in hand with the overall transition. There are many factors that influence the scope of a migration and several of them are inherent properties of the transition itself. These factors include:
- Raw content migration scope and details
- How many documents are there to migrate?
- What is the total size of these documents?
- What is the ingestion rate?
- Are annotations currently in use and required for migration?
- What storage device is being used to actually store these documents?
- Are there long lived workflows associated with this content that need to be migrated?
- How many documents are there to migrate?
- Information about the target system
- Will content be stored on premise or in the cloud?
- Transition Approach
- Will the transition be grouped by individual lines of business (LOB)?
- Will user groups be gradually rolled out onto the new platform, or will there be one “Big-bang”?
- What is the time-frame that the total transition needs to complete by?
When approaching an ECM system transition and supporting content migration, we like to think of it as a story. The first step in planning is to figure out what kind of story it will be. Will this be a strategic transition, with 500 million total documents split into five LOB groups of 100 million documents each, which transition consecutively over three years and require a significant amount of associated application development? Or is this a straightforward transition between technologies, supporting one LOB with 50 million documents that can be migrated as quickly as possible? Will a delta migration to capture changes in the legacy system during migration activities be required?
For one large insurance company Perficient employed a “dual-committal” approach allowing them to avoid a “big-bang” cut-over. Synchronizing content and metadata between both the legacy and new ECM systems allowed this customer to gradually and seamlessly roll individual users out on the new system. While this isn’t appropriate for every migration scenario, the ability to not have an entire office of adjusters leave for the weekend Friday afternoon using one system and arrive Monday morning having to use a different system was extremely valuable.
One important transition consideration is workflows associated with migrated content. Best practice is to finish work to completion in the legacy system and start with fresh workflows in the new system. If there are long lived workflows that do need to be migrated, careful consideration needs to be given to the migration approach as this can significantly increase the overall scope.
Additionally, if your migration approach involves proven best practices like extracting content directly from the underlying storage device bypassing API calls to the legacy system, you can achieve throughput fast enough to support multiple transition schedules. This flexibility is incredibly valuable. With early and complete planning, content migrations can be setup to best support the overall transition effort rather than dictate it.