The short answer. Data migration testing is how you prove a migration actually worked, that the data moved completely, accurately, and without breaking the relationships between records. It combines pre-migration profiling, validation during the load, and reconciliation afterward that compares the target against the source. A migration is not finished when the load completes; it is finished when testing proves the result is correct.

A migration can complete without being successful. The load runs, the job reports done, and everyone moves on, only to find weeks later that records were dropped, values were mangled, or links were broken. Data migration testing exists to catch that before go-live, turning "the load finished" into "the data is provably right". Here is what it involves.

What data migration testing is

Data migration testing is the set of checks that confirm data has moved from source to target completely, accurately, and usably. It is not one activity but a series, running before, during, and after the migration. The aim is evidence: to be able to show, not just assert, that the migrated data matches the source and works correctly in the new system. In a migration to a critical platform such as S/4HANA, this evidence is what lets the business trust the new system from day one.

The main types of testing

Pre-migration profiling. Before anything moves, profile the source to understand its quality, so you know what you are migrating and can fix problems upfront.
Validation testing. During the migration, validate that extracted and transformed data meets business and technical rules, catching errors before they reach the target.
Reconciliation testing. After the load, compare the target against the source, confirming record counts match and values agree, so nothing was lost or altered.
Integrity testing. Confirm that relationships between records survived the move, so linked data still matches in the new system.
Business verification. Have the people who own the data confirm it looks right and processes run correctly against it.

Reconciliation is the proof

A completed load is a hope. A reconciled load is a fact.

Of all the testing types, reconciliation is the one that turns a migration from assumed-successful into proven-successful. It answers the question every stakeholder asks: can we trust the new system? By comparing the migrated data against the source, count by count and value by value, reconciliation provides the evidence that nothing was silently lost or changed. Without it, "done" rests on faith. With it, "done" rests on proof, and that proof is also the audit trail you will want later when someone asks why a figure looks the way it does.

Mock migrations as rehearsal

Testing is most valuable when it happens before the real cutover, which is why mock migrations matter. A mock migration is a full rehearsal of the extract, transform, and load against a copy of the target, with all the testing applied. The first mock run almost always surfaces problems, records that fail validation, mappings with gaps, volumes that take longer than planned. Each issue found in a rehearsal is one that does not surface during the real cutover, when the business is waiting and the window is fixed. Enough mock runs, each cleaner than the last, are how a team turns go-live from a gamble into a formality.

What to test, and how much

A practical question every migration faces is how much testing is enough, since testing every single record by hand is impossible at enterprise volumes. The answer is to combine automated, complete checks with targeted manual verification. Automated reconciliation can compare counts and values across the entire dataset, so completeness and accuracy are checked everywhere, not sampled.

Manual business verification then focuses on the areas that matter most: high-value records, complex transformations, and the objects most likely to cause problems, such as business partners and open items. This mix, automation for breadth and human judgement for depth, gives confidence across the whole migration without pretending a person can eyeball millions of rows.

When testing finds a problem

Finding a problem in testing is a success, not a setback, because it means the problem was caught before go-live rather than after. What matters is having a clear process for what happens next: the failing records are identified, routed to the people who can correct them, fixed, and re-tested. In many migrations this takes the shape of sending invalid records back to business owners for validation and correction, then reloading the corrected data and re-running the checks.

The aim is a repeatable loop, catch, correct, re-test, so that every issue testing surfaces is resolved and confirmed rather than argued over or waved through. A migration where testing finds problems and the team fixes them calmly is in far better shape than one where testing found nothing because no one really looked.

Testing creates your audit trail

Beyond proving the migration worked on go-live day, testing produces something valuable for later: a record of what happened to the data. Reconciliation results, validation outcomes, and the log of what moved, what changed, and what was rejected together form an audit trail that answers questions months after the event. When someone asks why a figure in the new system looks a certain way, or whether a particular record migrated correctly, that trail is the answer. This is why testing should be documented, not just performed. A migration that was tested but left no evidence forces you to re-establish trust every time a question arises; one that was tested and documented can simply point to the record.

How deKorvai helps

deKorvai builds testing into the migration itself. It profiles the source before migration to expose quality problems, validates data against business and technical rules throughout the pipeline, and reconciles the loaded data against the source so accuracy is proven rather than assumed. Because it preserves referential integrity through transformation, the relationships between records survive the move. For S/4HANA specifically, it loads into the Migration Cockpit (DMC or LTMC) staging tables with reconciliation built in, and supports the simulation and mock runs that let teams rehearse before the real cutover. In one documented business partner migration, this approach moved more than 50,000 vendor records with 100% data accuracy and a 95%+ first-pass rate.

Key takeaways

A completed load is not a successful one; testing is what proves success.
Test before, during, and after: profile, validate, reconcile, verify.
Reconciliation is the proof that nothing was lost or changed.
Mock migrations rehearse the real thing, so go-live is a formality.

Frequently asked questions

What is data migration testing?

Data migration testing is the set of checks that prove data moved from source to target completely, accurately, and usably. It runs before, during, and after the migration, and its purpose is evidence that the migrated data matches the source and works in the new system.

What are the main types of migration testing?

Pre-migration profiling to understand source quality, validation testing during the load, reconciliation testing that compares target against source, integrity testing that confirms relationships survived, and business verification by the people who own the data.

Why is reconciliation so important?

Because it turns a migration from assumed-successful into proven-successful. By comparing migrated data against the source count by count and value by value, reconciliation provides evidence that nothing was lost or altered, and creates the audit trail you will need later.

What is a mock migration?

A mock migration is a full rehearsal of the extract, transform, and load against a copy of the target, with testing applied. It surfaces problems before the real cutover, so each issue found in rehearsal is one that does not disrupt go-live.

Data Migration Testing: How to Prove Your Migration Worked