The economics of data migration have not changed in twenty years. The work has. If the assessment is mathematical — not manual — what does that do to the cost equation?
A typical enterprise migration assessment costs somewhere between a hundred thousand and half a million pounds. The number varies by system size, scope, and the system integrator's day rate. But the structure of the cost is always the same: people, multiplied by time.
Consultants for discovery workshops. Analysts for mapping spreadsheets. Testers for load cycles. Programme managers for coordination. Status report writers for the steering committee. Each of these roles has a day rate. Each activity takes weeks. The total accumulates over three to six months, and by the time the assessment is complete, the programme has spent a significant portion of its budget before a single record has been migrated.
This is not a criticism. It is an observation about structure. The cost is high because the work is manual. The work is manual because it has always been manual. And it has always been manual because nobody built the alternative.
The question worth asking is: what should the cost be if the work is mathematical instead?
Where the cost actually goes
In a traditional migration assessment, the budget distributes roughly like this:
Discovery (25-30% of cost). Workshops to understand the source system landscape. Interviews with data owners. Documentation of object types, field structures, and business rules. This work produces the input for mapping.
Mapping (20-25%). Building the field-by-field mapping specification. Source field A maps to target field B. Value X in the source becomes value Y in the target. This is typically maintained in spreadsheets, reviewed by business analysts, and iterated over multiple rounds.
Test loads (25-30%). Loading sample data into a sandbox environment. Debugging failures. Adjusting mappings. Reloading. This cycle typically runs two to four times before the team is satisfied that the sample loads cleanly.
Reporting and coordination (15-20%). Status reports, steering committee presentations, risk assessments, and the final assessment report that says "we are ready" or "we are not."
Each of these activities is necessary under the traditional model. But each one contains a structural inefficiency: it is discovering, through human effort, something that is already knowable.
What is knowable in advance
The mapping rules for enterprise system migrations are not infinite. For any given source-to-target pair, the object types are finite. The field structures are documented. The API constraints are published. The dependency relationships are structural. The valid value sets are configured in the target system.
A consultant who spends four weeks in workshops is discovering rules that the systems already contain. An analyst who spends three weeks building a mapping spreadsheet is encoding transformations that the API specifications already define. A tester who spends six weeks running load cycles is verifying — through trial and error — preconditions that are formally checkable.
This is not a criticism of the people doing the work. They are skilled, diligent, and working within the only model available to them. The observation is about the model, not the people: the cost is proportional to human effort, and much of that effort is discovering what is already deterministic.
If you encode the mapping rules into a kernel — forward and inverse transforms for every object type — and encode the preconditions into a validation engine — formal checks against ISO standards, configuration tables, and referential integrity — then the discovery phase, the mapping phase, and the test-load phase are all replaced by a single computation.
Not a faster version of the same work. A structurally different kind of work.
What changes when the work is mathematical
When the assessment is a computation rather than a consulting engagement, several things change:
Time compresses from months to minutes. Not because the engine is faster at doing the same thing, but because it eliminates activities that exist only because the traditional process requires humans to discover deterministic rules. There is no discovery workshop when the kernel already knows the mappings. There is no test-load cycle when the bijective proof verifies every record mathematically.
Coverage goes from two percent to one hundred percent. The traditional model samples because full coverage is too expensive with human effort. The mathematical model processes every record because the marginal cost of one more record is near zero. A proof engine that verifies one record can verify a million records in the same architectural pass — only the wall-clock time changes, and it changes linearly.
Quality shifts from probabilistic to provable. A test-load tells you that a sample passed. A bijective proof tells you that every record either passed or failed, with a specific diagnosis for every failure. The output is not "the migration looks ready." The output is "799 of 847 records are provably lossless, and here are the 48 that are not, with the exact reason and remediation for each one."
Cost follows the structural change. If the work that took three to six months now takes minutes, and the coverage that was two percent is now one hundred percent, and the quality that was "we think it is ready" is now "here is the mathematical proof" — then the cost basis is fundamentally different.
What the customer actually pays for
Under the traditional model, the customer pays for time — person-days multiplied by a day rate. The deliverable is an assessment report, but the cost driver is elapsed effort.
Under the mathematical model, the customer pays for an outcome: a complete, per-record proof of transformation integrity, with diagnosed findings and specific remediations. The time is minutes, not months. The effort is computational, not human. The deliverable is not an opinion about readiness — it is a proof.
This reframes the pricing question. The relevant comparison is not "how many person-days did this take?" but "what is the value of knowing — with mathematical certainty — which records will fail on cutover weekend?"
For a programme with a two-hundred-million-pound budget and a fixed cutover date, the value of that knowledge is substantial. Finding forty-eight untransformable records before cutover — with specific root causes and remediation paths — prevents the four thousand nine hundred sixty failures that sampling would have missed. The cost of those failures on cutover weekend (emergency remediation, extended downtime, potential rollback) dwarfs the cost of the proof that would have caught them.
The fiduciary question
There is a sharper way to frame this. If a read-only diagnostic can identify the same issues — with higher coverage and mathematical certainty — in a fraction of the time and at a fraction of the cost of a traditional assessment, then the decision to not run the diagnostic is itself a risk decision.
A CFO reviewing migration spend is not asking "how many workshops did we run?" They are asking "do we know it will work?" If the answer to that question can be obtained in twenty minutes with a read-only diagnostic, and the alternative is obtaining it over six months at vastly higher cost with lower coverage, then the cost-benefit analysis is straightforward.
This is not about whether traditional assessments are bad. They produced value for decades. The question is whether, given a mathematical alternative, continuing to rely exclusively on the manual approach represents the best use of programme resources.
The answer depends on the programme. But the question should be asked. And increasingly, it will be asked by the people who control the budget — because the cost differential is too large to ignore.
What we charge and why
Migration Proof offers three tiers:
Intelligence Report. The full bijective proof — one hundred percent record coverage, untransformable diagnosis with per-record root cause and remediation, cascade impact analysis, dependency chain map, and Ownership Ledger with cryptographic proof entries. Self-serve: upload your extract, receive the report. This is the entry point.
Proof and Clean. Everything in the Intelligence Report, plus data cleansing for all untransformable records, value mapping resolution, and re-proof cycles until one hundred percent of records are transformable. This is for programmes that want the findings fixed, not just identified.
Clean Sweep. Full migration execution — dependency-ordered creation of records in the target system via standard APIs, live system proof, delta synchronisation, and cutover support.
Each tier is a superset of the previous. And the Intelligence Report is designed to make the case for the next tier using the customer's own data — not a sales pitch, but a specific diagnosis: "here are the forty-eight records that need fixing, here is exactly what is wrong with each one, and here is what it costs to fix them." The customer's own data makes the argument.
migrationproof.io is 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.