Lock-in is one of those phrases that everyone uses and few define, which is precisely why it is so poorly managed. Treated as a single, vague risk — "we don't want to be locked in" — it gets addressed once, at contract signature, with a clause about data portability, and then forgotten while the actual dependencies accumulate for years afterward. But lock-in is not one thing you negotiate away at the start. It is a set of distinct dependencies, each with a different shape, a different rate of accumulation, and a different remedy. You cannot manage it until you have named its parts.
Naming them is not an argument against committing to a vendor. Deep commitment is often the right call, and the benefits of standardising on a strong platform are real. The point is to commit with your eyes open — to know which dependencies you are accepting deliberately and which you are drifting into by neglect.
The five dependencies inside "lock-in"
Lock-in is not one risk but five
- Data — can you get your data out, whole, with its meaning intact?
- Process — how deeply has the vendor's way of working become your way of working?
- Skills — how scarce and expensive are the people who can run what you've built?
- Integration — how many other systems now depend on this one's particular interfaces?
- Commercial — how much does your negotiating position weaken with each year invested?
They accumulate at different speeds
The data question is largely settled at signature and rarely changes — you either secured portability or you didn't. But the other four deepen continuously, invisibly, every year the platform runs. Process dependency grows each time the business reshapes itself around the system's assumptions. Skills dependency grows as the market for those specific capabilities tightens. Integration dependency grows with every new connection that assumes this platform's particular way of doing things. Commercial dependency grows precisely because all the others do — the more embedded you are, the less credible your ability to leave, and the vendor prices accordingly. Managing lock-in at signature and never again means managing the one dependency that was already fixed and ignoring the four that were still moving.
The lock-in you negotiate at signature is the one that stopped growing. The four that matter keep deepening every year you don't look at them.
Each has its own remedy
Because the dependencies differ, so do the countermeasures — and a single "anti-lock-in clause" addresses at most one of them. Data dependency is managed by portability rights and periodic proof that an export actually reconstitutes. Process dependency is managed by clean-core discipline, keeping your operating model separable from the vendor's defaults. Skills dependency is managed by developing internal capability rather than renting all of it. Integration dependency is managed by building on documented, standard interfaces rather than bespoke coupling. Commercial dependency is managed by preserving genuine alternatives — even ones you never intend to use — because a credible option you'll never exercise is still what gives you a seat at the negotiating table.
Independence as leverage
Underneath all five is a single principle: leverage comes from having an honest, independent view of your own dependency. The vendor knows exactly how embedded you are; too often the customer does not, and negotiates from a position it cannot actually see. An unsentimental read of where you truly depend on the platform — and what it would genuinely take to change course — is not a prelude to leaving. It is what makes staying a decision rather than a default, and what keeps the relationship one between two parties rather than one.
Where we sit. Roltrader's PRAIS layer quantifies these dependencies from your own estate — what leaving would actually cost, where you're genuinely coupled — so the read is yours and not the vendor's. But the discipline stands alone: name the five separately, track the four that keep growing, match each to its own remedy, and keep one credible alternative alive. Lock-in you can see is lock-in you can choose.