There’s a question that doesn’t get asked often enough at the end of a data migration project, and the reason it doesn’t get asked is that the answer is uncomfortable.
Not “did the data move?” That one gets asked and answered, usually with confidence, usually at the point of go-live. The question that tends not to get asked is the more important one.
Can you actually trust it?
For most organisations that have been through a migration, the honest answer is that they’re not entirely sure. They know the data is there. They know the system is live. They know the project closed. What they don’t always know – what the standard migration validation process often doesn’t tell them – is whether what arrived in the new environment is complete, accurate, and behaving the way it’s supposed to.
That gap between “the data moved” and “the data works” is where a specific and costly category of problem lives. And it tends to stay hidden just long enough to become very expensive to fix. It is also widespread: Gartner has long reported that 83% of data migration projects either fail outright or exceed their budgets and schedules, with cost overruns averaging 30% and time overruns 41% – numbers that have proved remarkably resistant to industry experience and improved tooling[1].
Why migration projects get signed off before they’re actually finished
Migration projects operate under pressure. There are timelines, there are budgets, there are stakeholders waiting for the new system to go live, and there is a natural organisational momentum towards declaring success and moving on. The work of extracting, transforming, and loading data is intensive and highly visible. When it’s done, the temptation to treat completion as validation is almost irresistible.
The testing that happens in most migrations is focused on the right question but not quite the full question. It asks: Is the data there? Record counts are checked. Key fields are spot-checked. The system runs. Reports generate. On the basis of that, the migration is declared successful.
What it typically doesn’t ask with the same rigour is whether the data is right. Whether the relationships between datasets transferred correctly. Whether values that existed in one format in the legacy system are behaving as expected in a different format in the new one. Whether the business rules that governed how data was used in the old environment still apply correctly in the new one. Whether the data, when put under the pressure of real operations rather than test scenarios, actually does what the organisation needs it to do.
These are different questions. And answering them requires a different kind of work – work that tends to get deprioritised because the project timeline doesn’t accommodate it and because, on the surface, everything looks fine. Data quality is a major contributor to the failure rate: research has found that a substantial proportion of organisations cite data quality issues as a primary cause of migration delay, with poor source data slowing the entire migration process and proving incompatible with the stricter standards of newer systems[1].
What fine looks like before it doesn’t
The particular challenge with migration data quality issues is how long they can remain invisible.
In the weeks immediately after go-live, the system is new and unfamiliar. Users are adjusting. Processes are being relearned. When something doesn’t look quite right, the natural assumption is that it’s a user issue or a configuration issue or just the adjustment period that everyone expected. The possibility that the underlying data is wrong doesn’t always surface quickly, because the signals are subtle and the context is noisy.
What tends to happen instead is a gradual accumulation of doubt. Reports that should align don’t, and the explanation isn’t immediately obvious. A process that worked smoothly in the legacy system requires unexpected workarounds in the new one. A dataset that was supposed to provide a clean foundation for analytics turns out to have inconsistencies that nobody noticed in testing because the test scenarios didn’t replicate the complexity of real operations.
None of these is a crisis in isolation. But the cumulative effect on confidence in the new system is significant – and once users lose trust in the data, that trust is very difficult to rebuild. People start maintaining parallel records to compensate for what they don’t trust in the system. They build workarounds that introduce their own inconsistencies. The complexity that the migration was supposed to reduce starts to reassemble itself around the gaps in the data.
And then someone looks closely at the underlying data and finds what the validation process didn’t catch. At which point the organisation faces a choice between living with the problems – managing around them indefinitely – or going back into the data to fix them in a live environment that people are actively depending on. Both options are expensive. Neither is what the business case anticipated. Gartner puts the average annual cost of poor data quality at $12.9 million per organisation[2] – a figure that compounds quickly when poor quality is baked into a freshly migrated system that the rest of the business has already started building on top of.
What data reconciliation actually means – and why it’s not the same as testing
The term reconciliation gets used loosely in the context of migration, sometimes as a synonym for testing and sometimes as an afterthought that happens after go-live when problems have already surfaced. Neither of these is what it actually means or what it’s actually for.
Data reconciliation, done properly, is the systematic process of comparing source and target datasets at a level of detail that goes beyond record counts and spot checks – and doing it at a point in the migration where discrepancies can still be resolved before they affect live operations.
That means comparing not just whether records exist in both environments, but whether the values within them are consistent. Whether relationships between tables and datasets have transferred correctly. Whether calculated fields are producing the same outputs in the new system as they did in the old one. Whether data that was transformed as part of the migration has been transformed correctly and completely. Whether the edge cases (the records that didn’t fit neatly into the standard migration logic) have been handled in a way that preserves their integrity rather than silently distorting them.
It also means testing how data behaves under real business conditions, not just whether it’s present in the system. A record that passes a structural check can still fail a business logic check. A dataset that looks complete in isolation can produce incorrect outputs when it interacts with another dataset it was supposed to align with. The only way to catch these issues before they become operational problems is to test the data the way the business will actually use it – not just the way the migration specification defined it.
This is the work that most migration validation processes don’t do thoroughly enough. Not because the teams involved don’t know it’s important, but because it takes time that isn’t always built into the plan and requires a depth of understanding about how the data is actually used in the business that the technical migration team doesn’t always have.
The specific places reconciliation finds what testing misses
It’s worth being concrete about the categories of issue that proper reconciliation surfaces and standard testing doesn’t, because this is where the business case for investing in it properly becomes most tangible.
Duplicate records are one of the most common. Legacy systems accumulate duplicates over time in ways that aren’t always obvious – the same customer under two slightly different name formats, the same transaction recorded against two different reference numbers, the same asset appearing in two different system modules. Migration processes that don’t explicitly identify and resolve duplicates before moving data carry them into the new environment, where they create confusion and incorrect reporting that can take months to unpick.
Silent data loss is another. Record counts matching between source and target doesn’t mean all records transferred correctly, it means the right number of rows exist. Records that transferred with key fields blank, or with values replaced by defaults because the transformation logic didn’t handle a particular data type correctly, won’t show up in a volume check. They’ll show up later, when someone tries to use the data and finds it incomplete in ways that aren’t immediately explicable.
Relationship breaks are particularly damaging in complex data environments. A customer record that migrated correctly but whose relationship to their associated transactions didn’t transfer properly. An asset record that exists in the new system but is no longer connected to the maintenance history that should sit against it. These breaks are invisible until someone tries to follow the relationship. And in operational contexts, they can cause significant disruption before anyone understands what’s actually wrong.
And then there are the business logic failures: the cases where the data is technically present and structurally correct but produces wrong outputs because the rules governing how it behaves in the new system weren’t fully mapped from the old one. These are the hardest to catch and the most disruptive when they surface, because they look like system errors rather than data errors and can send troubleshooting in entirely the wrong direction.
What the organisations that get this right do differently
The distinction between organisations that emerge from migrations with data they can trust and those that spend the months afterwards firefighting comes down to a decision about when validation happens and what it covers.
The organisations that get it right build reconciliation into the migration process as a defined phase with its own resource, its own timeline, and its own success criteria; not a final check that happens under pressure when everything else is done. They define what “correct” looks like for each dataset before they start moving data, so they have a standard to test against rather than discovering what the standard should have been after the fact. This aligns with Gartner’s published best practice guidance, which now structures successful migrations across distinct planning, design, development, and delivery phases rather than treating reconciliation as a sign-off step[3].
They involve people who understand how the data is actually used in the business – not just how it’s structured – in the validation process, so that tests reflect real operational scenarios rather than just technical specifications. And they treat the reconciliation outputs not as a sign-off exercise but as a feedback loop, using what they find to improve the migration before go-live rather than documenting it for future reference.
The difference in outcomes is significant. Migrations approached this way go live with data that the organisation can trust from day one. The system performs as expected. Users adopt it without the nagging doubt that something isn’t quite right. The return on the investment starts to materialise at the pace the business case assumed.
How Dajon supports migration reconciliation
At Dajon Data Management, data reconciliation is one of the most critical parts of the migration work we do with clients – and it’s where we consistently find the issues that would otherwise surface after go-live.
We work with organisations to define what complete and accurate looks like for their specific data before migration begins, build reconciliation into the process as a structured phase rather than an afterthought, and test data against real business scenarios rather than just technical specifications. For complex migrations involving multiple legacy systems or large data volumes, we provide the depth of scrutiny that standard testing processes typically don’t reach.
The goal isn’t to find problems for their own sake. It’s to find them at the point in the process where they can still be fixed cleanly – before they’re embedded in a live system that people are depending on, and before the cost of fixing them is a multiple of what it would have been earlier.
A different definition of done
Migration projects need a better definition of success than “the data moved.”
Data that has moved but can’t be trusted doesn’t support the processes it’s supposed to support. It doesn’t enable the reporting it was supposed to enable. It doesn’t deliver the operational improvement that justified the investment. What it delivers instead is a system that functions on the surface and creates doubt underneath. And doubt, once established in a data environment, is remarkably persistent.
The organisations that avoid this outcome have asked a harder question at the end of their migration than most. Not “is the data there?” but “can we stand behind it?” And they’ve done the work – the reconciliation, the validation against real scenarios, the scrutiny of the edge cases – that means when they answer yes, they mean it.
Do you know your migration worked – or are you assuming it did?
Dajon Data Management helps organisations validate and reconcile migrated data so they can go live with genuine confidence in what’s in their new system. Get in touch to understand where your current validation process might be leaving questions unanswered.
References
- 83% of data migrations fail or exceed their budgets and schedules Gartner via Experian[↩][↩]
- Data Quality: Why It Matters and How to Achieve It Gartner[↩]
- 5 Common Data Migration Challenges and How to Solve Them Bluesource, summarising Gartner’s 15 Best Practices for Successful Data Migration, April 2025[↩]