How to Perform a Content Migration - Your Checklist for Success

You’ve made a New Year’s resolution to clean up one of your digital landfills. Congratulations! But where do you start? In this blog post, we present an approach and checklist for migrating your information from one system to another. While the details will differ depending on a number of factors (the systems being migrated from and to, the nature of the information being migrated, etc.), many of the steps in the migration process will be similar.

We believe that an effective migration process consists of four primary phases:

1. Strategy
2. Planning
3. Preparation
4. Migration

Content Migration Phase 1: Strategy

The strategy should address the following:

• What’s the Reason for this Migration? It could be that the system is no longer supported by the vendor, making it increasingly difficult to access the information in that system over time. It could be that the organization wants to consolidate or standardize on systems or formats. It could simply be that the users don’t like and don’t want to use the system (though this is a much longer discussion). But the reason will impact the overall migration process.
• What’s the Scope of the Migration? Again, if the source system is being decommissioned, the organization may need to migrate everything. For a file share cleanup, it may make more sense to go in phases or target particular departments or processes. This will definitely impact the timeline required to do the migration, as well as what happens to the source system and the data it contains.
• Who Needs to be Involved? A migration is very intrusive and requires significant resources and commitment from the organization. This starts with senior management recognizing the need and committing resources. Once that’s in place, the team doing the actual migration can be identified. This should include at a minimum:
  • Business Users: Users who know (for better or worse) why the source system is set up the way it is. They understand their business needs and will be invaluable as the migration gets underway. In addition, business users will need to do the final quality control for their information.
  • Technical Specialists: A migration could require technical support for the movement of data and questions about implementation and data structures. The source and target system administrators should be involved as well.
  • Information Management Specialists: A given migration could require advice and support from records managers, knowledge managers, document managers or document controllers, privacy and data protection specialists, and others.

Content Migration Phase 2: Planning

Next, it’s important to plan the migration. This phase would include the following steps:

• Take Inventory of the Source System: This means identifying the information in the system, its metadata, how it is categorized and classified, any relevant business rules or workflows, security settings, etc.
• Identify Key Stakeholders for the Source System: Who uses or relies on that content? Who serves as the steward for that content on behalf of the business users? And who is the ultimate owner of that content – and can approve its disposition when appropriate? If you don’t know who the owner is, here’s a fast way to find out: Turn the system off! (Temporarily!) Whoever it is that complains first or loudest – that’s your owner. Note that this may not be a career-enhancing strategy...
• Determine the Value of the Information in the Source System: Does the source system store formal business records such as financial data, personnel files, contracts, etc.? Does it store information that can no longer be recreated? Or is much of it redundant, outdated or obsolete, or trivial (ROT)? The key is that you don’t want to migrate information of no business value. That also means that someone needs to make the decision about what is – and is not – migrated. Two key considerations here:
  • No permanent/irreversible actions should be taken without consulting with records management, legal, etc. Just because it’s old does NOT mean that it can be gotten rid of.
  • The decision to keep or not should not be based on nebulous, “just in case” reasoning. If some department or person wants to keep content that the team has determined is of no current business or legal value, that decision needs to be justified and agreed to. The group to make this determination should be all the relevant stakeholders, including legal, IT, and records management. This is especially important when dealing with personal data or other sensitive types of information.

Content Migration Phase 3: Preparation

With the plan in place, the team can start to prepare for the actual migration process. Relevant tasks here should include:

• Get Migration Tools: There are tools available to assist with the migration process that span the gamut from simply identifying folders and content to using analytics to automatically migrate and classify information. Whatever the team is using needs to be acquired and configured, and the users trained on it.
• Identify Existing Metadata in the Source System and Metadata Needs for the New System: Folders may be serving as metadata in some systems. In others, the migration may present an opportunity to standardize metadata structures and values.
• Prepare the Target System: Key tasks required include setting up security roles and settings, setting up classification schemes, setting up metadata, controlled vocabularies, thesauri, etc., and setting up workflows. Additionally, you'll need to ensure that users are ready to use the system as soon as the migration is complete and confirmed.

Content Migration Phase 4: The Actual Migration

And now it’s time to conduct the migration. Again, the details will vary significantly depending on the source and target systems. But the migration process must include these steps:

• Pilot & Test the Migration Process: This should be done first with smaller data sets to make sure the migration approach is sound, but we also recommend that a larger migration test be done as well to identify any issues that only occur at scale.
• Perform the Migration: While the migration is going on, it should be monitored for any potential issues or errors.
• Perform Quality Control: This starts with a basic technical check – 10,000 items in the source system, 10,000 items in the target system. But this is not enough – what if the metadata for each item is off? That is, the metadata for item 1,002 is actually the metadata for item 1,001? The key here is that users need to be significantly involved in this step because they know their information the best, and they know what they need in able to be able to perform their job.
• Turn Off Access to the Old System: There may be reasons that the legacy system needs to be kept – for example, some of the data that wasn’t migrated still has to be retained for legal or regulatory reasons. But at a minimum, that system should be set to read-only. It may be helpful to turn off access to it by end-users altogether because otherwise they may try to keep using it.

Conclusion

Migrations are complex projects that require time and resources to succeed. But every organization has to do this at some point or risk losing access to important information. Organizations that plan methodically, provide the resources required, and follow this process are much more likely to succeed.