Data Platforms

Planning a Data Platform Migration: Phasing, Cutover and Validation

A data platform migration succeeds on four things: an inventory that includes dependencies, waves ordered to reduce risk, a period of running old and new in parallel with the results compared, and a decommissioning date that is kept. Most of the effort is in work that produces nothing new, which is why it has to be planned.

• By DII Editorial Team

• Published October 9, 2026
• 10 min read

Share

• Share on LinkedIn
• Share on X
• Share by Email

A platform migration is an unusual project. When it is finished, users should have what they had before, on something different underneath. The benefit comes later, from what the new platform makes possible. The risk comes during, from the many ways of breaking something that worked.

This guide covers the planning: what to inventory, how to phase the work, how to choose a cutover approach, how to validate that the new platform produces the right answers, and how to finish. It assumes the destination has been chosen. It treats the work as a migration, a move of existing workloads, and leaves the question of what to improve along the way to be decided deliberately.

Settle the scope before the plan

Three decisions come before any scheduling.

What is moving, and what is not. A migration is the best opportunity the organisation will have to leave things behind. Amazon’s migration guidance lists seven strategies for each workload, which it says are “known as the 7 Rs”: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect¹. The first is the cheapest. Every pipeline and report that is retired before the migration is one that does not have to be moved, tested and reconciled.

Move as it is, or improve on the way. Moving a workload unchanged is faster and easier to validate, because the output should match exactly. Redesigning it during the move brings the benefits sooner and makes validation much harder, because differences are now expected and each has to be explained. DII’s advice is to choose one approach per workload and to prefer moving unchanged wherever the existing logic is sound. Improving and moving at once doubles the unknowns.

What done means. State the end condition: all in-scope workloads running on the new platform, validated, with the old platform switched off by a given date. Without the last clause, migrations finish at the point where the difficult remainder is left running on the old platform indefinitely.

Most published migration guidance is written for applications, and the phase models cited below come from it. Guidance written for data warehouse migrations adds what the general material leaves out. Microsoft’s guide to moving a warehouse to its analytics service states the scope in a sentence: “Performing a successful migration requires you to migrate your table schemas, code, and data”². It makes compatibility the first planning question, “A primary goal of planning is to ensure that your data, table schemas, and code are compatible” with the destination², and it advises settling design changes early: “While some design adjustments can be made after migration, making changes earlier in the process will save you time later”². That is one vendor writing about its own product, and the three objects it names, schemas, code and data, are the ones any data platform migration has to move. An application migration has no equivalent of proving that billions of rows arrived unchanged, which is why validation has a section of its own below. No vendor-neutral method for migrating a data platform was found and read for this article. The inventory, the stages of a wave and the levels of validation set out below are DII’s, built on that guidance.

Phase one: inventory and dependencies

Cloud providers’ migration frameworks agree that assessment comes first. Google’s describes four phases, assess, plan, deploy and optimise, and defines the first as the one in which you “understand your app and environment inventory, identify app dependencies and requirements, perform total cost of ownership calculations, and establish app performance benchmarks”³. Amazon’s large migration guidance uses three: “assess, mobilize, and migrate and modernize”⁴.

For a data platform, the inventory has five parts.

• Data. Tables, files and their volumes, with sensitivity and retention requirements.
• Pipelines. Every job that loads or transforms data, with its schedule and its owner.
• Consumers. Reports, dashboards, extracts, applications and people who query directly.
• Access. Roles, permissions and service accounts.
• Non-functional expectations. When data must be ready, how fast queries must be, what recovery is required.

The inventory is necessary and not sufficient. The connections between the items are what determine the order of work. Microsoft’s migration guidance is firm on the point: “Discover all dependencies first. Dependencies between workloads cause service disruptions if not migrated together”⁵.

Dependencies in a data platform are dense. A report reads a table that is built from three others, each fed by a pipeline that reads a source. Mapping those chains is a data flow mapping exercise, and the Data Flow Mapping Template gives a structure for recording them. Where usage logs exist, use them: they show what is actually read, including consumers nobody remembered.

Establish the benchmarks now. Record how long key pipelines take and how key queries perform on the old platform. After migration, someone will say the new platform is slower, and only a recorded baseline can settle it.

Phase two: waves

A migration of any size is done in waves. Microsoft’s guidance puts it as an instruction: “Organize large portfolios into migration waves”⁵. It gives the reason: “Migration sequencing reduces risk and builds team confidence by establishing a logical order for workload migration”⁵. Amazon’s guidance likewise tells teams to “perform wave planning”⁴.

A wave is a group of workloads that can be moved, validated and cut over together. Four principles guide the grouping. They are DII’s application of the published guidance to data workloads.

