Carefully think through the pros and cons of your approach to content migration.
The advent of a new generation of modern content solutions and the desire of many organizations to reduce the number of content systems is driving organizations to look at how they can update their content management infrastructure.
More and more organizational leaders face the need to migrate legacy content to a newer content suite, either in the cloud or on-premise. This may contain hundreds, thousands, or millions of files and documents with related metadata and business logic that need to be migrated.
Organizations face conflicting goals as they think about rationalizing and modernizing their content infrastructure. On the one hand, as organizations make their plans for the next 18-24 months, they can clearly see the attractiveness of cloud content management solutions and the imperative of making these solutions a more important part of their infrastructure. On the other hand, they likely have older legacy ECM systems – likely multiple systems – performing critical functions that can’t just be turned off without suffering lots of business disruption. In any migration project, it is important to be able to monitor and verify that all desired content is migrated, and no content is lost during the process.
There are basically five main approaches that can be taken – three of them built around a DIY strategy, and the other two involving a partner.
A manual migration means just that. Manual. You’re not using a tool but rather just a drag and drop approach. If you have a small number of documents in your repository – say in a file share – this may be all you need. Usually in this approach you can work efficiently with the content in the new system without having to do any transformations.
A manual approach can also work in a situation where you have an ECM system that has export functions. In this case, you could export all of the data and then move it to SharePoint, for instance. However, adding the metadata the right way (assuming this was present in the source system, not necessarily the case) will not be easy – and might not even be possible.
This approach can sometimes be error prone, time consuming, and dependent on simple brute strength (like using students) for its success.
AIIM Data Point: 70 percent of organizations are shifting their emphasis from on-premises content management platforms to cloud-based services.
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. A typical example of this might be a tool to migrate from a fileshare to SharePoint or from one SharePoint repository to another. This kind of approach can be inflexible because of the one-to-one nature of many of these tools – they move content from one specific system to another. No system integrator or consulting expertise is necessary, though, and end users can often do it themselves.
AIIM Data Point: 80 percent of organizations state that they are working to migrate from legacy content management platforms to more modern solutions for managing content.
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. Like most custom approaches, this does carry the advantage that you can be very specific in your requirements. This is also the inherent disadvantage, though. Custom development often means underestimating the time and money necessary to build a solution – and the eventual purchase of a tool anyway.
Because of the high volume of migrations, there are many software platforms that are specifically built for migrations. These platforms are often used by consultancy bureaus that specialize in migration and require extended training to use. These solutions basically all use the same “Extract, Transform, Load process” and offer the opportunity to create business rules on selection, mapping, enrichment and validation, guaranteeing that a document is exactly the same in the source and in the target system.
The disadvantage of this approach is that not all tools are flexible enough to cover the 20% of migration needs that are always unique to you’re your organization, which means that the “last mile” of a migration can often lead to unexpected professional services costs.
A more recent option is Migration-as-a-Service, in which a single vendor handles everything. In complex infrastructures with multiple legacy source systems, business rules and millions of documents, an automated migration solution can only migrate up to 80 percent of all the content because there are always exceptions. Often organizations are much better off outsourcing the complete migration process so that someone else assumes the risk for the “last mile” of the project.