Ask a company that has just finished an ERP implementation where the schedule went, and the answer is rarely configuration. It is the data: article masters with three conventions layered on top of each other, customers who exist four times, stock figures that have been quietly wrong for years, and open items nobody can explain.
None of that is visible when the plan is written, because the plan assumes the data describes reality. It usually describes a decade of workarounds.
Why does data migration overrun so often?
Because the effort is not in moving records, it is in deciding what they should be. Every duplicate customer, obsolete article and unexplained open item needs somebody with authority to say what the correct value is, and those decisions arrive one at a time from people who have other jobs. The extract-transform-load itself is usually a few days of work.
Plan the calendar around the decision rate, not the record count.
The four categories, in the order they hurt
Master data — customers, suppliers, articles, bills of material. Highest value, worst condition, and the only category where cleaning is unambiguously worth it. Cleaning happens in the source system, by the people who own the records, starting long before the new system exists.
Open transactions — orders, invoices, stock. Must be exact at cut-over, which makes them a logistics problem rather than a data-quality one: the answer is a freeze window and a reconciliation, not a transformation script.
History — closed years. This is where scope quietly doubles. Migrating five years of transactional history into the new system is expensive, slows the target, and is almost never needed. Keep the old system readable, or export to a data store, and migrate balances only.
Configuration-adjacent data — tax codes, units, price lists, account mappings. Small volume, disproportionate blast radius. One wrong tax code discovered in month two is worse than a thousand missing article descriptions.
How much history should you actually migrate?
Balances plus the current year, in most cases. Statutory retention in Switzerland is ten years for business records, but retention means the records remain readable and auditable — not that they live inside the new ERP. A read-only archive of the old system, or an export, satisfies it at a fraction of the cost.
Confirm the retention scope against Fedlex and your auditor before deciding, then write the decision down so it is not reopened monthly.
What the sequence should look like
| Stage | When | What it produces |
|---|---|---|
| Profile the source | Before vendor selection | How bad it actually is, in counts |
| Assign ownership | Immediately after | One named person per data domain |
| Clean in the source | Continuously, from week one | Value even if the project is cancelled |
| First trial load | As early as the target allows | The real error list, not an estimate |
| Repeat loads | Every two to three weeks | A falling error count you can chart |
| Reconciliation | Each load | Signed off by finance, not by IT |
| Cut-over load | The freeze window | A rehearsed procedure, not a first attempt |
The item that most often gets skipped is the early trial load. Teams wait until the configuration is finished, which means the first honest picture of data quality arrives with no time left to act on it. Load badly, early, on purpose.
The rule that saves small teams
Clean in the source system, not in the migration. Cleaning inside the transformation means the fix exists only in a script that runs once, the old system stays wrong during parallel running, and nobody else can see or verify the work.
Cleaning in the source means the improvement is real immediately, your own people do it in their normal tools, and if the programme slips a quarter you still keep the benefit. For a company without a data team, that difference decides whether the work gets done at all.
Who signs it off
Finance reconciles balances. Operations confirms stock and open orders. Neither signature belongs to IT, and neither should be given on a summary — it should be given on a comparison the signer can reproduce.
This is the same organisational constraint that determines the whole programme's pace, described in why ERP programmes stall. And if you are still deciding whether to move at all, the signals are in when a small company actually needs an ERP.
Our ERP practice treats migration as the first workstream rather than the last, because it is the one that sets the date.
Related reading
- When does a small company actually need an ERP?
- Why ERP programmes stall in Swiss mid-market companies
- ERP selection for the Swiss mid-market
Working on this right now?
Tell us where you are in two questions. A consulting partner reviews every enquiry within 2 business days.