Data migration: managing it rather than explaining it

What gets migrated, why and how is set out in data migration — the riskiest step and the least discussed. This station is about something else: running it as a project phase.

The number to understand first: this phase consumes most of the schedule contingency. Plan two weeks for it and you find yourself in six, not because loading is hard, but because the data is not what it was described as.

First decision: who owns each file

A file with no named owner does not get cleaned.

File	The right owner	Why not IT
Chart of accounts	Finance director	A reporting structure, not a list of numbers
Items	Purchasing or production	Classification is a business decision
Customers	Sales	Credit and terms belong to sales
Suppliers	Purchasing	Payment terms and bank details
Opening balances	Accounting	Reconciled rather than copied
Transaction history	Finance director	A depth decision, not a transfer decision

The third column is this station’s message. Hand the data to IT and you get a technically successful load of data nobody accepts.

Write the owner by name in a published table, with a delivery date per file.

Second decision: how much history

A steering committee decision, not a working team one.

Option	What it gives	Its price
Opening balances only	A clean start and the fastest project	No prior-year comparison inside the system
One year	Year-on-year comparison	Double the cleaning effort
Three years or more	Trend analysis	Doubles the phase, and imports old disorder

The first option is right more often than people assume, and it is usually refused for an emotional rather than an analytical reason: “we want our history”.

The question that settles it: which decision will you take with this history that you could not take from the old system? With no specific answer, the history stays readable in the old system and is not loaded.

Keeping the legacy system readable for a year is far cheaper than migrating three years of transactions. That is a third option rarely offered, and usually the right one.

Three loads, not one

One load before go-live is the commonest shape of failure in this phase.

Cycle	When	Its purpose
1	After design approval	To expose the size of the problem — it partly fails, and that is expected
2	Mid-testing	To verify cleaning, and to build test data
3	The cutover rehearsal	A drill for the night itself, to the clock

The first cycle always shocks, and that is its purpose. It converts “our data is good” into a number: how many records were rejected, and for what reasons. Defer it to month six and the surprise becomes a crisis.

The third cycle is measured by the clock. If the load takes fourteen hours, that is a number in the cutover plan rather than a technical detail.

The reconciliation criterion — written before the first load

“The data moved” is not a criterion.

The criterion is four lines, written and approved before the first load.

• Record counts: source against target, with every difference explained line by line.
• Financial totals: total receivables, payables and inventory, reconciled to the currency unit rather than to a rounding.
• A vertical sample: twenty records read in full in both systems and compared field by field.
• A functional test: a real transaction executed against migrated data — an invoice to a migrated customer, an issue from migrated stock.

The last line catches what counting does not. A customer record can migrate in full and you still cannot invoice them, because a field that appears in no reconciliation report is empty.

Who signs the reconciliation? The finance director, not the project manager.

Opening balances — which are not a migration

The commonest conceptual error in this phase is treating opening balances as a file to be moved. They are not.

They are an accounting entry that is written, reconciled and approved, sourced from the legacy system and owned by the finance director.

Four items need a separate decision each.

Item	The decision required
Customer and supplier balances	Per invoice or as a total? — only per-invoice gives a correct ageing
Inventory	Quantity and cost per item per location — and counted physically before migration, not after
Fixed assets	Cost, accumulated depreciation and purchase date, not net book value alone
Post-dated cheques and commitments	Carried across with their due dates, and always forgotten

The first row decides whether the ageing report works from day one. Move a single total per customer and you get a correct balance with an ageing entirely in one bucket — which is information with no value.

The second row needs a real stock count, not a copy of the legacy report. The gap between the books and reality surfaces once in a company’s life: at cutover. It is the cheapest moment to find it.

What you actually do in this station

• Write the file table with an owner, a name and a delivery date.
• Put the history depth decision to the steering committee with its three options and each one’s impact.
• Schedule three load cycles in the main plan, not in a side plan.
• Write and approve the reconciliation criterion before cycle one.
• Measure the load duration in cycle three and put it into the cutover plan.

The three commonest mistakes

One: one load before go-live. The problem is found when there is no time left.

Two: handing the data to IT. It loads successfully and nobody accepts it.

Three: migrating history without asking. The phase doubles and five years of disorder is carried into a new system.

The acceptance test for this station

1. Show the file table with an owner and a date for each.
2. State the history depth decision, who made it and on what grounds.
3. Show cycle one’s results with rejection counts and reasons.
4. Show the reconciliation criterion and who approved it.
5. State the measured load duration and where it sits in the cutover plan.

What comes next

The data has moved. The next station verifies the system actually works on it: testing and UAT — who signs, and against what exit criterion.