Cloud Lock-In 
What an Exit Plan Actually Costs 

Lock-in is one of the few architecture topics where the loudest advice is reliably wrong in both directions. One camp treats every managed service as a trap and builds everything on portable primitives, paying a permanent tax in engineering time to preserve an option they will never exercise. The other adopts every proprietary service available and discovers, three years later, that a renegotiation they thought they would win has no credible alternative behind it. The useful position is neither, and it starts by noticing that lock-in is not one thing — it is four quite different kinds of dependency with wildly different costs to unwind.

The four kinds, and only one of them is expensive

Infrastructure lock-in — compute, block storage, networking, load balancing — is the kind people worry about and the cheapest to escape, because these are commodities with equivalents everywhere and the work is mostly re-plumbing infrastructure-as-code. Data lock-in is the expensive one, and it is expensive for physical rather than commercial reasons: moving fifty terabytes takes time you cannot compress, egress is charged on the way out, and the difficulty is not the copy but doing it while the system stays available and consistent. Service lock-in sits in the middle and varies enormously by service, since a managed Postgres or Kubernetes has a clear migration path while a proprietary serverless workflow engine, a managed identity service, or a purpose-built analytics stack has been woven into your application's logic and has no equivalent to move to. Then there is the one nobody puts in the diagram: operational lock-in, meaning your team's expertise, your runbooks, your monitoring, your compliance evidence, and the fact that your on-call engineers know how one provider behaves at three in the morning. On a real migration this is frequently the largest cost of all, and it never appears in the estimate.

What portability actually costs to maintain

The reason 'stay portable' is bad advice as a blanket rule is that the tax is continuous and the benefit is contingent. Refusing managed services means running your own database, queue, cache, and search infrastructure, which is several engineers of permanent capacity at a growth-stage company — capacity you are taking from your product to insure against an event that may never occur. An abstraction layer over provider services sounds cheaper and is usually worse: it delivers the lowest common denominator, hides the features you adopted the service for, and rots on every provider release, and in practice teams that build one still find the migration hard because the leaks are where the value was. Genuine multi-cloud, run properly, roughly doubles the operational surface — two sets of IAM, two networking models, two monitoring stacks, two sets of expertise — and outside specific regulatory or sovereignty requirements it very rarely pays for itself. The honest arithmetic is that most companies should accept meaningful lock-in in exchange for the leverage a managed platform gives a small team, and spend the savings on the product. That is a defensible engineering decision, provided it is a decision rather than an accident.

Where to buy portability deliberately

• Your data. Regular exports in an open format, restore-tested somewhere other than the provider that produced them. This is the one investment that is unambiguously worth it, and it doubles as your disaster recovery posture.
• Containers over proprietary runtimes for your own services, since the packaging is portable even when the orchestration is not.
• Standard interfaces where they exist and cost nothing: Postgres over a proprietary datastore when both fit, S3-compatible object APIs, OpenTelemetry for instrumentation, Kubernetes when you are already at the scale that justifies it.
• Infrastructure as code for everything, which converts a rebuild elsewhere from an archaeology project into a porting exercise.
• Your identity model. Keeping your own user, organization, and permission records as the source of truth means changing identity providers is an integration change rather than a data migration.
• Business logic kept out of proprietary orchestration. Rules encoded in a managed workflow engine's configuration are the hardest thing to move, and they are usually the part you most need to keep.

The commercial dimension people underplay

Lock-in matters most at renewal, and the negotiation is the point at which an abstract architectural preference becomes money. A provider's pricing power over you is a direct function of how credible your alternative is, and credibility here is unsentimental: 'we could move in eighteen months with six engineers' is a materially weaker position than 'our data is exported nightly in an open format, our services are containerised, and we have a written plan with a nine-month estimate'. You do not need to intend to leave, and you should not bluff, but a documented, costed exit plan changes the conversation and typically pays for itself once. Two commercial details are worth watching specifically. Egress fees are a deliberate design choice by cloud providers and the reason data lock-in has teeth, so the volume you keep in one place is a decision with a price attached even if you never move it. And committed-spend discounts — the large multi-year agreements that look like an obvious saving — are the mechanism by which a reversible architectural position becomes an irreversible financial one, so the commit should be sized against your actual cost trajectory rather than the projection your account team prefers.

Writing the exit plan you hope not to use

An exit plan is a short document, not a project, and its value is mostly in having been written. It should name every provider service you depend on and, for each, what the replacement would be and roughly what moving would cost in engineering weeks — an estimate, not a study. It should identify the two or three dependencies that are genuinely hard, because in most architectures the difficulty concentrates in a small number of places and everything else is routine. It should state where your data is, in what volume, and how you would get it out, including the egress cost, since that number is often the one that surprises people. It should say what your team does not know how to operate elsewhere, because operational lock-in is real even when nothing technical blocks you. And it should be reviewed once a year, or whenever you are about to adopt a new proprietary service, which is precisely the moment the document earns its keep: the question 'what would it take to leave this?' asked before adoption is worth more than the same question asked afterwards, and it costs an hour.

How Infiniti Tech Partners approaches this

We are asked about this in two very different situations. The first is a team about to make a large architectural or commercial commitment who want the lock-in question answered honestly before they sign, and that is a short engagement — a dependency map, a costed exit estimate, and a clear recommendation, which frequently amounts to 'adopt the service, but keep your data exports and your identity model portable'. The second is a company that has already decided to move, usually for cost, acquisition, or sovereignty reasons, where the work is a phased migration plan that sequences the hard dependencies first and keeps the business running throughout. In both cases our bias is against reflexive multi-cloud and against abstraction layers built on principle, because we have seen both consume more engineering than the migrations they were meant to prevent. We work across AWS, Azure, VMware and Proxmox, including on-premise and edge deployments, so the recommendation is not shaped by one platform being the only one we know. If a renewal or a board question has put this on your agenda, a costed exit plan is a couple of weeks and it makes the next conversation a much easier one.