How to Write a Data Migration Plan: Phases, Types, and Cutover Strategy

Write a data migration plan by settling four things before anything else: what data actually moves, how each field maps to the target, how you will prove the move worked, and what triggers a rollback. The phases, the schedule and the cutover runbook all follow from those four answers rather than the other way round.

This is about the data specifically, not the wider system move. If you are still choosing between rehosting, re-platforming and rebuilding the application around it, that decision sits upstream and is covered in how to plan a system migration. What follows assumes the target exists and the question is how to get the records into it without losing any.

How do you write a data migration plan?

Write it backwards, starting from the check that will tell you the migration succeeded, because that check determines almost everything upstream of it. If you cannot describe the passing state in numbers, you have no basis for deciding whether to go live or roll back, and cutover night will be decided by whoever sounds most confident at 2am.

A workable plan contains nine things:

• Scope. Which sources, which entities, which date ranges, and an explicit list of what is not moving.
• Owners. A named person per source system, per target, and per validation check. Not team names.
• Source profile. Row volumes, quality findings, known bad data, and what happens to each category of it.
• Mapping. Field by field, with transformation rules, defaults and the fields with no target.
• Environments and dry runs. Where you rehearse, on what data, and how many times.
• Cutover sequence. Freeze, extract, transform, load, verify, release, with times against each step.
• Validation and reconciliation. The specific checks, the thresholds that count as passing, and who reads the results.
• Rollback. The trigger conditions, the person authorised to call it, and the time after which it stops being available.
• Decommission. When the source is switched off, who keeps a copy, and for how long.

The section that gets left out is almost always the rollback trigger. A plan that does not say who is allowed to stop the migration is a schedule, not a plan.

Keep the mapping in a separate sheet rather than inside the document. It changes daily during design and monthly forever afterwards, and a plan that has to be reissued every time a column is renamed stops being read.

What are the 6 phases of migration?

The six phases below are the ones that appear in nearly every published methodology, though the number itself is a convention rather than a standard. Vendors publish four, five, six and seven phase versions and they disagree about where the boundaries fall. Treat the sequence as reliable and the count as arbitrary.

1. Discovery and scoping. Find every source, including the spreadsheet the finance team has been maintaining since the last migration. Establish volumes, owners, dependencies and which downstream systems read from the source.
2. Profiling and assessment. Measure the data rather than describe it. Null rates, distinct values, orphaned foreign keys, duplicates, date fields holding free text. This is where you find out the plan you wrote is fiction.
3. Design and mapping. Agree the target model and map every field to it. Decide the transformation rules, the defaults for missing values, and what happens to source fields with nowhere to go.
4. Build and rehearse. Write the extract and transform code, then run it against a production-scale copy. Time the load. Record how long the reconciliation takes, because that time sits inside your cutover window too.
5. Cutover. Freeze writes on the source, run the migration for real, reconcile, and either release the new system or roll back. The plan should already say which.
6. Validation and decommission. Run the business-level checks over the first days of live use, keep the source readable but frozen, and retire it only once someone with a stake in the data has signed off.

Phases two and three are where the schedule is actually decided, and they are the ones most often compressed to make a fixed go-live date work. Compressing them does not save time. It moves the work into phase five, where it costs considerably more.

Profiling and mapping: where the plan meets the data

Profiling is a measurement exercise, and the output is a list of exceptions with a decision against each one. Run counts and distributions on every column you intend to move: null rate, distinct count, min and max, length outliers, and format violations against whatever rule the target enforces. Compare row counts between related tables to find orphans. Every anomaly needs a named disposition before mapping starts, because a mapping rule written over unprofiled data is a guess, and downstream it gets read as a fact.

The common findings are dull and expensive. Free-text values in fields the target treats as enumerations. Two customer records for the same organisation with different identifiers. Dates stored as strings in three formats because three applications wrote to the column over ten years.

Mapping then produces four categories, and it is worth labelling them explicitly:

• Direct. Source field to target field, no change.
• Transformed. A rule applies. Write the rule as code or pseudocode, not as a sentence.
• Derived. The target field has no source and must be computed or defaulted. State the default and who chose it.
• Dropped. The source field does not move. This is the category that generates arguments later, so record who agreed to it.

Field-level decisions get made in passing and forgotten within a fortnight. Keep them somewhere durable rather than in a thread, which is the same argument as for keeping a decision log on any long-running piece of engineering work.

What are the different types of data migration?

Five categories are commonly used, and the label only matters because each one changes a different part of the plan.

• Storage migration. Data moves between storage systems with the format unchanged. The risk is throughput and integrity, not meaning. Checksums do most of the validation work.
• Database migration. Data moves between engines or major versions. Schema and type differences dominate, along with anything that relied on engine-specific behaviour such as collation or default precision.
• Application migration. The application changes, so the data model changes with it. This is the hardest type, because two systems rarely agree on what an entity is. One system’s “account” is another’s “organisation plus billing contact”.
• Cloud migration. Data moves to or between cloud platforms. Transfer time, egress cost and the security boundary become planning constraints in a way they were not on-premises.
• Business process migration. The business changed, through a merger, restructure or regulatory split, and the data has to follow. The mapping questions are organisational rather than technical, and the answers usually need someone senior.

Most real migrations are two or three of these at once. A move from a self-hosted CRM to a hosted one is an application migration and a cloud migration together, and the plan has to answer both sets of questions.

