Moving data from one system to another can be a complex process. In this post, we have broken down how to approach data migration in 3 stages:
- Before you migrate
- Ready to migrate
- Once you’ve migrated
Your requirements will take into consideration:
- the amount of content and data you are moving
- how prepared each area of the organisation is to move
- how much you wish to automate the process
Stage 1 - Before you migrate
Ahead of migrating your content, you need to make sure your stakeholders are aligned, and the data is actually ready to move.
Here are our recommended steps ahead of migrating your content.
1. Identify your stakeholder/content owners
Start by understanding the different types of data you are migrating so that you can identify your stakeholders.
To do this, identify each department that has content within scope of your migration, and make them aware of your plans to migrate to a new platform, and the responsibility that sits with them to review and prepare their content. For example, policies may sit with HR, whereas news articles will likely sit with Internal Communications.
By identifying the stakeholder and assigning ownership to them, you’ve now made them accountable for the information that is presented to your users on the new platform after the migration. This should help align your stakeholders and get their buy in for your project.
2. Content discovery
Once you know who your stakeholders are, it’s important to keep them engaged, as nine times out of ten they will have other priorities, and the thought of reading through legacy content isn’t exactly appealing.
To keep them engaged, conduct content discovery workshops with each stakeholder.
Target the workshop at creating a structure for them to review and tag their content using something similar to a ROT analysis approach; whereby you label each item of data (be it communications content or a user data record) with one of the following.
Redundant; this type of content is duplicated elsewhere on the platform
Outdated; this content served specific purpose at a given time but it now no longer useful
Trivial; content that is not necessary or irrelevant for your new platform
Once each stakeholder has categorised their dataset, you can then help them make the decision to remove content before migrating, or to create an archived area on the new platform.
If you can, use your data analytics to support your decisions. Areas that are frequently visited but have outdated data are likely to still serve a purpose for a specific group of users. Whereas, an area that hasn’t been visited in the last 90 days probably does not.
3. Design your templates
Moving to a new platform should offer your users a better experience, and make things easier for them.
Once you know the types of data that are going to be hosted on the platforms, you can start thinking about how you want each of these to look.
Within the limitations of the new platform, put the design templates together for each content type taking into account the data each content type has (e.g. Title, image and tags).
Working with your stakeholders to design their new templates will help them feel involved and accountable for the new experience users will have.
4. Map your data
At this stage, you know what you’re migrating, you have your templates for each type of data, and you’ve taken into consideration the types of information each content type displays.
The next part is to complete a field mapping exercise for each of your content types so that the data is migrated into each area correctly.
The title of your content on the current platform is to be migrated into the title field on the new platform, like below.
| Current field | New field | |
| Title | > | Title |
| Topic | > | Tags |
| Updated date | > | Updated on |
| Body | > | Body |
Most communications platforms nowadays provide you with similar fields but some may label the field slightly different (e.g. Topic > Tags).
Stage 2 - Ready to migrate
Now you’ve prepared your data and engaged your stakeholders, you’re ready to start your migration journey. Now it’s time to choose your preferred method for migrating.
Option 1 - Whole Content Migration
This type of migration requires you to have all data ready to migrate at the same time. Sometimes this isn’t possible, as stakeholders haven’t finished their preparation or areas of the new platform have yet to be designed/signed off.
With whole content migration, we would recommend using a data migration tool to automate the process and remove any chance of human error. The larger the migration, the harder it is to find any issues with the data migrated.
Use this method if you’re confident that all content is ready and has been reviewed by the stakeholders, and if you’re looking to move fast.
Option 2 - Prioritised Content Migration
A prioritised content migration requires you to analyse the data involved and approach the migration in a more agile methodology to test the migration process.
With this method, you’ll prepare and migrate one dataset a time (eg Human Resources, Finance, News), and review the content on the new platform before moving on to the next dataset.
Each stakeholder will likely tell you that their content is a priority, so it’s usually a good idea to prioritise the content based on business importance and the platform analytics to support this.
With this approach you’ll be able to stagger your migration and review the process each time to minimise any risks of issues each type you migrate. It will also be easier to identify any cosmetic issues as less content would have been migrated.
Option 3 - Manual Content Migration
A manual migration is usually the preferred approach if you only have small amounts of content to move.
We’ve worked with customers that opt to start fresh and not migrate anything at all, or bring across very small amounts of data. To do this, we would recommend a manual migration, whereby you simply copy the data from the old system into the newly designed templates on the new.
Stage 3 - Now you’ve migrated
Once you’ve migrated, the heavy lifting is done, right? Wrong.
Remember how much effort had to go into engaging with stakeholders, ensuring their content is prepared and ready to migrate, and actually completing the migration. You don’t want to do that again any time soon, so follow these 3 steps.
Create guidance that helps your users create content in a consistent, quality way. Give them advice on the steps they should take and how they should format their content to make it more useful.
Define a workflow that ensures data is reviewed regularly and removed if necessary on the new platform. Most communications platforms these days offer you content features such as setting review dates, or automatic content deletion.
Review your platform analytics regularly to highlight any potential cases of redundant, outdated or trivial content so that you can fix the problem before it appears. Giving stakeholders ownership of their areas, and access to the analytics for their data is highly recommended but not always possible.
And, always remember, make sure your users are accountable for what they’re publishing!