1. Follow the dependencies. Workloads that depend closely on each other move in the same wave, or the upstream one moves first.
2. Begin with something small and real. The first wave should be a complete, low-risk workload, taken all the way through cutover and decommissioning. Its purpose is to prove the method and expose what the plan missed.
3. Move the difficult ones in the middle. After the method is proven and before the team is tired. Leaving the hardest until last is how migrations stall near the end.
4. Group by consumer where possible. A team whose reports all move in one wave experiences one change. A team whose reports move across five waves works across two platforms for months.

Choosing a cutover approach

Cutover is the moment consumers move from old to new. There are three broad approaches, and the choice can differ by wave.

Single cutover. Everything in scope switches at once. This minimises the time spent running two platforms and concentrates all the risk in one event. It suits small estates and tightly coupled workloads that cannot sensibly be separated.

Phased cutover. Workloads switch wave by wave. Risk is spread and lessons carry forward. The cost is a long period in which two platforms run, data may have to be synchronised between them, and users must know which to use for what.

Parallel run, then switch. Old and new both run in full for a period, outputs are compared, and consumers switch when the comparison is clean. This is the safest for data, because it produces direct evidence of equivalence. It is also the most expensive, since everything is paid for twice while it lasts.

DII regards a phased approach with a parallel run inside each wave as the reasonable default for a data platform. The length of the parallel run should be set by the business cycle: workloads with month-end processing need to run in parallel across at least one month-end.

Whatever the approach, define rollback before cutover: the conditions that trigger it, who decides, and how it is done. A rollback that has not been rehearsed is an intention.

Validation: proving the new platform is right

Validation is what distinguishes a data migration from an application migration. An application either works or it does not. Data can be subtly wrong in ways nobody notices for weeks. Validation has to be designed, automated and run repeatedly.

Check at four levels, each catching what the one before cannot.

1. Structure. Every table exists with the expected columns and types.
2. Counts. Row counts match between old and new for each table and each period.
3. Aggregates. Sums, minimums, maximums and distinct counts on key columns match. This catches differences that counts miss.
4. Values. Row-by-row comparison, on samples or in full for the most important tables.

Tooling exists for this. Google’s guidance on warehouse migration, for example, describes an open-source data validation tool used “to validate that your source and destination tables match”⁶. Comparable approaches can be built with queries on any platform. What matters is that the comparison is automatic and runs on every parallel cycle.

Expect differences, and classify them. Platforms differ in how they handle numeric precision, rounding, null ordering, time zones and text comparison. Some differences will be genuine faults in the migration. Others will be legitimate differences in behaviour, and some will reveal that the old platform was wrong. Each needs a recorded decision. Agree the tolerance with the people who own the figures before validation begins, and not while a discrepancy is being argued over.

Validate the consumers as well as the tables. A report can show a different number from correct data if its own logic behaves differently on the new platform. For important reports, compare the report output.

The same properties that make a pipeline dependable in normal operation make it easier to migrate: a pipeline that can be rerun for any past period can be run on both platforms for the same period and compared. They are described in what makes a data pipeline reliable.

Decommissioning is part of the migration

The old platform must be switched off, and the plan should say when. Until it is, the organisation pays for two platforms, maintains two sets of access controls and runs the risk that someone is still using the old one. The treatment of that double-running cost belongs in the migration budget, and the wider discipline is covered in controlling data platform costs.

Before switching off, confirm from logs that nothing has read from the old platform for an agreed period, meet any retention obligations by archiving what must be kept, and remove access. Then stop the service and confirm the billing has stopped.

Governing the migration

A migration makes a large number of decisions in a short time, and several of them are architectural: how to handle a pattern the new platform does not support, whether to carry over a design everyone dislikes. Those decisions benefit from review by people outside the delivery team, on the lines set out in running a data architecture review that changes something.

Three habits keep a migration under control. Report progress as workloads decommissioned, since workloads merely moved are still running on both sides. Keep a visible list of exceptions and differences accepted. And hold the end date for the old platform as a commitment, with any extension decided explicitly by the sponsor.

The destination’s capabilities should be understood before the plan is made, as described in what a modern data platform is, and the criteria that led to choosing it, in how to evaluate and select a data platform, are the standard its first months should be judged against. The Migration Checklist sets out the steps for each wave from preparation to decommissioning.

Sources

1. Amazon Web Services. About the migration strategies (AWS Prescriptive Guidance: large migrations).
2. Microsoft. Migrate a data warehouse to a dedicated SQL pool in Azure Synapse Analytics (Microsoft Learn).
3. Google Cloud. Migrate to Google Cloud: Get started (Cloud Architecture Center).
4. Amazon Web Services. Phases of a large migration (AWS Prescriptive Guidance: large migrations).
5. Microsoft. Plan your migration (Cloud Adoption Framework for Azure, Microsoft Learn). Updated 1 August 2025.
6. Google Cloud. Introduction to BigQuery migration (BigQuery documentation). Updated 7 October 2026.

This article is general professional information. It is not legal or regulatory advice.