Multi-Cloud and Avoiding Vendor Lock-In

Part 6 made the point that modernization is about how a system is built, not where it runs. This part follows that thread to its sharpest architectural question: once you’re in a cloud, how much of your future do you hand to the provider that runs it? Cloud vendor lock-in is the new shape of an old problem. For decades the dependency was hardware — a specific mainframe, a specific data center. The cloud dissolves that, then offers a fresh dependency in its place: the provider’s proprietary services, woven so deeply into your systems that leaving means rebuilding. This part is about taking that dependency on purpose rather than by accident.

What lock-in actually is

Vendor lock-in is the cost and difficulty of moving off a provider once your systems depend on its proprietary services — the managed database, the serverless platform, the identity system, the messaging layer, the dozens of small conveniences that make a particular cloud pleasant to build on. Lean on those, and your systems stop being “cloud applications” and become “applications for this cloud.”

The first thing to get right is that lock-in is not binary and not inherently bad. Every useful platform creates some dependency; the moment you adopt a managed service you’ve taken on a little. The question is never whether you have lock-in — you do — but whether the lock-in you’ve accepted is worth what it buys, and whether you could leave if you had to without a rewrite.

The case against fighting all lock-in

There is a reflexive instinct, especially among architects who’ve been burned before, to avoid every proprietary service and keep everything portable. Taken to its conclusion, that instinct is its own trap.

If you refuse every managed service and build only on the lowest common denominator that runs anywhere, you’ve forfeited most of the reason to be in the cloud at all. You’re back to operating your own databases, your own queues, your own everything — paying cloud prices for on-prem operational burden. The provider’s managed services are frequently exactly what makes a migration pay off (Part 3): they’re the difference between renting infrastructure and renting an operating model. Avoiding them on principle is how a lock-in worry turns into a cost problem.

Total portability and total convenience are opposite ends of one dial. The skill is not picking an end — it’s knowing which workload sits where.

Deliberate lock-in: a framework

The mature posture is to take lock-in deliberately, service by service, weighing two things: how much value the proprietary service delivers, and how costly it would be to switch away from it.

	Low switching cost	High switching cost
High value	Use it freely	Use it, with eyes open and an exit noted
Low value	Use it if convenient	Avoid — the worst quadrant

The trap quadrant is bottom-right: deep dependence on a proprietary service that doesn’t buy you much. That’s where lock-in accumulates by accident — a default chosen without thought, woven in until it’s load-bearing. The safe quadrants are the top row: depend freely where the value is high, and where switching is also expensive, make that a conscious decision with the exit cost written down, not discovered later.

The technique: protect the core, use the edges

The practical method for keeping that exit affordable is to separate your core business logic from the provider’s services behind clean boundaries. Your domain logic — the rules that are your business, the pricing engine, the claims adjudication, the things nobody else can run for you — stays in portable code that depends on nothing provider-specific. The provider’s managed services sit behind interfaces you control, at the edges of the system.

You still use the managed database. You still use the serverless platform. But the specifics of those services don’t leak into the heart of the system, so switching one becomes a bounded change at a boundary rather than a rewrite through the core. This is just good architecture — the same modular, well-bounded design that makes a system changeable in any dimension happens to make it portable too. A system built to be modernized is, almost as a side effect, a system that isn’t trapped.

When multi-cloud is actually worth it

Multi-cloud — running across more than one provider — is often proposed as the answer to lock-in. For most organizations, running every workload across multiple clouds costs far more than it returns: you operate to the lowest common denominator, forfeit the managed services, and double the operational surface. It is a heavy hedge against a risk most companies will never realize.

Multi-cloud earns its place for specific reasons, not as a default:

• Regulatory or contractual requirements to avoid single-provider concentration.
• Genuine resilience needs where a whole-provider outage is an unacceptable risk worth real money to mitigate.
• Best-of-breed — using one provider for a capability it does distinctly better than the others.

Adopt multi-cloud for one of those reasons, on the workloads that need it, with the portability technique above. Adopting it everywhere as a reflexive hedge buys insurance most workloads don’t need at a premium most budgets shouldn’t pay.

Data is where lock-in actually bites

If you take one practical thing from this part, make it this: the deepest lock-in is rarely in the compute — it’s in the data. Application code can be rewritten in weeks; a few terabytes of data in a provider’s proprietary database, with other systems built around its specific features and access patterns, is a far harder thing to move. Data has gravity (Part 5), and proprietary data services add a second, stickier kind on top of it.

This reorders the portability priorities most teams start with. Worrying about whether your compute runs on one provider’s serverless platform is worrying about the cheap-to-change layer. Worrying about whether your system of record is trapped in a format and a service you can’t extract from cleanly is worrying about the expensive one. When you place workloads on the deliberate-lock-in grid from earlier, weight the data layer most heavily: a proprietary managed database is high-value and high-switching-cost, which means use it — but write down the exit, keep your access behind a boundary you control, and know how you’d get the data out if you had to. The compute will follow; the data is what holds you.

Portability has a cost too

Avoiding lock-in has a real cost, and pretending otherwise is how architects talk teams into expensive portability nobody uses. Every abstraction you add to stay portable is code to build, test, and maintain — and an abstraction defending against a switch you never make is pure overhead. The honest position is that some lock-in is correct, portability is a spectrum you place each workload on deliberately, and the goal is not freedom from every provider dependency but the ability to leave the ones that matter without betting the business on it. Protect the core, take the edges as they come, and reserve multi-cloud for where it pays.

Where this leads

You now have the strategy, the decisions, the failure modes, the scenarios, and the architecture. What remains is execution — turning all of it into a sequence you can actually run against a real estate. Part 8, Cloud Migration Checklist, is the end-to-end checklist that ties this series into something operational: what to do, in what order, with what proven before you move to the next step.