Published September 11, 2026
Why the next software battle will be won by making it safe to leave
The Foundry Price ended with seven questions a buyer should ask before signing a renewal. This essay is the operational sequel. You asked the questions, the answers were poor, and now there is a harder problem: how does a business move?
The claim of this essay: when software becomes cheap to build, the binding constraint is no longer building the replacement. It is moving a living business into it without breaking anything — and whoever industrialises that will hold a more valuable position than whoever ships the better feature.
1
The Moat That Is Not a Feature
Ask a finance director why an expensive contract was renewed and the answer is rarely that the product is excellent. It is some version of: we looked, and leaving seemed worse.
Unpack that sentence and it contains a specific set of fears, each reasonable. The data may not come out complete. Configuration built over six years is undocumented, and nobody remembers why the third rule exists. Integrations will break in ways that surface a fortnight later. Workflows nobody described will turn out to have been load-bearing. Historical records may not transfer, and somebody will need them during an audit. Staff will resist a system that does the same job differently. And underneath all of it, one person will be responsible if the transition goes badly — and that person is usually the one recommending the change.
None of those fears is about the incumbent’s product. They are all about the transition. Which means the incumbent is protected by something it did not build and cannot lose: the customer’s reasonable assessment that the disruption exceeds the saving.
This has always been true. What changes it is the collapse in production cost. When building a competitive replacement took three years and forty engineers, migration difficulty was one obstacle among many and not the largest. When the replacement can be produced in months, migration becomes the only obstacle left standing — and therefore the one worth industrialising.
There is a useful precedent. Mobile telephone numbers were portable long before most people used the right to switch; the point was never that everybody moved, but that staying became a decision rather than a default. A migration factory does the same thing to a software renewal. Its value is not measured only in customers who arrive. It is measured in the moment a buyer stops treating the incumbent as fixed.
2
Implementation Is Not Migration
The software industry has a word for the work of getting a customer onto a new system, and the word is wrong. Implementation describes configuring a product to meet a customer’s requirements. It begins with the new system’s needs: which fields must be populated, which workflows configured, which integrations connected, which users trained. It is a project, it is scoped by the vendor, and it is priced.
Migration begins from the other end. It begins with what the customer cannot afford to lose — and the customer usually cannot say what that is, because most of it was never written down. The undocumented exception. The suppression rule added after an incident in 2022. The report one department depends on that nobody else knows exists. Implementation asks what the new system needs. Migration asks what the old one was doing.
| Implementation | Migration |
| Begins with the new product’s configuration | Begins with the customer’s current operating reality |
| Collects the fields and settings required | Discovers undocumented workflows, exceptions and dependencies |
| Optimises for go-live | Optimises for continuity, evidence and reversal |
| Treats disagreement as a configuration issue | Treats disagreement as information about policy or history |
| Ends when the product is live | Ends when the business is stable and the way back is known |
Table 1. Implementation configures a product. Migration carries a living organisation.
The distinction is not academic, because the two produce different failure modes. A go-live can succeed while the migration fails. The screens work, the records exist, the project is signed off — and a consent rule was simplified, a refund exception vanished, a report no longer reconciles, and one connector silently stopped sending a class of event. The new system is live. The old operating truth did not arrive.
A failed implementation produces a system configured wrongly, which is visible and fixable. A failed migration produces a system that works perfectly and quietly does something the business did not intend — the silent kind of failure that The Expensive Last 10% described, discovered later, by its consequences.
This also explains why migration has never been a product. It has been a professional-services engagement: senior people, spreadsheets, discovery workshops, a project plan, a risk register, and a price that often exceeds the software’s annual cost. That was rational when discovery could only be done by expensive humans interviewing other humans. It is what makes migration the obvious thing to industrialise now, because most of that discovery is reading systems, not reading minds.
3
The Machine
A migration factory is a repeatable production line, not a bespoke project. Eight stages, and the middle two carry the difficulty.
Figure 1. The migration factory. Steps three and four are where the value sits.
Discover. Connect to the incumbent and establish what is running: entities, volumes, configuration, automations, integrations, permissions, retention rules, and — the part that matters — what is running that nobody described. Discovery reads the system rather than interviewing the organisation, which is why it can be done in an afternoon rather than a fortnight.
Extract. Records, configuration, workflow definitions, permissions, templates, history, consent records, suppression state and audit trail, in a form that can be inspected rather than merely loaded. Data export without configuration export moves the nouns and loses the verbs.
Reconstruct. This is the hard one and the whole argument turns on it, so the next section takes it alone.
Reconcile. Discovery always surfaces contradictions: two rules that disagree, a policy documented one way and running another, permissions granted to people who left. Most migration projects quietly resolve these by picking one. A factory does the opposite — it surfaces them and requires somebody with standing to decide, because as The Expensive Last 10% argued, choosing between two contested truths is an institutional act and not a technical one.
Shadow. The new system runs alongside the old, receiving the same inputs, acting on nothing. This is the step that removes the fear, and it is the reason the sequence can be self-serve: nobody has to trust the replacement before watching it be right.
Certify. Equivalence has to be defined before it is tested, or the comparison becomes an argument. Which outputs must match, within what tolerance, over what period, and what constitutes an acceptable difference rather than a defect. A migration that cannot state in advance what would count as success is not a migration; it is a hope.
Switch. By segment rather than by weekend. One customer group, one workflow, one region at a time, with the old system live behind it.
Reverse. A route back that stays open, and is tested rather than assumed. Reversal is not the inverse of switching; it is a designed capability, and it has to exist before anybody needs it.
4
Reconstructing a Specification That Never Existed
Everything above is engineering except the third step, which is closer to archaeology.
The incumbent system does not contain a specification. It contains behaviour — configuration, rules, automations, exceptions and accumulated workarounds that together encode how the business operates, without anywhere stating it. Nobody wrote it down because nobody had to; the system was the statement.
Worse, there is no single account to work from. Four of them exist and they disagree: the written policy, the incumbent’s configuration, what the system observably does, and what the experienced people say happens when the normal rule does not fit.
Figure 2. The reconstruction step resolves four disagreeing accounts into one.
So the reconstruction step converts behaviour into an executable account: which rules are in force, what they do, which are legal requirements and which are preferences, which exceptions have been accepted, who may override, what happens when two rules conflict. *This is the same artefact Software After Code called the specification, produced backwards* — derived from a running system rather than authored ahead of one.
Two properties make it difficult, and both were named in the previous essay. Provenance is missing: the system knows what to do and not why, so a rule cannot be safely changed by anyone who does not already know its origin. And habit is indistinguishable from policy in the artefact itself — a workaround added for a supplier who no longer exists looks exactly like a compliance requirement. Migrate without separating them and the new system inherits the folklore with the same authority as the law.
Which is why the reconstruction step produces two outputs rather than one: the specification, and a list of things the organisation must now decide. The second output is often more valuable than the migration. A business that has never seen its own operating rules written down usually discovers, at this point, several it would not have chosen.
And this is the durable asset. The data lands once and is then just data. The reconstructed specification is what the customer keeps, what the system is regenerated from afterwards, and what makes the next change safe — which is the recompile property from Software After Code, and it cannot exist without this step.
5
Disagreement Is the Product
Shadow operation is the bridge between a plausible replacement and an authorised one, and its output is not a pass mark. It is a list of differences — every case where the two systems would have done something different under identical conditions.
The temptation is to call all of them defects and fix them until the systems agree. That destroys precisely the information the exercise exists to surface, because the differences fall into five categories and only one of them is a defect.
| Kind of disagreement | What it requires |
| The replacement is wrong | Correct the specification and add a permanent test |
| The incumbent is wrong | Confirm the old behaviour should not be preserved out of familiarity |
| The data differs | Reconcile source, timing, identity or historical state |
| The policy is ambiguous | An authorised person decides, and the decision is recorded with its provenance |
| Both are acceptable | Define the boundary within which either action is allowed |
Table 2. Shadow operation converts uncertainty into a finite set of decisions.
The second row is the one customers find hardest and value most. A difference is not automatically an error in the new system; sometimes the incumbent has been doing something wrong for four years and nobody noticed because nothing existed to compare it against.
Certification, then, does not mean the two systems agree. It means the organisation understands why they differ and has authorised the new behaviour — across the ordinary path, the rare and consequential exceptions, the permission model, silent-failure detection and the route back.
Which connects migration to the authority ladder in Software After Code. The replacement begins by observing, then recommending, then preparing, then acting after approval, and only later operating within policy. A migration is not complete when the data arrives. It is complete when authority has been earned.
6
Switching Without the Weekend
Large migrations are still narrated as heroic weekends: freeze on Friday, move everything, test through the night, declare victory on Monday. The story persists because projects are organised around dates. Businesses are organised around continuity.
Progressive switching aligns with the second. Move one capability whose boundaries are clear, or one location, one cohort, one workflow, keeping the incumbent as the fallback for everything else. Compare operating results, support load and exceptions. Expand only where the evidence holds.
This changes the economics as well as the risk. The customer receives value before the whole estate moves. The producer discovers where its own machinery is weak while the blast radius is small. And the incumbent contract can be reduced in stages rather than terminated through one all-or-nothing negotiation — which matters, because that negotiation is often the real reason a switch never starts.
It also permits an ending the industry rarely admits to. The end state need not be total replacement. Some customers will keep the incumbent as a system of record and move workflows, intelligence or selected capabilities out around it. Migration is not ideological purity; it is the disciplined movement of utility to the architecture and the price that serve it best.
7
The Argument Only Works If It Points Both Ways
There is an obvious objection, and any reader will have arrived at it. A company that industrialises leaving expensive software has built a weapon it will eventually want to point away from itself. The migration factory attacks the incumbent’s lock-in on Monday and becomes the new lock-in by Friday.
The only answer that survives is to make exit a shipped feature: full data export, the reconstructed specification exported with it, a documented list of what will stop working, connector inventory, the authority granted to each agent, and a transition window during which both systems can run. Not on request. Not as a retention conversation. As a documented capability with a page describing it.
This sounds like commercial self-harm and is closer to the opposite, for a reason that fits the rest of this series. The company has argued that its price is honest, its obligation is inspectable and its value is continuing. A customer who cannot leave never tests any of those claims, which means the company never learns whether they are true. Retention through lock-in is a mechanism for not finding out.
There is also a plainer argument. A buyer deciding whether to enter a system is making a bet on how hard it will be to reverse. Lowering the cost of leaving lowers the cost of arriving — which, for a company with no salespeople to overcome hesitation, is not a philosophical position. It is the acquisition mechanism.
8
What This Changes
Three consequences, and they run in increasing order of size.
For the buyer, the renewal conversation changes shape. The Foundry Price argued that the moment leaving has a price, staying has a negotiation. Migration machinery is what converts that from advice into a number — and the number is useful whether or not anybody switches.
For the producer, migration stops being a cost of sale and becomes the product’s front half. It is the first thing a customer experiences, it is where the operating truth is captured, and it is the step that decides whether everything afterwards works. A company that treats migration as onboarding has misunderstood which part of its product is load-bearing.
And for the market: incumbency stops being a position and becomes a performance. Software companies have long enjoyed a protection they did not earn and could not lose — the accumulated difficulty of leaving. When that difficulty is industrialised away, the only remaining reasons to stay are the ones a vendor has to keep earning: the product is good, the price is honest, and somebody is answerable when it fails.
One discipline keeps the whole thing from collapsing back into what it replaced, and it should be stated because the pressure is predictable. A difficult migration will invite bespoke services. A valuable customer will be offered a project team. The revenue will look good, and the migration factory will quietly become an implementation practice again. The rule is the same one that governs everything else here: custom work is permitted only when it produces a reusable mapping, connector, specification or component. Measure it accordingly — human hours per migration, proportion of configuration reconstructed without help, disagreements resolved before switching, incidents after it.
The most valuable thing to build in software may not be the replacement. It may be the road out.
