What goes in a data migration plan?

Scope, stated by object

The first section names what is moving. Not "customer data" but each object: customers, addresses, contracts, open orders, invoices, ledger balances, attachments. For each one, three decisions get recorded — is it migrated, how much history comes with it, and what happens to what is left behind.

History is where scope quietly expands. Ten years of closed transactions cost far more to migrate, reconcile and defend than two years of open ones, and the request for all of it is usually made without anyone costing it. The alternatives — archive, read-only access to the legacy system, extract to a reporting store — belong in the plan as named decisions with an owner, because they will be questioned later.

What is explicitly out of scope is worth writing down as plainly as what is in.

Mapping

Source to target, field by field, with the transformation rule for each. Default values where the source has none. Rules for the fields that exist in the target and not in the source, which are usually the ones that generate manual work for the business. Reference data mapping, which is where most of the trouble sits: two systems with different code lists, different currencies, different unit of measure conventions.

The mapping is a working document with a version, not a one-off. Each dry run changes it. Whoever owns it needs to be able to say which version produced which load, because that is the first question when a reconciliation does not balance.

Cleansing, and who does it

Profiling comes first: duplicates, missing mandatory values, invalid formats, orphaned records, values outside the range the target will accept. The results usually surprise the business, which is the point of doing it early.

Then the part that determines whether the plan works — who cleanses. Cleansing is almost always business work, because it needs someone who knows which of two duplicate customers is real. It competes with those people's day jobs and with user acceptance testing, and it is the single most common reason a migration timeline slips. The plan names the people, the volumes and the dates, and the Data Migration & UAT Tracker keeps both workstreams in one place because in practice the same people are doing them in the same weeks.

Load sequence and dependencies

Objects load in an order set by referential integrity: reference data before masters, masters before transactions, transactions before their dependants. The sequence lists each load with its dependency, its expected duration and its verification step. It is also where the split between what can be loaded ahead of the window and what must be loaded inside it gets decided, which directly determines how long the window has to be.

Dry runs

A dry run is a full rehearsal of the load at production volume, in an environment that resembles production, timed. Anything less tells you the code runs; it does not tell you how long it takes or what breaks under real data.

The plan sets how many dry runs there will be, what each one is for, and the entry and exit criteria for each. A first run proves the mechanics. A second proves the timings and the reconciliation. A final one is a rehearsal of the actual cutover sequence, with the people who will be on shift. Each produces a defect list, a revised mapping and revised durations.

Reconciliation and tolerances

Tolerances are agreed in advance and with the people who will have to defend the numbers. A tolerance argued about at four in the morning is a tolerance being negotiated to fit the result. Where a difference is expected — records deliberately excluded, historical rounding — that is documented as an expected variance rather than discovered as a gap.

Defects, sign-off and fallback

Migration defects need their own severity definitions, because "the record loaded but the credit limit is wrong" is a different class of problem from a failed job. The plan states how they are logged, triaged and re-tested, and which severities block go-live.

Sign-off is a named person accepting the reconciliation result for each object, before the go/no-go meeting rather than in it. That signature is one of the criteria on the Go/No-Go Checklist.

Finally, the fallback: what happens if the load fails or reconciliation is outside tolerance during the window. Restore point, reverse sequence, the deadline by which the decision must be taken. That connects directly to the rollback plan, and the fuller treatment of profiling, dry runs and sign-off is in the data migration guide.

Questions · All 36 templates