Why migrate at all? Who are the stakeholders? Should I look for outside help? What tools are needed? What preparations are needed? What are the costs involved?
Before we can think about embarking on a migration, we want to ensure that we have addressed these and other key questions in our planning for the migration. In short, we want to develop something akin to a charter for the migration; something that can form the basis for a strong business case and a successful migration.
Reasons for migration
The reasons for migrating an ECM system and its documents vary widely depending on circumstances, but the most common reasons include:
- Risk Management – ensuring that key, high value business assets in the form of electronic documents and metadata are current, available, protected, and uncorrupted
- Enhancement - need for additional functionality, increased performance or increased capacity
- Software/hardware obsolescence – end of life, inadequate performance, high maintenance/license costs, hard to maintain and integration/customization issues
- Media obsolescence – exhausted capacity, slow performance, degraded condition/read errors, unsupported, high maintenance/management/license costs, difficult to maintain and store, and regulatory non-compliance
- Strategic platform planning – bringing ECM in line with corporate standards and imperatives (streamlining costs, simplifying management, improving availability, and so on)
- Merging disparate systems – whether due to external acquisition/merger or incompatible internal repositories
“Build it and they will come” may work wonderfully in the movies, but migration success depends on concretely identifying and reaching out to the various constituencies with a vested interest in the migration and the benefits it will bring. Three main groups stand out here:
- Business Users – those who create and consume the content and use the ECM software. Identifying all the departments, lines of business, and groups can sometimes be a real challenge. Failure to locate, engage, and get buy-in from users is a major source of changes in scope, project delays, and overruns.
- Information Technology – IT supports the current repository infrastructure and acts as the gatekeeper in most cases. Thus, they tend to have the indispensable detailed, working knowledge of the current ECM solution, including who the users are, the laundry list of dependent processes and applications, limitations, etc.
- Legal and Compliance – those responsible for managing risk, legal issues, regulatory compliance and proper retention of records will all have to weigh in on how a new ECM solution must function and, in many cases, how electronic documents must be handled during the migration process
To partner or not to partner?
“Surely my company can handle the migration in house!” For a small, simple document migration, a company with the right mix of personnel, skills, processes, software, and experience can successfully migrate the documents. Unfortunately, the terms “document migration project” and “simple” rarely coincide.
The personnel angle is straightforward – document migration projects tend to be few and far between, usually resulting in few internal folks who possess the requisite big picture migration know-how and experience. Alongside the high level fundamentals, document migration requires a deep understanding of the repository internals, coupled with a wealth of hands-on knowledge of both the source and target repositories.
Processes and software for ongoing business use of documents can flawlessly handle daily operations but fail to address the unique requirements for carrying out a migration. Existing applications can outperform when it comes to daily document tasks but yet lack the ability to scale and log in the manner necessary for a timely and fully audited migration. Since most migrations involve a distinct source and target repository, the processes and tools needed must span both repositories, which in the case of a brand new target repository implementation often means that at least half the ingredients of the secret sauce are missing.
As the size and complexity of a migration grows, so too does the need for a trusted partner who has the full array of these vital pieces. Nevertheless, the partner question is not necessarily an all or nothing proposition. Paying a reputable document migration vendor to perform a detailed analysis and jointly develop a proposed migration solution vision can yield dividends and more than pay back the cost of the analysis engagement in terms of streamlined planning and execution of the actual document migration, even if a different vendor or in-house staff ends up performing the document migration.
Since source and target ECM repositories rarely have a built in way to move documents and data directly between them, some kind of migration software tool or application framework solution enters the picture for performing this function. A migration framework provides much needed manageability, reliability, scalability, extensibility, error handling, automation, and auditing for a document migration. And as the size and complexity of the migration grows, the need for a capable framework solution grows even faster.
At the 10,000 foot level, it looks something like this:
Migration frameworks come in many shapes and sizes. When evaluating potential vendors and tools, consider the following functionality as must haves:
- Scalability to quickly add and maximize available source and target processing resources
- Extensibility to support different repositories and quickly adapt to changing requirements
- Centralized configuration and management
- Unattended processing for up to 24x7 operation
- Automated stop and start capability for processing during selected periods
- Auto-restart if processing is unexpectedly interrupted
- Auto identification of exceptions (e.g. source repository corrupt files, missing metadata) and queuing for later handling
- Automated, document-level audit trail
- Ability to manage both bulk and delta migrations
- Ability to establish rules to consolidate or re-map metadata on the fly
- Handle rules for excluding documents based on age, type, or other criteria
- Ability to subsequently detect and handle changes to source document properties after the document has already been migrated to the target system
- Handling core document features of the source and target systems
Estimating the cost of a migration involves a large number of factors. As stated earlier, paying a trusted migration partner to help with planning and analysis, resulting in a documented solution and cost estimate can be well worth the price. The following expenses should be factored in (remember to account for each environment, i.e. DEV, UAT, PROD, DR):
- Software (base cost + licensing cost + maintenance)
- Core ECM application
- Supporting applications (operating system, database, application server, directory server)
- ECM add-on applications (monitoring, records management, case/process management
- Migration Framework
- Hardware (base cost + maintenance)
- Physical servers / virtual machines
- Storage media (primary and backup)
- Migration clients
- Installation and configuration of software and hardware
- Migration execution
- Migration testing and support
Imagine Solutions ECM Migration Services can help make your next ECM Migration project very successful!