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 migrationThe 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 uncorruptedEnhancement - need for additional functionality, increased performance or increased capacitySoftware/hardware obsolescence - end of life, inadequate performance, high maintenance/license costs, hard to maintain and integration/customization issuesMedia obsolescence - exhausted capacity, slow performance, degraded condition/read errors, unsupported, high maintenance/management/license costs, difficult to maintain and store, and regulatory non-complianceStrategic 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 repositoriesStakeholders"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 processTo 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. Migration FrameworkSince 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 resourcesExtensibility to support different repositories and quickly adapt to changing requirementsCentralized configuration and managementUnattended processing for up to 24x7 operationAutomated stop and start capability for processing during selected periodsAuto-restart if processing is unexpectedly interruptedAuto identification of exceptions (e.g. source repository corrupt files, missing metadata) and queuing for later handlingAutomated, document-level audit trailAbility to manage both bulk and delta migrationsAbility to establish rules to consolidate or re-map metadata on the flyHandle rules for excluding documents based on age, type, or other criteriaAbility to subsequently detect and handle changes to source document properties after the document has already been migrated to the target systemHandling core document features of the source and target systemsBudgetingEstimating 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 applicationSupporting applications (operating system, database, application server, directory server)ECM add-on applications (monitoring, records management, case/process managementMigration FrameworkHardware (base cost + maintenance)Physical servers / virtual machinesStorage media (primary and backup)Migration clientsInstallation and configuration of software and hardwareMigration executionMigration testing and supportReferencesImagine Solutions ECM Migration Services can help make your next ECM Migration project very successful!About the authorSean Leino, Senior Systems EngineerSean Leino works for Imagine Solutions, Inc. as the Principal Conversion Specialist. He has over 10 years of experience planning and executing document migrations for dozens of clients, ranging from small departmental repositories up to high volume, Fortune 100 enterprise systems with counts of a billion images and more. Imagine Solutions, maker of Encapture: Distributed Capture System and an IBM Premier Business Partner, provides the full range of ECM services including migration, software, consulting, solutions, and platform services. More from this author
