Key considerations for a successful legacy data migration

Organizations move to the cloud for many reasons. Some are seeking to enable growth or innovation; others are doing so to reduce or better control ongoing spend; still others are seeking to consolidate disparate tools and platforms.

But once your organization has decided to embark on a cloud migration, the next question to answer is: “what happens to all the legacy data?” While it would be easier to leave the data where it is in the system or platform, this approach brings significant drawbacks:

1. The legacy system may no longer be supported. If something goes wrong in this system, it will go horribly wrong.
2. There is no single source of truth, and users would need to interrogate multiple systems or platforms to find all the data to get a complete picture of the available data.
3. As technology changes, how will the legacy system be supported from an infrastructure perspective?
4. Can create a risk and public embarrassment problem if users do not know where data is located.

As you can see, it is important to bring forward the data from the legacy systems into the new system being implemented.

Once this decision has been made we must consider: what is the data migration strategy? Is it a lift-and-shift, where the data is transferred without being changed, or should we transform the data? How do we make sure that this is an effective data migration project that meets the business’ requirements?

Data migration strategies compared: lift-and-shift vs modernization

One of the greatest mistakes that organizations make is to try and make the new system look and feel too much like the legacy system.

A lift-and-shift migration, where applications and data are moved to the cloud with minimal changes, may seem like a cost-effective approach, but it often becomes more costly in the long run. This is because lifted and shifted apps are not optimized to leverage the cloud-native features of the new application and may involve increased data egress costs. A lift-and-shift migration is short-sighted, as it doesn’t consider how business processes may evolve, with the business narrowly focused on delivering what they had in their old system into the new.

A lift-and-shift can be contrasted with a modernization, where applications and data are transformed to better leverage the cloud. This may involve transforming data from a collection of individual records into a database, for example.

If the decision is made to transform and modernize the data, it becomes critical to understand the ideal end-state, and how the integrity and compliance posture of the data will be maintained throughout the process.

Transformation of data requires patience, to ensure all the stakeholders are engaged, onboard and ready for the journey of change. Vision is required to ensure the stakeholders rethink the status quo and can move in an agile manner through the process. Digital transformation is not just about upgrading systems, it is also about building capability, empowering workers, and enabling communication.

Regardless of whether the migration strategy is to lift-and-shift or to transform the data, the three data migration project phases are the same. Here are the top questions to consider to ensure the project is a success.

1: Planning

• Who in the organization will be involved in the project?
• Will the migration implementation be conducted in-house or through a consultancy or third-party?
• What resources will be needed for the project?
• What is the scope and budget of the migration?
• Which data will be migrated – is it everything or is it a sub-set?
• Where will the data reside: in which systems and in what geographical region? Will your organization require data sovereignty?

Good planning assumes that any assumptions in the plan will fail. Be careful about any assumptions in the data migration. A key assumption to break: Not all metadata or data needs to be brought across to the new system. It is important to analyze what is of value and what is just noise when migrating data from legacy systems.

2: Migration

• Who will be able to access the data once the migration has occurred?
• Who will build the migration checklist?
• Who will be involved in the data extraction for the migration?
• What migration tooling will be used?
• When will the migration take place, and when will any backups be made? Timing is critical for this point.
• How will the data be managed in its new location – are there any potential legal considerations to be made?

Testing, testing, testing – this cannot be stressed enough. Testing ensures that there is minimal downtime, data integrity is maintained, data is not lost and the application to which the data is being migrated will be functional post-migration.

Throughout the migration process, it is important to continually check to ensure that the plan and what is proposed for migration continues to be workable.

3: Post-migration

• Who is the responsible owner of the system post-migration stage?
• What testing will occur post-migration to ensure complete success of the data migration?
• When testing, the key indicator of success is whether the data in the new system matches the old. Can it be found? Is the required metadata present? Is it searchable as expected?
• When is the post-migration stage going to occur and when will the system be handed over to the business-as-usual team?
• How is the system going to be managed in an ongoing basis?

No two migrations will ever be the same. Leaving the data in a legacy system is not the answer, so the key question to be answered is whether the migration is going to be an exercise in lift-and-shift, or whether a transformation occur. Once this question has been answered, then the planning can begin in earnest.