By Ritvars Mētra, Founder of ReadinessCompassThe migration report is green. 1,284,006 records extracted, 1,284,006 loaded, reconciliation balanced to the record.
Three weeks after go-live, a customer service adviser is maintaining her own spreadsheet of delivery addresses, because roughly one in six of the addresses in the system is the invoicing address rather than the delivery one, and she has no way of telling which.
The migration was correct. It moved exactly what it was asked to move. The problem is that nothing in the plan asked whether the data was any good.
Reconciliation is not validation
Volume reconciliation proves that nothing was lost in transit. It says nothing about whether the content is usable, correctly classified, still current, or meaningful to the person who has to act on it.
That second judgement cannot be made by the migration team, because it requires knowing the business. Whether a customer marked as active in 2019 is still a customer is not a technical question, and the only people who can answer it are the ones whose time was never allocated to the migration workstream.
Markus and Tanis list inadequate attention to data cleanup among the characteristic errors of the project phase, and data input errors among the problems that then surface after go-live. The two are connected: bad migrated data produces bad manual correction, which produces more bad data.
The three people problems
| Problem | Why it is not technical | What it needs |
|---|---|---|
| Nobody owns the data | Master data has been shared between three functions for a decade, and none of them decides | A named owner per data domain, agreed before cleansing starts |
| Cleansing needs judgement | “Is this duplicate the same company?” requires knowing the account, not a matching rule | Released business time, scheduled, months before cutover |
| Users do not trust the result | One visible error persuades people the whole set is unreliable | Visible validation by their own colleagues, not an assurance from the programme |
The third is the one with adoption consequences. Trust in data is asymmetric — a single wrong price or wrong address discovered in front of a customer does more damage than a hundred correct records repair. Once a team concludes the data cannot be relied on, they build a parallel record, and the spreadsheet that appears is a data trust symptom rather than a training failure.
Cleanse early and incrementally
The default pattern is to cleanse late, in a compressed window, as a one-off exercise driven by the migration schedule. It is the most expensive available option and it produces the least reliable result, because the people doing it are under time pressure and making judgement calls at volume.
The National Audit Office recommends the opposite approach for exactly this reason, advising bodies to address data issues in a planned and incremental way, to reduce the need for costly manual exercises.
Incremental in practice means cleansing in the source system, starting a year out, in small scheduled blocks owned by the business rather than the programme. It has a second advantage that is rarely counted: the data improves whether or not the programme succeeds, so the effort is not contingent on a go-live date.
Validate with the people who will use it
Business validation of migrated data is usually a sign-off form sent to a manager who cannot realistically check anything. A more useful version takes half a day per function:
- Give people their own records. Not a random sample — their twenty accounts, the materials they handle, the suppliers they call. They will spot errors in minutes that no rule would catch.
- Ask them to complete a real task with it, rather than to review a spreadsheet. Errors that matter surface in use.
- Record what they found, and fix a visible portion of it before go-live. This is the part that builds trust: people believe data they have seen corrected.
- Publish what is known to be imperfect. “Delivery addresses for accounts dormant since 2021 have not been verified” is far better than silence, because it tells people where to look rather than leaving them to distrust everything.
The last point matters more than it seems. A known and bounded data problem is manageable. An unknown one produces general suspicion, and general suspicion produces spreadsheets.
Data migration is measured as a technical deliverable and experienced as a trust event. Getting the reconciliation right is necessary; it is the business judgement, the named ownership and the visible validation that determine whether anyone uses the result.
More on readiness evidence before go-live in the ERP Readiness Hub, or read why business and technical readiness are different claims.