In every other migration tool, failures are bad news. In a proof-based system, failures are the most valuable output — because each one is a diagnosed, remediable, prioritised finding that tells you exactly what to fix and exactly why.

When a migration assessment produces a list of records that cannot be migrated, the typical reaction is concern. Failures feel like bad news. A high failure rate feels like a problem with the data, the mapping, or the tool.

This reaction is understandable. It is also backwards.

A record that fails a bijective proof is not a defect in the assessment. It is a discovery — a specific, diagnosed, remediable finding that would otherwise have surfaced on cutover weekend at ten to fifty times the cost to fix. Every untransformable record found before cutover is a cutover-weekend failure prevented. Every untransformable record missed is a cutover-weekend failure waiting.

The question is not "how do we reduce the failure count?" The question is "how do we find every failure before cutover — and know exactly how to fix each one?"

What makes a record untransformable

A record is untransformable when the bijective proof cannot be satisfied — when f⁻¹(f(x)) ≠ x for one or more fields. This means the roundtrip transformation does not recover the original. Something was lost, collapsed, or defaulted during the transformation, and the loss is detectable.

There are specific categories of untransformability, each with a different root cause and a different remediation:

Invalid source values. The source field contains a value that is not valid in the target system's configuration. A country code that predates ISO standardisation. A unit of measure that is locally defined but not internationally recognised. A payment term that exists in the source configuration table but has no equivalent in the target. These records cannot be transformed losslessly because the source value has no clean mapping — any transformation would require an assumption, and assumptions are what the proof is designed to prevent.

Collapsed classifications. Two or more distinct values in the source map to the same value in the target. The transformation is technically possible — both source values can be converted to the single target value. But the inverse cannot recover the distinction. If "TRADE" and "ONE-TIME" both map to "VENDOR," then given "VENDOR" in the target, the inverse cannot determine whether the original was "TRADE" or "ONE-TIME." The function is not injective. The proof fails.

Missing dependencies. The record itself may be perfectly transformable, but an object it depends on is not. A purchase order that references an untransformable supplier inherits the failure — not because the PO data is bad, but because its upstream dependency is unresolved. These cascade failures are flagged differently: the PO is not the root cause, and fixing the PO will not help. The supplier must be fixed first.

Configuration mismatches. The combination of values across multiple fields creates a configuration state that does not exist in the target system. Each field individually is valid. Together, they form a combination that the target does not recognise. A material type plus planning profile plus storage location that has no valid intersection in the target plant configuration. These are the hardest failures to catch with field-level validation, because each field passes its own check — only the combination fails.

Why untransformables are commercially valuable

Here is the counterintuitive insight: the more untransformable records the proof finds, the more valuable the assessment.

If the proof finds zero untransformables, the assessment confirms what the mapping coverage dashboard already suggested: everything looks fine. That is useful but not revelatory.

If the proof finds forty-eight untransformables — with per-record, per-field diagnosis and specific remediation — then the assessment has produced something that no other process in the programme has: a complete, prioritised remediation plan that tells the programme team exactly where to focus before cutover.

And the cascade analysis adds another dimension. If two of those forty-eight records are root causes that cascade to block thirty-six others, then the remediation priority is clear: fix two records and seventy-five percent of the problem resolves. That insight — which root cause to fix first — is worth more than the proof score itself, because it converts a potentially overwhelming remediation effort into a focused, tractable task.

This is why we call untransformable records a commercial asset, not a defect. In a proof-based model:

The Intelligence Report that says "forty-eight records failed, here is every one of them with the exact fix" is a stronger deliverable than the report that says "everything passed." The customer with forty-eight untransformables knows exactly what to do next. The customer with zero findings knows nothing new.

The anatomy of an untransformable report

A properly structured untransformable report contains five elements for every failed record:

1. Record identity. Which object, which key. Supplier 100456. Material MAT-2281. PO 4500019331. The team needs to find this record in their source system.

2. Failing field. Which specific field caused the proof failure. COUNTRY. PAYMENT_TERMS. UNIT_OF_MEASURE. Not "the record failed" — which field, specifically.

