1. Start planning early.

Clients often underestimate the amount of planning required for any type of migration. Migration often involves more than just moving content from one place to another. Many migrations also have to account for mapping metadata, folder structure, security, and other related objects from the source system to the target system. A typical migration timeline is depicted below. Note the duration of the planning phase.

2. Take inventory of all objects in the source system to be migrated.

It might seem obvious, but it’s important to take detailed inventory of the content to be migrated. In addition to just counting documents, consider other objects, such a versions, renditions, folders, permissions sets, annotations, users, and groups. For many clients, the inventory process frequently uncovers content that may have fallen through the cracks.

3. Use migration as an opportunity to “clean house”.

Content migrations provide a great opportunity to clean up data to avoid migrating content that is no longer needed. Content cleanup can be a labor intensive task to perform in-place in an existing content management system. Migrations have provided many of our clients a chance to leave behind the clutter. Additionally, the less content that needs to be migrated, the shorter the duration of the migration.

4. Use migration as an opportunity to “reorganize the house”.

Similar to cleaning house, as noted in tip #3, migration is also the optimal time to rework the content model, massage metadata, rearrange the folder structure, or simplify the security model. Since every content item is being touched as part of the migration, why not jump on the opportunity to make content architecture changes that are otherwise very difficult and time consuming to do in-place?

5. Take the time to perform benchmark testing during the planning phase.

For large migrations, duration is an important factor to consider. Performing test migrations of sample batches of documents helps to provide more accurate estimates for how long the full migration will take. Migration throughput is largely dependent on factors such as network, storage, CPU, memory, and database speeds, making it nearly impossible to predict the overall migration duration without benchmarking.

6. Identify and address migration performance bottlenecks.

After benchmark tests have been run, scrutinizing migration logs to identify throughput bottlenecks proves to be worth the extra effort. We often see clients significantly improve migration performance by making simple fixes to address bottlenecks, such as adding indexes to database tables, adding additional RAM to the source or target system, or running the migration process on a server with better network throughput.

7. Break the migration down into manageable batches.

Staying organized and tracking counts of the content that needs to be migrated, is currently being migrated, and has been migrated is critical for large migrations. It can be unwieldly to try to migrate all documents as one big batch. Most clients find it easiest to batch content into smaller pieces based on metadata, such as document type, creation date, or folder path. Migration statistics can be gathered and analyzed upon the completion of each batch, making it easier to report status and estimate how long the migration will take to complete. Smaller batches also make it easier to restart a migration if a problem arises, such as a network outage or planned maintenance on the source system.

8. Have a migration verification plan.

Migration tools, such as TSG’s OpenMigrate, have robust logging mechanisms for reporting counts of the amount of content that was successfully migrated or failed to migrate. Migration tools cannot always report that content is migrated exactly as expected. It’s critical to identify a sample set of content to verify after migration to ensure that content, metadata, folder structure, security, etc. are all mapped correctly in the target system. Verification can be tedious, but it’s important that all possible scenarios are verified. It can be very costly and time consuming to fix discrepancies if they’re caught too late.

9. Allow enough time to handle migration anomalies and failures.

Rarely do large migrations run perfectly without any failures, especially when migrating from legacy systems that have exceeded their life expectancy. Even with detailed planning, there are almost always instances of corrupt files, bad/missing metadata, and other unexpected scenarios that occur during a migration. Even if the error rate is a very small number, reconciling and resolving errors can be a time consuming process, and should be planned for.

10. Plan to perform delta migrations.

Delta migrations allow for the source repository to continue to be used while the bulk migration is being execute. With large migrations, it’s risky and sometimes impossible to execute a full migration during an outage window. Migration tools like TSG’s OpenMigrate allow for smaller delta migrations to be run after the bulk migration is complete to synchronize any content that was added or modified since the start of the bulk migration. A final delta migration can be scheduled during an outage window at the time that users are to switch from using the old system to the new system.