Data Migration Services
ERP migrations don’t fail on configuration
They fail on data. Fifteen years of customer, supplier and item records built up under different rules, different people and sometimes different companies — and the gap is usually found after the go-live date has been announced.
Why they slip
Three things that go wrong, every time
We have been on both sides of this — running the business that was migrating, and doing the migration. The pattern does not vary much.
Discovered late
Data problems surface in user acceptance testing, when the go-live date is already committed and the room is full of people.
No reconciliation
The load "succeeded" but nobody can prove the balances match, so finance will not sign.
Nobody owns the rules
Decisions get made in the moment by whoever is in the room, and are never written down.
The method
Six stages. You sign off stage two
Every mapping decision is written down and approved before anything runs, so a disagreement in month four is settled by a document rather than a meeting.
Profile
Read the actual source data and show you what is in it — not what the project plan assumed.
Map
Agree in writing what every field becomes in the new system. Your people sign it off.
Cleanse
Run the agreed rules. Duplicates merged, formats standardised, gaps identified.
Trial load
Load into the target for real. Reconcile back to the source, record by record.
Exceptions
Everything the rules cannot resolve, listed for a person. Nothing guessed.
Cutover
The final run, on the weekend it has to happen, with a reconciliation you can show the board.
Systems
System-agnostic, because the work is in the data
ERP, TMS, WMS and billing systems, plus the spreadsheets and legacy databases around them. The vendor changes; the mapping problem does not.
Already underway?
Coming in mid-project is common and usually starts the same way: profiling what is genuinely in the source systems. That is often the first time anyone has looked.
Every trial load
Three numbers, and the middle one decides your go-live
Each trial produces this, not a status report. The escalated records are the ones needing a decision from somebody in your business, and they are the reason cutover dates move.
The rule was unambiguous, so the record was transformed and logged.
Two rules could both apply. A person in your business decides which one wins.
The source record is not viable. Listed with the reason, never silently dropped.
Questions
Migration, answered
Usually on data rather than configuration. Fifteen years of customer, supplier and item records built up under different rules, different people and sometimes different companies do not fit a new system’s expectations, and the gap is found late, when the cutover date is already committed.
Profiling the source data, agreeing mapping rules with your people in writing, cleansing, trial loads, reconciliation against the source, and cutover support. You sign off the rules before anything runs, and every trial produces an exception list instead of a status report.
More than one, always. That is the argument for building a repeatable process at the start: if each trial means rebuilding the transformation by hand, the third trial costs as much as the first. If the rules are automated, the third trial costs an afternoon.
ERP, CRM, TMS, WMS, finance and billing systems, plus the spreadsheets and legacy databases that sit around them. The approach is system-agnostic, because the work is in the data and the rules, not in the vendor.
Yes, and this is common. Coming in mid-project usually starts with profiling what is actually in the source systems, which is often different from what the project plan assumed.
Talk to us