What are the different types of migration methods?

Three cutover methods cover almost all migrations: big bang, phased (also called trickle or incremental), and parallel run. They are decisions about time and reversibility, and they are separate from the rehosting and re-platforming choices that apply to the application layer.

	Big bang	Phased (trickle)	Parallel run
How it runs	Everything moves in one window, usually a weekend	Data moves in slices by entity, region or date range	Both systems run live on the same data until you switch
Downtime	A defined freeze, hours to days	Little or none, but a long split state	None, paid for with dual writes
Rollback	Clean while the freeze holds, difficult afterwards	Per slice, so one bad slice does not sink the release	Simplest available: keep using the old system
Build complexity	Lowest	Needs sync or change data capture between old and new throughout	Highest: every write lands twice and the two must agree
Suits	Smaller datasets, few consumers, a business that tolerates a weekend offline	Large datasets, many downstream consumers, regulated cutovers	Finance, payroll, clinical data, anything where a wrong number is unrecoverable
Main failure mode	The window overruns and rollback is no longer available	The interim state quietly becomes permanent	Divergence nobody reconciles until a customer finds it

Phased migrations depend on keeping the old and new systems consistent while both are live, usually through change data capture reading the source’s transaction log. Budget for that plumbing as a deliverable in its own right. Teams often choose phased because it sounds lower risk, then discover the sync layer is the largest piece of engineering in the project.

Parallel running is the strongest control available and the least popular, because it doubles the write path and requires someone to compare the two outputs regularly. If nobody is assigned to read the comparison, a parallel run is just an expensive big bang.

Decide the rollback criteria before cutover, not during it

Rollback criteria are the numeric conditions under which you abandon the migration and restore service on the old system, and they have to be written down while everyone is calm. On the night, the people in the room will have spent months on the work and will be strongly motivated to push on. That is exactly when a pre-agreed threshold earns its place.

Write four things:

1. The triggers. Specific and measurable. “Reconciliation variance above 0.1% on any monetary total”, “load not complete by 05:00”, “any orphaned record in the order tables”, “error rate above the agreed threshold in the first hour of live traffic”.
2. The decision owner. One named person with the authority to call it, plus a named deputy. Not a committee, and not “the migration team”.
3. The expiry. The point of no return, which is usually the first user write to the new system. After that you are not rolling back, you are forward-fixing, and the plan needs a separate section for that.
4. The rollback procedure itself. Timed and rehearsed, in the cutover runbook alongside the forward steps. A rollback that has never been executed is a hope.

Those answers come from people who rarely sit in the same meeting: the data owner, whoever is on call, and whoever answers for the downstream reporting. Projan will work through the open questions with that group in Slack, record each answer with the owner’s name attached, and push the resulting tasks into Jira or Linear. The plan should not reach cutover with the rollback owner still unnamed.

How do you prove the migration worked?

Reconciliation, in layers, with the results written down and read by someone. Row counts matching is the weakest evidence available and it is where most teams stop.

Run these in order, cheapest first:

• Row counts per table and per partition. Fast, and catches only gross failures.
• Control totals. Sums of every monetary and quantity column, compared source to target. These catch truncation, type coercion and duplicated loads.
• Column profiles. Null rate and distinct count per column, compared against the profiling baseline you took in phase two. A column that was 2% null in the source and is 40% null in the target has a broken mapping.
• Referential integrity. Orphan checks across every relationship the target enforces and every one it does not.
• Record-level sampling. A stratified sample reconciled field by field, including the awkward records you found during profiling. Someone who knows the domain should read a handful in full.
• Business-level checks. Reproduce a report both systems can generate, such as last month’s revenue by region or headcount by department, and compare the outputs. This is the check the business trusts, and it is the one that finds mapping errors the technical checks pass.

Variances are normal. What matters is that each one has an explanation and a disposition before sign-off, rather than a note saying it will be looked into. Keep the reconciliation output as an artefact with the plan. When someone questions a number six months later, the alternative is re-running an argument nobody can win.

Frequently asked questions

How to write a data migration plan? Keep it short and specific. Roughly a page per phase, with named owners rather than team names, a mapping sheet held separately because it changes daily, and a version number on the front. Review it with the people who operate the source and target systems, not only with the people funding the project.

Do you have to migrate all the historical data? No, and deciding this early removes more work than any other scope call. Split records into migrate, archive and drop. Archive means a readable export plus a documented way to query it. Anything you drop needs a written decision with a name against it, because someone will eventually ask where the 2019 orders went.

How many dry runs should you do before cutover? At least two on production-scale data, and the last one should be a full rehearsal including the freeze, the reconciliation checks and a timed rollback. Small runs on sample extracts tell you the transform logic works. They tell you nothing about whether the load finishes inside your window.

How long should the freeze window be? Long enough for the slowest dry run plus the reconciliation checks plus the rollback, not the average dry run. Publish the window as a time by which you will either confirm or roll back, and give the business a read-only view of the old system during it if the data supports one.

Who signs off that a migration is complete? Someone in the business who depends on the data, not the engineer who ran the load. The engineer confirms the technical checks passed. The finance lead, operations manager or clinician confirms the numbers they use every day still look right. Both signatures belong in the plan with a date.

A data migration plan is worth what its exceptions list and its rollback criteria are worth. Profile before you map, rehearse at production scale, and agree in writing who can stop the cutover and on what number. The rest of the document is scheduling.