3. Source value. What value the field currently holds. "UK". "ZCUS". "PCS". The team needs to see what they are working with.

4. Failure reason. Why the value is untransformable. "Not valid ISO 3166-1 alpha-2." "Not present in target payment terms configuration." "Not a recognised ISO unit of measure." The reason should be specific enough to suggest the fix.

5. Remediation action. What to do about it. "Change to GB in source system." "Map to ZN60 or create ZCUS in target configuration." "Map to EA (ISO standard each)." The remediation should be actionable — not "investigate further," but "change this specific value to this specific alternative."

For cascade failures, the report adds:

6. Root cause reference. "This PO is blocked because Supplier 100456 is untransformable. Fix Supplier 100456 (COUNTRY='UK') and this PO will be unblocked automatically."

7. Cascade count. "This root cause blocks 12 POs, 8 GRs, 8 invoices — 29 objects total."

Prioritisation: the blast radius approach

Not all untransformable records are equally important. A supplier with an invalid country code that blocks twenty-nine downstream objects is more urgent than a material with a non-standard unit of measure that affects only itself.

We prioritise remediation findings by blast radius — the total number of downstream objects that would be unblocked if this root cause were fixed.

Priority  Root cause              Blast radius  Fix
──────────────────────────────────────────────────────────────
   1      Supplier 100456         29 objects    COUNTRY: UK → GB
          COUNTRY = "UK"          (12 POs, 8 GRs, 8 INVs)

   2      Supplier 100891         7 objects     PAY_TERMS: ZCUS → ZN60
          PAY_TERMS = "ZCUS"      (3 POs, 2 GRs, 2 INVs)

   3      Material MAT-2281       1 object      UOM: PCS → EA
          UOM = "PCS"             (self only)

   ...

Fixing priority 1 resolves twenty-nine of forty-eight failures. Fixing priorities 1 and 2 resolves thirty-six of forty-eight — seventy-five percent. The remaining twelve are direct field-level issues with no cascade impact, fixable in any order.

This prioritisation transforms the remediation conversation from "we have forty-eight problems" to "we have two problems that matter most, and fixing them resolves three-quarters of everything." That is a conversation a programme director can act on immediately.

The chartered vehicle principle

We use a phrase internally: bad data does not board the vehicle.

In aviation, a pre-flight checklist exists for a reason. An aircraft does not take off with a known mechanical issue and plan to fix it in the air. The issue is identified, diagnosed, and resolved on the ground — where the cost of remediation is low and the risk of failure is zero.

The same principle applies to data migration. A record with a known transformation failure should not be loaded into the target system with a plan to "fix it after go-live." Fixing it after go-live means fixing it in production, under pressure, while users are trying to work, and while the cascade effects are propagating through every process that touches the record.

The proof engine is the pre-flight checklist. It identifies every untransformable record before loading. It diagnoses the failure. It prescribes the fix. And it quantifies the cascade impact of not fixing it. The programme team can then make an informed decision: fix it before migration, accept the risk and exclude it from scope, or defer it with full knowledge of the downstream consequences.

What the team should never do is migrate it without knowing it will fail. That is the scenario the proof prevents.

What this means for your programme

If your migration programme is producing test-load results, those results tell you which records loaded and which did not. They do not tell you why the failures happened, what to do about them, or how many other records are affected by the same root cause.

If your programme is not producing any assessment at all — if it is relying on mapping coverage as the measure of readiness — then the untransformable records exist in your data right now, undiagnosed, waiting for cutover weekend.

The proof does not add work. It prevents work. Every untransformable record found before cutover is a remediation task that can be planned, prioritised, and executed calmly. Every untransformable record found on cutover weekend is a crisis.

We would rather hand you a report with forty-eight findings and a clear remediation plan than a report with zero findings and a false sense of security. The findings are the value. The diagnosis is the value. The cascade prioritisation is the value. The clean bill of health is just the absence of findings — and the absence of findings from a two percent sample tells you very little about the other ninety-eight percent.

migrationproof.io — launching shortly. First release: SAP ECC-to-S/4HANA. The mathematics applies everywhere.

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.

We read every message. We reply to every question.

← PreviousWhat Migration Costs