Data Migration: Moving Systems Without Losing Your Past

Choosing new software gets weeks of demos, a scoring spreadsheet and three board discussions. Moving ten years of your business's data into it gets one line in the quote: "data migration — included". That line is where system projects actually succeed or fail. The software is replaceable; the record of every customer, price, balance and job you have ever done is not.

A migration is not a copy-paste. It is a translation between two systems that describe your business differently — and translations need a translator who knows what the old words meant.

Why it is never just an import

The old system has three records for Botha Construction — one per typo era — and the new system should have one. The old system stored a delivery note number in a field labelled "Reference 2", because in 2019 that was the only spare field, and only Marie knows this. Two hundred stock codes belong to products you stopped selling in 2022, and a customer category called "MISC" holds a quarter of your turnover. None of this survives an automatic import intact. Every one of these is a decision, and the vendor's import tool cannot make decisions — it can only faithfully reproduce your mess at a higher monthly fee.

Decide what moves — and what honourably retires

The instinct is "bring everything". Resist it. The working rule has three tiers: everything open moves (unpaid invoices, live orders, current stock, running jobs); master data moves after cleaning (customers, suppliers, products, price lists); and closed history moves back to a sensible horizon — usually two to three years, enough to answer "what did we charge them last time?". Everything older goes to a read-only archive: an export you can still search when the auditor or a dispute demands it. Paying to migrate a decade of closed transactions buys you slower screens and a bigger bill, not a better memory.

Migrate the data you will ask questions of. Archive the data you merely need to be able to answer for. The first belongs in the new system; the second only needs to exist.

Clean before you carry

Moving house is when you finally throw things out, and a migration is the one moment the business will tolerate data cleaning, because there is a deadline attached. Deduplicate the customers. Retire the dead stock codes. Split the "MISC" bucket into categories that mean something, because every report the new system ever produces will inherit whatever you carry in. All of it goes into a mapping workbook — old field to new field, rule by rule, decision by decision, with a name next to each choice. That workbook is the migration's real deliverable: it is the answer, two years from now, to "why does the new system say this?"

Trial runs, and counting things

No migration should meet real life on its first attempt. Run the whole move into a test copy of the new system, then hand it to the people who will live in it and let them run a pretend month-end. They will find what no consultant can: the customer whose terms are wrong, the unit of measure that turned boxes into eaches, the balance that looks almost right.

"Almost right" is the phrase to fear. The trial's exit test is reconciliation: record counts old versus new, the debtors' book to the cent, the creditors' book to the cent, stock quantities and values, trial balance if the migration touches the ledger. Every difference gets explained or fixed — never shrugged at, because a cent that cannot be explained is a rule that misfired, and rules misfire in bulk.

Cutover, and the two-systems trap

The move itself is a controlled weekend: freeze the old system on Friday, migrate the final delta, reconcile again, and open the new system on Monday with the old one switched to read-only — permanently. That last word is the important one. The deadliest failure mode is not lost data; it is the migration that "goes live" while the old system stays writable, and three months later half the team still lives there — the exact dynamic we described in Adoption Is the Project. Two writable systems means two versions of the truth, and the business quietly starts reconciling them by hand, forever. One system writes; the other remembers.

The move is the opportunity

Done properly, a migration is more than logistics. It is the one moment you get to correct ten years of accumulated shortcuts: the duplicate customers, the fields used for the wrong thing, the categories that stopped meaning anything. Businesses that treat the migration as an afterthought carry their old problems into their new system on day one. Businesses that treat it as the project arrive in the new system with numbers they trust — which was the reason for changing systems in the first place.