Data migration checklist work is the least glamorous part of any system replacement, and it is the part that quietly decides whether the project lands on the planned weekend or drags into a six-month cleanup. Nobody demos a reconciliation pack. Nobody puts a rollback runbook on a slide. Yet when a finance director refuses to sign off a new ERP because the trial balance moved by £4,000 overnight, every one of those unglamorous documents becomes the only thing anyone wants to read.
The reason so many moves go wrong is that teams treat the copy as the project. Extracting records from one database and loading them into another is the easy, well-tooled, largely solved part. The hard part is proving that what arrived is the same as what left, in a form the business will accept, with a credible way back if it is not. A data migration checklist exists to force those three questions — validation, reconciliation and rollback — into the plan before the transfer window opens rather than after it closes.
This guide sets out a working data migration checklist for UK businesses moving between systems: what to profile before you write a single mapping, which validation layers actually catch defects, how to build a reconciliation pack finance will sign, and how to design a rollback you could genuinely execute at 3am. Our data management and analytics and data warehousing teams run this work with mid-sized organisations most months, and the companion guide to a cloud migration cutover plan and rollback covers the infrastructure side of the same weekend. A general data migration overview is a fine primer, but it will not tell you what to sign.
Table of contents
- What a data migration checklist must cover before anything moves
- Pre-migration profiling: where a data migration checklist actually starts
- Validation in a data migration checklist: proving the data arrived intact
- Reconciliation: the data migration checklist step finance signs
- Rollback: the data migration checklist step everyone skips
- Cutover sequencing: running the data migration checklist on the day
- Governance and UK GDPR duties inside a data migration checklist
- What a data migration checklist costs in effort and time
- Failure modes a data migration checklist is designed to catch
- The full data migration checklist, phase by phase
- Frequently asked questions about a data migration checklist
- References
What a data migration checklist must cover before anything moves
Most failed moves were lost weeks before the transfer window, in decisions nobody recorded. A data migration checklist front-loads those decisions so that the technical work has something firm to build against.
Scope: name the systems, tables and record types explicitly
Write down every source system in play, every table or object within it, and every record type inside those tables. “Customers” is not a scope statement; “active customers, dormant customers, prospects, duplicates flagged for merge, and the 1,400 records with no postcode” is. Ambiguous scope is the single most reliable predictor of an overrunning migration, because each unnamed record type becomes a mid-flight decision made under time pressure by whoever happens to be awake.
Agree what “correct” means with the people who will sign
Correctness is a business definition, not a technical one. Before any mapping is written, the data migration checklist should capture, in the business’s own words, the handful of figures that must match after the move: the trial balance, the open order value, the headcount, the stock valuation, the number of live contracts. These become your reconciliation controls later. Agreeing them at the start costs an afternoon; discovering them during cutover costs the weekend.
Choose the migration pattern deliberately
Big bang, phased, parallel run and trickle each carry a different risk profile, and the choice changes almost every other line of the plan. A parallel run buys confidence at the cost of running two systems and double-keying for weeks. A big bang is cheaper and faster and gives you one shot. The pattern must be a recorded decision with named trade-offs, not a default inherited from the vendor’s implementation template.
Freeze the mapping document and version it
The source-to-target mapping is the contract between the business and the build. Every field, its source, its transformation rule, its default when null, its length limit and its owner. Version it, and treat changes as change requests. A data migration checklist that does not name a single owner for the mapping document is a checklist that will produce two incompatible versions by week three.
| Pattern | How it runs | Rollback difficulty | Best suited to | Main risk |
|---|---|---|---|---|
| Big bang | One transfer window, old system off | Hard after go-live | Small estates, hard vendor deadlines | One shot, no rehearsal in production |
| Phased by module | Finance, then sales, then operations | Moderate, per phase | ERP and finance replacements | Interfaces between migrated and legacy modules |
| Parallel run | Both systems live, outputs compared | Easy, old system still authoritative | Payroll, billing, regulated reporting | Double-keying fatigue and cost |
| Trickle with CDC | Continuous replication, then promote | Easy until promotion | Large databases, short outage tolerance | Delta window never fully closes |
| Archive and start clean | Open items only, history to an archive | Easy, source untouched | CRM, ticketing, marketing platforms | Users cannot find historic records |
Pre-migration profiling: where a data migration checklist actually starts
You cannot map data you have not measured. Profiling is the step teams skip when the timeline is tight, and it is the step that returns the most hours later, because every defect it finds is a defect that would otherwise have surfaced during the transfer window.
Profile every source table before writing a mapping
For each column, record the populated rate, the distinct value count, the minimum and maximum lengths, the observed formats and the outliers. This takes hours with standard tooling and reliably finds the surprises: the free-text field holding four different date formats, the “country” column with 31 spellings of United Kingdom, the phone numbers with embedded notes. A data migration checklist without a profiling output attached is a plan built on assumptions.
Decide what not to migrate
The cheapest record to validate is the one you never move. Most estates carry a long tail of dormant, superseded and duplicate records that exist only because nothing ever deleted them. Splitting the estate into migrate, archive and discard — with the business signing that split — routinely removes a third of the volume and, with it, a third of the reconciliation effort. It also aligns the move with the UK GDPR data minimisation principle, which a migration is a natural moment to apply.
Cleanse in the source, not in the pipeline
Fixing a broken record in the transformation layer means the source and target now legitimately disagree, and your reconciliation has to explain why. Fixing it in the source before extraction keeps both sides identical and keeps the reconciliation simple. Where a source fix is impossible, record the transformation as a named, approved exception with an expected variance — that exception list becomes part of the reconciliation pack.
Measure the delta rate
If your move involves any replication window, you need to know how many records change per hour in the source. That number sets your outage length, your catch-up strategy and the point at which a trickle migration stops being viable. Teams that never measure it discover during cutover that the delta is growing faster than the pipeline can apply it.
The shape of that distribution is the argument for profiling. Four defects in five originate before a single row is loaded, which is why a data migration checklist that begins at the load step is already too late to help.
Validation in a data migration checklist: proving the data arrived intact
Validation answers a narrow, technical question: is the target a faithful representation of the source under the agreed mapping? It is not the same as reconciliation, and conflating the two is how migrations end up with a green test report and an unhappy finance team. The validation section of a data migration checklist should specify layers, because each layer catches a class of defect the others cannot see.
Layer one: counts and control totals
Row counts per table, per record type and per partition, plus summed control totals on every numeric column that matters. This is crude, fast, and catches the largest category of catastrophic failure — a truncated load, a filtered extract, a batch that silently failed. Run it after every load, including every rehearsal, and store the results so trends are visible.
Layer two: field-level rules
For each mapped field, assert the things the mapping promised: type, length, null policy, allowed values, format, range. The classic defect this catches is silent truncation, where a 60-character target column accepts the first 60 characters of an 80-character source value and the load reports success. A field-level rule comparing source and target lengths finds it in seconds; a human reading sample records almost never does.
Layer three: referential integrity
Every foreign key should resolve. Orphaned order lines, invoices pointing at deleted customers, contacts attached to organisations that were filtered out of scope — these load without error in most systems and only surface when a user opens a record and sees nothing. A data migration checklist should require an explicit orphan report per relationship, with a target of zero and a written explanation for any exception.
Layer four: business rules the database cannot express
Some correctness lives above the schema. An invoice that is paid should not have an open balance. A closed contract should not carry future renewal dates. A stock item should not have negative quantity across all locations. These assertions must be written by people who know the business process, and they belong in the same automated suite as the technical checks so they run on every rehearsal.
| Validation layer | What it catches | What it misses | When to run |
|---|---|---|---|
| Row counts and control totals | Truncated loads, filtered extracts, failed batches | Any defect that preserves the count | After every load, automated |
| Field-level rules | Truncation, type coercion, format drift, bad defaults | Correct-looking but wrong values | After every load, automated |
| Referential integrity | Orphans, broken hierarchies, missing parents | Valid links to the wrong record | After every load, automated |
| Business-rule assertions | Process-level contradictions | Rules nobody thought to write | Each rehearsal and cutover |
| User acceptance sampling | Usability, wrong-but-valid data, missing context | Anything outside the sample | Final rehearsal, before sign-off |
| Reconciliation controls | Business figures that moved | Individually wrong records that net to zero | Cutover, then daily for two weeks |
Reconciliation: the data migration checklist step finance signs
Reconciliation is the business’s proof, not the project’s. It asks whether the numbers the organisation manages itself by are the same before and after, and it is the evidence a director puts their name against. Validation can pass perfectly while reconciliation fails, because a faithfully migrated wrong number is still wrong.
Build the control set from the agreed definitions
Return to the figures the business named at the start of the data migration checklist and turn each into a repeatable query on both sides. Trial balance by account. Aged debtors by bucket. Open orders by value and count. Stock valuation by location. Live headcount by cost centre. Each control needs a source query, a target query, an owner and a tolerance — usually zero, occasionally a documented rounding allowance.
Run reconciliation on every rehearsal, not just the real one
A reconciliation pack produced for the first time on cutover night is a reconciliation pack nobody knows how to read. Producing it on each dry run does three things: it debugs the queries themselves, it trains the finance reviewers on the format, and it builds a history so that a variance on the night can be compared against the last clean run rather than argued about from scratch.
Distinguish sampling from full reconciliation
Full reconciliation compares aggregate totals across the whole estate and is cheap to automate. Sampling opens individual records and checks them end to end against the source system’s screens, which is expensive but catches things totals cannot. A serious data migration checklist uses both: full reconciliation on every control figure, plus a stratified sample of perhaps 100 to 300 records weighted towards the awkward cases.
Close the delta window explicitly
If records changed in the source after your extract, reconciliation must account for them. The pack should state the extract timestamp, the count of source changes since that timestamp, the count applied to the target, and the resulting difference — which should be zero. Leaving this implicit is how a migration passes reconciliation on Saturday and fails it on Monday when someone notices Friday afternoon’s orders are missing.
The execution everyone worries about is the smallest slice on the chart. That is the practical case for a data migration checklist weighted towards preparation and proof rather than towards the mechanics of the transfer.
Rollback: the data migration checklist step everyone skips
Rollback is the item most often written as a single line — “revert to previous system if required” — and most often discovered to be fiction at the worst possible moment. A rollback plan is only real if someone has executed it end to end against a realistic dataset and timed it.
Define the point of no return before the weekend
Every migration has a moment after which reverting costs more than pressing on: usually the first genuine business transaction recorded only in the new system. Name that moment, name what makes it irreversible, and put a decision checkpoint immediately before it. A data migration checklist that leaves the point of no return undefined guarantees the decision gets made implicitly, by drift, at about four in the morning.
Choose a rollback pattern that matches the migration pattern
Restore-from-backup is the simplest and slowest and loses anything entered since the snapshot. Keeping the legacy system live and read-write until sign-off is faster to revert but risks divergence. Reverse synchronisation writes new-system changes back to the old one and is the most capable and the most expensive to build. Blue-green deployment thinking applies directly here: the value is in keeping a known-good environment intact and switchable.
Write triggers, thresholds and a named decision-maker
“We will roll back if there are serious problems” is not a trigger. “We will roll back if reconciliation variance on any control exceeds tolerance and cannot be explained within 90 minutes, or if the load has not completed by 04:00, and the decision sits with the named migration lead” is. Pre-agreed triggers convert a fraught judgement call into a procedure, which is exactly what you want from anyone who has been awake for eighteen hours.
Time-box the rollback itself
Measure how long a full revert takes, including restoring integrations, reversing interface flags, and notifying users. That duration must fit inside the remaining outage window with margin. If your rollback takes six hours and you have four left, you do not have a rollback — you have a hope. The recovery-objective discipline from NIST SP 800-34 transfers cleanly to migration planning, and our guide to cloud disaster recovery testing covers how to rehearse it properly.
| Rollback pattern | Typical revert time | Data loss exposure | Build cost | Use when |
|---|---|---|---|---|
| Restore from snapshot | Hours, scales with volume | Everything since the snapshot | Low | Short outage windows, low transaction rate |
| Legacy kept read-write | Minutes, flip the routing | New-system entries only | Low to medium | Phased moves with a short overlap |
| Legacy kept read-only | Hours, needs a re-enable step | New-system entries only | Low | Most mid-market replacements |
| Reverse synchronisation | Minutes, continuous | Near zero | High | Regulated or 24/7 operations |
| No rollback, fix forward | Not applicable | Unbounded | None | Only with an explicit signed decision |
Cutover sequencing: running the data migration checklist on the day
The transfer window is where a good plan gets tested and a vague one gets improvised. Sequencing is the discipline that keeps it boring.
Write a runbook with timestamps and owners
Every step, in order, with an expected clock time, an owner, a duration, a verification action and the go or no-go criterion. Integrations disabled at 18:30. Final extract started at 19:00. Load complete by 23:00. Validation suite green by 00:30. Reconciliation pack issued by 02:00. The runbook is the artefact that lets someone unfamiliar with the project see whether the night is on schedule, which matters because the people who built it will be too tired to judge.
Rehearse the whole thing at production scale
A dress rehearsal on a subset proves the code runs; it does not prove the timings. Load volumes behave non-linearly, and a step that takes 20 minutes on a tenth of the data can take four hours on all of it. At least one rehearsal must use full-volume production-like data end to end, with the validation suite and the reconciliation pack produced exactly as they will be on the night.
Freeze changes and communicate the window
Nothing undermines a reconciliation faster than a well-meaning colleague processing a batch during the freeze. Publish the freeze window, disable the entry points where you can rather than relying on goodwill, and make the communication explicit about what users should do with work that arrives during the outage. The government service manual’s guidance on deploying software regularly reinforces the same point: small, rehearsed, well-communicated changes fail less often.
Keep a decision log during the window
Every deviation from the runbook, every exception waved through, every variance accepted — logged with a timestamp and a name, in real time. It costs a minute each and it is the difference between a clean post-migration review and a fortnight of archaeology. It is also the evidence trail an auditor will ask for.
Governance and UK GDPR duties inside a data migration checklist
A migration moves personal data, usually copies it several times, and frequently leaves those copies lying around. The compliance items belong in the same data migration checklist as the technical ones, because they have the same deadline.
Treat non-production copies as real data
Test and rehearsal environments generally receive full production extracts, which means they carry the same personal data with weaker controls and looser access. Either mask or synthesise the data for non-production use, or apply production-grade access control and a documented destruction date. Enumerating every copy created during the project, and who can reach it, is a five-minute exercise that regularly surprises people.
Apply retention and accuracy at the point of transfer
A migration is the best opportunity in a decade to act on the storage limitation and accuracy principles, because you are already touching every record. Records past their retention period should not be carried forward simply because carrying them is easier than deciding. Our guide to a data governance framework for SMEs covers how to set those periods so the migration has something to apply.
Confirm processor obligations before data leaves
If a migration partner or a tool handles the data, the controller and processor responsibilities apply, including written instructions, security obligations and deletion at the end of the engagement. Where the data crosses borders — a support team outside the UK, a cloud region elsewhere — that needs checking before extraction, not after.
Capture the audit evidence the migration generates
Profiling outputs, mapping versions, validation results, reconciliation packs, the decision log and the sign-off. Store them together as a bundle. Anyone asking in eighteen months why a figure changed will be answered in ten minutes rather than ten days, and the same bundle satisfies most of what an internal auditor wants from a data migration checklist.
What a data migration checklist costs in effort and time
Budgeting a migration by the size of the database is the most common estimating error. Effort tracks the number of source systems, the number of mapped fields and the state of the data far more than it tracks volume.
The cost drivers that actually move the number
Each additional source system adds reconciliation surface. Each poorly-documented legacy schema adds discovery time. Each business rule that exists only in someone’s head adds a workshop. Ten million clean rows from one well-understood system is a smaller job than 200,000 rows spread across four spreadsheets, an access database and a system whose original developer left in 2014.
Realistic timelines by estate complexity
For a single well-documented source with a clean schema, six to eight weeks from profiling to cutover is achievable. Two or three systems with moderate data-quality problems typically runs twelve to twenty weeks. A multi-system ERP replacement with poor documentation and regulated reporting is a six-to-twelve month programme, and the data migration checklist for it should be treated as a workstream with its own lead.
| Estate profile | Sources | Elapsed time | Rehearsals | Typical UK cost band |
|---|---|---|---|---|
| Single clean system | 1 | 6 to 8 weeks | 2 | £15k to £35k |
| Two systems, moderate quality issues | 2 to 3 | 12 to 20 weeks | 3 | £40k to £90k |
| Finance or payroll with parallel run | 2 to 4 | 16 to 26 weeks | 3 to 4 | £70k to £150k |
| Multi-system ERP replacement | 4 or more | 6 to 12 months | 4 or more | £150k and above |
Those bands assume the validation and reconciliation work described above is in scope. Where a proposal comes in materially below them, the usual explanation is that proving correctness has been left to the client without anyone saying so, which is the most expensive kind of saving a data migration checklist can expose.
Failure modes a data migration checklist is designed to catch
Migrations fail in patterns, and the patterns repeat across industries and toolsets. Each of these has a specific checklist item that prevents it.
The silently truncated field
A source field exceeds the target’s length limit and the load layer quietly trims it. Addresses lose their final line, notes lose their conclusion, reference codes lose their suffix and stop matching. The load reports complete success because nothing raised an error. Field-level length comparison between source and target catches this in the first rehearsal.
The reconciliation nobody could reproduce
The pack was produced once, by one person, in a spreadsheet built on the night, using queries never written down. A variance appears on Monday and nobody can regenerate Saturday’s figures to compare. Version-controlled, automated reconciliation queries run on every rehearsal turn this from a crisis into a diff.
The rollback that was never tested
The plan said restore from backup. Nobody checked that the backup restores, how long it takes, or whether the integrations reconnect afterwards. Discovering that the restore takes nine hours when four remain in the window is a genuinely common way for a migration to become an outage. Test the restore, time it, and record the result in the data migration checklist.
The delta window that never closed
Extract at 19:00, load until 23:00, and quietly forget the four hours of source changes in between. The reconciliation passes because it compares the extract against the target, not the live source against the target. Explicitly counting and applying post-extract changes — and reconciling against the source as it stood at freeze, not at extract — closes the gap.
The interface that pointed at the old database
Reporting tools, integrations, scheduled jobs and that one spreadsheet with a live connection all need repointing. The system looks migrated; a nightly job keeps writing to the legacy database for a fortnight before anyone notices two divergent sets of numbers. Inventory every consumer of the source data during profiling and treat repointing as a first-class cutover step.
The full data migration checklist, phase by phase
Consolidating everything above into a sequence you can lift into a plan. Each item needs an owner and an evidence artefact, because an unowned checklist item is a wish.
Phase 1 — Discovery and profiling
Inventory source systems, tables and consumers. Profile every column. Agree scope by record type. Agree the reconciliation control figures with the business. Split the estate into migrate, archive and discard. Measure the delta rate. Record the migration pattern decision with its trade-offs.
Phase 2 — Build and rehearse
Write and version the source-to-target mapping. Build extract, transform and load. Build the validation suite across all four layers. Build the reconciliation queries on both sides. Build and time the rollback. Run at least two full rehearsals at production volume, producing the validation results and reconciliation pack each time.
Phase 3 — Cutover
Publish the runbook with timestamps and owners. Freeze changes and disable entry points. Take the final extract and record its timestamp. Load, then run the validation suite. Apply and count the delta. Produce the reconciliation pack. Hold the go or no-go checkpoint before the point of no return. Repoint every interface. Maintain the decision log throughout.
Phase 4 — Post-migration
Re-run reconciliation daily for two weeks. Keep the legacy system available read-only for an agreed period. Triage and fix defects against a published SLA. Destroy non-production copies on the recorded date. Bundle the evidence and hold a review. Close the data migration checklist formally, with the business signing that the numbers agree.
| Phase | Exit criterion | Evidence artefact | Typical owner |
|---|---|---|---|
| Discovery and profiling | Scope and control figures signed | Profiling report, scope statement | Data lead with business sponsor |
| Build and rehearse | Two clean full-volume rehearsals | Validation results, reconciliation pack | Migration engineer |
| Rollback readiness | Revert executed and timed within window | Timed restore log | Infrastructure lead |
| Cutover | Reconciliation within tolerance, go accepted | Runbook, decision log, signed pack | Migration lead |
| Post-migration | Fourteen clean daily reconciliations | Daily variance report, review notes | Business data owner |
Frequently asked questions about a data migration checklist
How long should a data migration checklist take to prepare?
Preparation is most of the job. Expect profiling, scope agreement and mapping to consume roughly a third of total effort, and validation and reconciliation build another quarter. If your plan allocates a fortnight to preparation and a weekend to execution, the estimate is inverted and the weekend will absorb the difference.
Is validation the same as reconciliation?
No, and treating them as one thing is a recurring cause of failed sign-off. Validation proves the target faithfully reflects the source under the agreed mapping and is a technical test. Reconciliation proves the business’s own figures still agree and is a business test. A migration can pass the first and fail the second, which is precisely why the data migration checklist separates them.
How many rehearsals are actually necessary?
Two full-volume rehearsals is the practical minimum, three is comfortable, and regulated or payroll migrations usually need four. The purpose of the last one is not to find defects — it is to prove the timings and to produce a reconciliation pack the reviewers have already seen in the same format.
What if the vendor says rollback is not possible?
Then that is a decision to make explicitly, in writing, with the business accepting the consequence. Sometimes it is genuinely the right answer. What is never acceptable is discovering it during the window. If there is no rollback, the compensating controls are more rehearsals, a longer parallel run and a firmer point of no return.
Can a small business run a data migration checklist without specialists?
Largely yes, for a single clean source system. The profiling, mapping and reconciliation controls are all achievable with spreadsheet and SQL skills. Where outside help earns its fee is on multi-system moves, regulated reporting, and any migration where the rollback has to be genuinely executable rather than nominal. Our managed IT services and cloud adoption teams pick up exactly those cases.
References
AWS Database Migration Service User Guide
Azure Database Migration Service overview
Martin Fowler: Blue-Green Deployment
Martin Fowler: Strangler Fig Application
Google SRE Workbook: Canarying Releases
NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems
NIST SP 800-92: Guide to Computer Security Log Management
GOV.UK Service Manual: Moving away from legacy systems
GOV.UK Service Manual: Deploying software regularly
GOV.UK: The Technology Code of Practice
ICO: The data minimisation principle
ICO: The storage limitation principle
ICO: Controllers and processors
DAMA Data Management Body of Knowledge
Microsoft Purview documentation
