Mapping coverage is a progress metric, not a safety metric. The five percent you have not examined contains eighty percent of your cutover-weekend failures. This applies to every system migration — the examples here are from SAP.
Somewhere in your programme, there is a dashboard showing ninety-five percent mapping coverage. It is green. The steering committee looked at it last Thursday and felt reassured. The programme director referenced it in an email to the CFO. Ninety-five percent. Nearly there.
Here is what that number does not tell you: whether the transformation is lossless. Whether meaning survives the move. Whether a record that enters the mapping kernel emerges on the other side with every field, every relationship, and every business distinction intact — or whether something was quietly dropped, collapsed, or defaulted to a value that will break a process six months after go-live.
Last year, a European manufacturer reported ninety-seven percent mapping coverage three weeks before cutover. Their migration dashboard was solid green. On cutover weekend, twenty-three thousand purchase orders failed validation in the target system. The root cause: two supplier classifications — trade vendors and one-time vendors — had been mapped to the same grouping in the target. The mapping was complete. It was not lossless. The downstream purchasing process depended on that distinction. The mapping team had checked the box. The business logic had lost a signal. And the programme lost four weeks.
A green dashboard is often just a spreadsheet's way of saying nobody asked a harder question.
Coverage is not safety
Mapping coverage measures how many fields have been assigned a target. It answers the question: have we decided where each field goes? This is a necessary question. It is not a sufficient one.
Migration safety measures whether the transformation preserves meaning. It answers a different question: does the data survive the move? A field can be mapped to a target and still lose information in transit. A record can pass through a mapping kernel and arrive in the target system structurally complete but semantically wrong.
The gap between coverage and safety is where migrations fail. And the gap is invisible to any metric that counts mappings instead of testing transformations.
We have a specific term for what most programmes are missing: transformation integrity. A transformation has integrity when three conditions hold:
Lossless: no information is discarded. If two distinct source values exist, two distinct target values must exist. If a classification carried business meaning in the source system, it must carry the same meaning in the target.
Reversible: the transformation can be undone. If you take the target record and reverse the mapping, you must recover the original source record exactly. This is the mathematical test — f⁻¹(f(x)) ≡ x — that the transformation is bijective, not just directional.
Chain-complete: the transformation respects dependencies. A purchase order cannot exist without its supplier. A goods receipt cannot exist without its purchase order. We call this dependency-chain integrity — and a mapping that ignores it will produce records that load successfully in isolation and fail catastrophically in integration.
Coverage asks: is every field assigned? Transformation integrity asks: does every record survive? These are not the same question. And only one of them predicts cutover success.
Four ways "mapped" data fails silently
When a programme reports ninety-five percent mapping coverage, the remaining five percent is typically labelled "in progress" or "deferred." But the real risk is not in the unmapped five percent. It is in the mapped ninety-five percent — the records that have been assigned a target but have not been tested for transformation integrity.
Lossy transformations. Two distinct values in the source collapse into one value in the target. The mapping is technically complete — both values have a target — but the distinction is lost. Example: two supplier classifications — trade vendor and one-time vendor — both mapped to the same grouping. Procurement loses the ability to distinguish them. Every purchasing report that relied on that distinction is silently wrong from day one.
Broken dependency chains. A supplier is migrated, but its purchasing organisation assignment is missing. The supplier exists in the target. The purchase order references it. But when the PO is created, it fails — the supplier has no valid purchasing organisation for that company code. The supplier is present. The PO cannot be posted. The goods receipt cannot follow. The invoice has nothing to reference. One missing link and every object downstream is blocked.
Default-masked gaps. A field in the source is null or non-standard. The transformation assigns a default — immediate payment terms. The record loads. Six months later, four hundred suppliers are on immediate payment terms who should be on sixty-day terms. The company has been paying invoices on receipt instead of holding cash for two months. Millions in working capital left the business sixty days early, every month, for a year. Nobody connects it to a default assigned during migration. The transformation did not fail — it lied. And the lie cost real money every day it went undetected.
Loaded-but-not-usable records. A material master loads with all mandatory fields. But the combination of material type, planning profile, storage location, classification, and characteristics creates a configuration that does not exist in the target plant. The material cannot be used in a production order. Worse — when downstream processes reference it, the invalid configuration propagates. A bill of materials inherits it. A production order references the BOM. A goods movement attempts to post against a storage location the plant does not recognise. The corruption spreads. The material is technically migrated, operationally useless, and actively poisoning the data around it.
Every one of these failures passes the mapping coverage check. Every one produces a green row on the dashboard.
The question your dashboard cannot answer
The fundamental problem is not that programmes fail to map their data. Most programmes map diligently. The problem is that mapping is treated as the end of the data workstream rather than the beginning.
A mapping decision is a hypothesis. The question is whether anyone tests it. Until you verify that every mapped value can be reversed without ambiguity — and that every record carrying that value produces the expected target value and not a default — the hypothesis is untested.
The question your dashboard cannot answer is: if I take every mapped record, transform it, and reverse the transformation, do I get back exactly what I started with?
If yes, the transformation is lossless. If no, something was lost. And whatever was lost is exactly what will break on cutover weekend.
This is the reverse proof. It is not a new concept in mathematics. It is new in data migration. And it is the only test that converts a mapping hypothesis into a transformation proof.
What migration safety actually looks like
A migration is safe when three things are true simultaneously:
Every transformation is lossless. For every record, the forward transform followed by the reverse transform recovers the original. No information discarded. No distinctions collapsed. f⁻¹(f(x)) ≡ x. If this holds, the transformation is bijective — provably correct, not probably correct.
Every dependency chain is complete. No record is loaded into the target without all of its upstream dependencies already present. Supplier before PO. PO before goods receipt. Goods receipt before invoice. This is structural integrity. Break the chain and the target system rejects the record.
Every untransformable is diagnosed before cutover. Records that cannot survive the lossless transformation are identified, quarantined, and reported with a specific root cause and remediation path. Not after UAT. Not during cutover. Before any transformation is attempted. We call these records untransformables — and they are the most valuable findings your migration programme will ever produce, because they tell you exactly what needs to be fixed and exactly why.
This is transformation integrity. It is measurable, verifiable, and — critically — it does not require trust in the person who ran it. The proof is self-verifying. Anyone can check it. A mapping is an opinion. A lossless transformation proof is a mathematical fact.
What to do about it
If your programme is reporting high mapping coverage, the next question is simple: is the transformation actually lossless?
You do not need to take our word for it. You do not need to book a demo or attend a workshop. You need to see your own data.
Migration Proof runs a read-only diagnostic on your data extract. You download a short extractor report, run it against your source system with one hundred invoices selected, and upload the output. The engine walks the dependency chain, expands every related object, checks every precondition, and runs the reverse proof on every record. In under twenty minutes, you see:
— Which records are provably lossless — Which dependency chains are intact and which are broken — Which records are untransformable, with the exact field and the exact reason — What percentage of your data is genuinely safe, not just mapped
No writes to your source system. No production access required. No consultants. Just mathematics applied to your data.
The mapping dashboard tells you how far your programme has come. The transformation proof tells you whether your programme will succeed. One of those takes months and costs six figures. The other takes twenty minutes and costs a fraction. migrationproof.io
Launching shortly. First release covers SAP ECC-to-S/4HANA. The mathematics applies to any system-to-system transformation.
A note from us
Migration Proof is an AI-native operation. Five specialised AI personas run the chain walk, precondition checks, transformation, proof, and reporting. Behind them, twenty-five years of enterprise system experience shaped every rule they apply.
We are mostly agents — and we are proud of that, because agents prove every record, not a two percent sample. When you write to us, a human replies.
[email protected]We read every message. We reply to every question.