Content Migration Plan: Step-By-Step Checklist

You've made a New Year's resolution to clean up one of your digital landfills. Congratulations! But where do you start? How do you migrate content? In this blog post, we describe a method and checklist for migrating your information from one system to another. While the details will vary based on many factors (the systems migrated from and to, the nature of the information being migrated, etc.), many steps in the content migration plan will be similar.

We believe that an effective transfer process consists of four main stages:

• Strategy

• Planning

• Preparation

• Migration

Content Migration Phase 1: Strategy

The strategy should address the following issues:

• Why content migration is important and what is the reason for it? It could be that the system is no longer supported by the vendor and over time it has become increasingly difficult to access the information in it. It may be that the organization wants to consolidate or standardize systems or formats. It might just be that the user doesn't like and doesn't want to use the system (although that's a longer discussion). But the reason affects the entire process.

• What is the scope of the migration? Likewise, if the source system is being decommissioned, the organization may need to migrate everything. For file share cleanup, it may make more sense to do it in stages or for a specific department or process. This definitely affects the timeline required to do the migration and what happens to the source schema and the data it contains.

• Who needs to be involved? Migration is very intrusive and requires significant resources and commitment from the organization. The first is that senior management recognizes the need and commits resources. Once in place, the team that will do the actual migration can be identified. This should include at least:

  • Business users: Know (for better or worse) why the source system is set up as such users. They understand their business needs and will be invaluable as the migration progresses. In addition, business users will require final quality control of their information.

  • Technologist: Transfer may require technical support for data movement and questions about implementation and data structures. Source and target system administrators should also be involved.

  • Information management specialists: A given migration may require advice and support from records managers, knowledge managers, document managers or document controllers, privacy and data protection experts, and others.

Content Migration Phase 2: Planning

Next, it's important to create a content migration plan. This phase will include the following steps:

• Inventory the source system: this means identifying the information in the system, its metadata, how it is categorized and categorized, Any relevant business rules or workflows, security settings, etc.

• Identify key stakeholders of the source system: Who uses or relies on the content? Who is the steward of this content on behalf of business users? Who is the ultimate owner of this content - and can approve its disposition in due course? If you don't know who the owner is, here's a quick way to find out: Shut down the system! (For now!) Whoever complains first or the loudest - that's your master. Note that this may not be a career advancement strategy...

• Determine the value of information in the source system: Does the source store formal business records such as financial data, personnel files, contracts, etc.? Does it store information that can no longer be recreated? Or are most of them redundant, outdated, outdated, or trivial (ROT)? The point is that you don't want to migrate information that has no business value. It also means that someone needs to decide what to migrate and what not to migrate. There are two key considerations here:

  • No permanent/irreversible action should be taken without consulting records management, laws, etc. Just because it's stale doesn't mean it can be gotten rid of.

  • The decision to reserve or not to reserve should not be based on vague "just in case" reasoning. If a department or individual wants to keep content that the team believes has no current business or legal value, that decision needs to be justified and agreed. The group making this decision should be all 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

Once the content migration plan is in place, the team can start preparing for the actual shifting process. Relevant tasks here should include:

• Get migration tools: There are tools available to assist with the migration process, from simply identifying folders and content to using analytics to automatically migrate and categorize information. Whatever the team uses, it needs to be acquired and configured, and users need to be trained.

• Identify existing metadata in the source system and metadata requirements for the new one: Folders may be used as metadata in some systems. In other cases, migrations may provide an opportunity to standardize metadata structures and values.

• Prepare the target system: The key tasks required include setting up security roles and settings, setting up taxonomy schemes, setting up metadata, controlled vocabularies, thesaurus, etc., and setting up workflows. Additionally, you need to ensure that users are ready to use the system as soon as the migration is complete and confirmed.

Content Migration Phase 4: Actual Migration

Now is the time to do the migration. Again, the details will vary greatly depending on the source and target systems. However, the process must include the following steps:

• Pilot and test the migration process: This should be done first with a smaller dataset to ensure the migration approach is sound, but we also recommend a larger migration test to identify any issues that only occur at scale.

• Perform the migration: During the transfer process, it should be monitored for any potential issues or errors.

• Perform quality control: Start with a basic technical check - 10,000 items in the source system, 10,000 items in the target system. But that's not enough - what if metadata for each item is turned 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 heavily involved in this step because they know their own information best and they know what they need to be able to perform their work.

• Close access to legacy systems: There may be reasons why legacy systems need to be retained - for example, some data that was not migrated must still be retained for legal or regulatory reasons. But at least, it should be set to read-only. It might help to turn off access to it completely for end users who might otherwise try to keep using it.

Conclusion

Migrations are complex projects that require time and resources to succeed. On SolutionsHub we have a selection of solutions for content migration and modernization. If you are planning database migration to the cloud, you can use migVisor in the initial phase. It's a tool for analyzing database environments and generating a visual cloud migration roadmap. It also ranks databases according to their complexity and identifies potential migration challenges and suggests appropriate workarounds.

A well-planned content migration can save time, money, and effort in the long run. By following a step-by-step checklist, you can ensure a smooth and efficient migration process. Keep in mind that proper planning and preparation are key to successful content migration.