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.

#big data #consulting #intranet #data migration #data analysis

How to Approach Data Migration in 3 Stages - DZone Big Data
1.40 GEEK