Migration means moving content from a source to a destination. Often it is from multiple sources to at least one destination. Here are some important considerations:
- If there are any information architecture changes required, the migration will be more complex than a simple "lift and shift" of content.
- This is often a great time to clean up information ROT (redundant, obsolete, trivial). This can make the new information repository cleaner and often lower the effort of the actual migration process.
- The process has to be planned and executed carefully and with adequate change management to avoid problems:
- The migration should usually be done at a time when no users are interacting with the content, otherwise you will have to deal with the delta of change in the content.
- The process should be planned and tested in a staging/testing environment in order to verify that all the content will be moved correctly by the planned migration process. If there are issues, revise and repeat until it works and has been verified. Then throw that test data away and redo the migration to the new production destination, allowing for much higher likelihood of success and avoiding a delta of content to reconcile.
- People who interact with the content as part of their job need to be informed and then verify that they have the information in the new location and can do their jobs. A little training at this point will go a long way toward successful adoption of the new solution. Remember: You are not just migrating content, but also people and processes.
Another thing to keep in mind is this: Depending on the information architecture, which should largely depend on your business processes, not all content necessarily has to be migrated at once. Focus on units of content that would cover individual business processes if it would work better to migrate in phases.
For each phase of migration, the following process can be adapted to your needs to ensure a successful content migration.
Stage 1: Plan
- Determine migration requirements.
- Inventory source content and metadata.
- Determine records and information management requirements.
- Create destination site architecture and design.
- Create cleanup and migration plan.
- Develop test plan.
- Communicate migration plan to affected users.
Stage 2: Test
- Create staging site for test and cleanup.
- Migrate a copy of the source content to staging site.
- Test content cleanup in staging site.
- Validate test cleanup and migration.
- Customize cleanup and migration procedures.
- Dispose of test content.
Stage 3: Migrate
- Make sources read-only.
- Migrate content to staging site again, for final cleanup prior to migration to final destination.
- Perform content cleanup.
- Create the production site for migration.
- Migrate cleansed content to target site.
Stage 4: Validate
- Verify successful migration completion. If anything goes wrong, you can back out by unlocking the source repositories for continued use while starting this planning again for a future attempt.
- Create migration report.
- Conduct migration completion meeting.
- Dispose of staging content.
- Decommission source content and source repositories according to retention policies and requirements.
I plan to write more about each of these steps in future posts.
A note about grammar here:
- "Clean up" is a verb phrase, as in "You need to clean up your content."
- "Cleanup" is a noun, as in "This is the plan for content cleanup."