Data migration — the riskiest step nobody budgets for

Migration appears in the proposal as one line: “we will move your data across from the legacy system.” In the project it consumes more calendar than any other work package, and it is discovered late because it is the only item the vendor cannot do alone.

The reason is structural rather than commercial. The data is yours, and nobody outside your company knows which parts of it are true.

Why it is always underestimated

Because everyone hears “move the files” and it is actually three consecutive jobs with three different owners.

The work	Who does it	How long it takes
Cleansing	You, alone	Far longer than the other two combined
Mapping to the new system’s structure	The vendor, under your direction	Moderate
Loading and verification	Both, together	Repeats more than once

The first row is the one missing from the plan. Then somebody opens the item file and finds the same product under three codes with three spellings, and everything stops while a decision is made about which one is real — a decision only your operations manager can make, and he is not in the project team.

The rule that halves the effort

Do not move everything. Move what you need to run the company tomorrow morning.

Confusing those two is expensive. Your history is not being abandoned; it just does not necessarily have to live inside the new system.

Data	The right decision
Active master data — items, customers, suppliers you still trade with	Move, after cleansing
Opening balances — accounts, stock, receivables and payables	Move as balances, never as transactions
Open documents — orders not yet received, invoices not yet paid	Move. This is the hardest and most precise part
Closed transaction history	Leave it in the legacy system for reference
Records untouched for years	Do not move. This is the single largest saving available

The fourth row always meets resistance, and the demand is always phrased the same way: we want all the history in the new system. The practical answer is to keep the old system running read-only for a defined period. Licensing a legacy system for lookup for two years costs a fraction of migrating a decade of transactions and then reconciling them, and the reconciliation is the part that overruns.

Opening balances, where most of the errors are

An opening balance is not a number you type. It is a journal entry that gets posted, and every balance you enter needs its other side. Without that, your trial balance is out on day one and stays out.

Three balances must be entered in detail rather than as a total:

Receivables, invoice by invoice. One aggregate figure per customer makes collection and allocation impossible: a payment arrives and there is nothing to match it to, so the ageing report is fiction from the first week.

Payables, invoice by invoice, for the same reason and with the same consequence at the supplier end.

Inventory with both quantity and cost. Moving quantity without cost produces a wrong cost of goods sold from the very first sale, and the error is invisible until the first monthly gross margin looks strange.

The only acceptable test is that the trial balance in the new system agrees with the last approved trial balance in the old one, to the currency’s smallest unit. Anything short of exact agreement is not close. It is a failure that has been deferred to the first close.

Cleansing comes before the load, never after

Bad data in a new system is still bad data, and now the system is what gets blamed for it. That misattribution is worth avoiding on its own: it poisons user confidence in month one, and confidence is very difficult to recover.

Four checks on every file before it is handed over:

• Duplication. Is the same item present under more than one code? The same customer under three spellings?
• Completeness. Does every item have a unit of measure, a category and an account?
• Consistency. Are all the numbers in one format, and all the dates in one format?
• Validity. Is this customer still a customer? Is this item still sold?

The best time to start is now, before the project exists. Cleansing is the only part of a migration that requires no software and no vendor, so it can run in parallel with the selection process. A company that tidied its item master before choosing a system has saved weeks, not days.

Rehearse the load three times

Anyone who loads their data once, shortly before go-live, discovers their problems on go-live night.

1. An early trial load with a small sample. The purpose is to expose format problems: character encoding, date formats, mandatory fields the source never captured.

2. A full load into the test environment. The purpose here is different — measure how long it takes, and surface the errors that only appear at volume. A routine that handles 500 items and fails at 50,000 fails silently in the first rehearsal.

3. The final load during cutover. Nothing new should appear at this point. If something does, the fault is in rehearsal two, not in this one, and the correct response is to invoke the rollback plan rather than to improvise. What that plan looks like is covered in go-live night.

Who signs that the data is correct

A neglected question with an expensive answer: every file needs one named owner who signs it off.

The accountant signs the chart of accounts and the opening balances. The inventory manager signs the item master and the quantities. The sales manager signs the customer list and the credit limits. Each of them is signing that the content is correct, not that the file loaded.

Leaving the sign-off to “the team” means there is no owner. When the error surfaces after go-live, the migration itself is blamed instead of the file nobody reviewed, and the project spends a fortnight investigating a data question that a named person could have answered in an hour.

What to do today

• Write the list of files required and sort each into the decision table above: move, move as a balance, do not move.
• Put one name against each file.
• Start cleansing before the contract is signed, because it is the only work that needs no system.
• Write the number of rehearsal loads into the contract, rather than the word “migration”.

Where to go from here

Every file you migrate serves a specific cycle, and understanding the cycle is what tells you what the file is missing: the procurement cycle, order to cash, and inventory and costing. The logic behind every opening balance is in the ledger and the close. The full sequence is on the learn ERP page.

Import tooling varies more between products than almost anything else. What each system ships as ready-made importers, and what needs additional work, is set out in the systems comparison.