The Like-for-Like Trap: How Vendor Lock-In Survives a Platform Migration

Every entrenched system eventually hits the wall: out of security support, unfixable, replacement non-negotiable. You’d think that moment is when the vendor’s leverage ends. Having watched this play out up close more than once, I’ve come to the opposite conclusion. The replacement project is where lock-in goes to survive.

Because the vendor doesn’t need to fight your migration. They just need to be in the middle of it.

The Lock-In Playbook

None of it arrives as a demand. It arrives as reasonable-sounding defaults, and that’s what makes it effective:

• The mandatory middleman. You’re buying a modern engine, and the incumbent offers to build the integration layer to it. You’d authenticate through their identity infrastructure, consume their events, and sequence your roadmap behind their build timeline. Same dependency, fresher logo.
• The legacy dialect, preserved. The incumbent’s “next-generation” product is engineered to accept the old system’s shapes and translate internally. A replacement that speaks the legacy dialect isn’t a replacement. It’s the old coupling wearing new clothes, and it keeps the intermediary sticky forever.
• Operational coupling as a moat. Picture a vendor appliance humming away in a comms room, configuration changes that must be lodged as support tickets, a private connection only their engineers can log into. The support burden this model generates isn’t a bug; it is the business model. And when the vendor modernises their own stack, the moat somehow survives the modernisation.
• Lump sums, not line items. Support and implementation fees arrive as single figures. Asking for a breakdown by activity and volume gets treated as an act of aggression rather than basic commercial hygiene.
• Ownership by vocabulary. Documents start describing the build as “collaborative” and “co-designed.” Nobody decided that. Language creep is how co-ownership gets established without a decision, and it has to be corrected every single time.

The Trap Is Like-for-Like

The uncomfortable part: none of this works without the customer’s help. The default ask in every replacement project is “give us what we have today, but new.” It feels safe. It’s auditable. You can build a requirements matrix from it.

But like-for-like requirements describe the current system, and the current system has the vendor woven through every layer. Specify parity and you’ve specified the lock-in: the appliances, the middleware, the ticket queues, all faithfully rebuilt on modern infrastructure, on day zero. Parity isn’t a scope decision. It’s a re-signing ceremony.

And parity has a deeper flaw than re-signing with the vendor: it never gets to the root cause. The project exists because the current shape is wrong. A legacy architecture encodes the constraints of the era it was built in - no APIs to integrate against, everything operated on-premise, the vendor as the only party who could touch it. Those constraints are gone, but the shape survived them, and most of what the system does today is compensate for problems that no longer exist. Ask for like-for-like and you’re commissioning the wrong shape with a new coat of paint. The right-shaped solution doesn’t resemble the current system. It’s vastly different, and a parity matrix is structurally incapable of describing it.

A platform replacement is a decision to minimise external dependencies and own your integrations. If the migration doesn’t achieve that, it’s just an upgrade with extra steps.

Getting a sentence like that written down and agreed does more than any technical spike, because it reframes the project from “replicate the platform” to “remove the coupling.” The legacy model’s support load exists because of the coupling. A root-problem design doesn’t inherit that load. It deletes the class of work that generates it.

The plan that follows is almost boring: integrate directly with the thing you’re paying for, hold the credentials yourself, own one thin adapter, and hold the commercial relationship directly rather than routing it through the incumbent.

What the Clean Version Doesn’t Tell You

Fairness demands a few admissions. Legacy platforms usually ran for a decade and mostly worked; that’s not nothing. The shiny replacement will have genuine gaps the old system covered for free, and you’ll be building those yourself. And every account of a lock-in escape is written by the side doing the escaping; the vendor’s support burden and revenue concerns are real, even when the tactics aren’t defensible.

The other honest admission: escape is never finished. Incumbents keep building in parallel, and every scope discussion is a chance for an intermediary to quietly re-enter the request path. Lock-in re-establishes itself through drift, not decisions. Someone has to keep watching the language, the diagrams, and the SOW.

The Way Forward Is Boring

The resolution isn’t a clever architecture. It’s transparency, applied relentlessly:

• Itemise everything. No lump-sum fee survives contact with a per-line breakdown.
• Hold your own credentials and contracts. Whoever owns the commercial relationship owns the roadmap.
• Write the principle down. “Minimise external dependencies” beats a hundred requirement rows because it gives every future decision a test.
• Listen for the root problem. The business doesn’t want the old system rebuilt. It wants to stop being dependent. Those are different projects, and only one of them is on the vendor’s quote.

Lock-in doesn’t end when the contract does. It ends when nobody’s platform sits between you and your problem.