There’s a certain type of architect who insists on abstracting everything away from cloud providers. “We might need to move to another cloud,” they say, designing elaborate abstraction layers that ensure every database query goes through seventeen interfaces.

Then reality hits: you’re never moving clouds. The cost and complexity of migration would dwarf whatever you’re trying to avoid.

The Lock-In Nobody Admits

Here’s the thing about cloud vendor lock-in—it’s not about compute instances. You can move VMs between clouds pretty easily. It’s not even about storage, though that gets expensive.

It’s about the services you’ve built on top.

Are you using AWS Lambda functions with EventBridge triggers and SQS queues? Good luck recreating that exact workflow in Azure or GCP. Sure, there are equivalents. They don’t work the same way. Your code will need changes. Your deployment pipelines will need to be rebuilt. Your monitoring setup starts from scratch.

Oh, and you’re using Cognito for authentication? DynamoDB for session state? S3 event notifications to trigger processing? Each of those is another dependency to unpick.

The Multi-Cloud Myth

Every few months, someone in enterprise IT discovers multi-cloud strategy and decides it’s the answer to vendor lock-in. Just spread your workloads across multiple providers! Then you’re not dependent on anyone!

Except now you’re paying for expertise in three cloud platforms instead of one. Your security team needs to understand three different IAM models. Your developers need to know three different ways to do the same thing. Your costs include data egress fees every time services on different clouds talk to each other.

And you still haven’t solved the problem, because individual applications are typically locked into one cloud anyway. You’ve just added complexity.

There are legitimate reasons for multi-cloud—regulatory requirements, disaster recovery, different clouds being better at specific workloads. “Avoiding lock-in” isn’t one of them.

When Abstraction Makes Sense

I’m not saying never abstract. I’m saying be strategic about it.

If you’re building a SaaS product that needs to deploy to customer-chosen clouds, abstraction makes sense. You need a common API that works everywhere. Tools like Terraform and Kubernetes help here—though you’ll still hit edge cases where cloud-specific features would have made life easier.

If you’re an enterprise running internal applications, you’re probably over-engineering. Pick a cloud. Get good at it. Use the services that make sense. The productivity gains from using managed services usually outweigh the theoretical flexibility of staying portable.

The Real Cost of Migration

Let’s say you’ve decided to move from AWS to Azure. Maybe AWS pricing changed. Maybe you’ve got a Microsoft EA that makes Azure attractive. Whatever the reason, you’re doing this.

What’s it going to cost?

First, there’s the actual data transfer. Depending on how much data you’ve got, this could be trivial or eye-watering. AWS doesn’t charge to get data in. They absolutely charge to get it out. Budget accordingly.

Then there’s the re-architecture. Even if you’ve been careful to stay portable, managed services work differently. Your deployment process needs reworking. Your monitoring setup starts over. Your team needs training.

And the hidden costs: bugs introduced during migration. Performance issues you didn’t see in testing. Integration problems with systems that only had AWS connectors. The three months where you’re running both clouds simultaneously to be safe.

I’ve seen migration projects that cost more than three years of the price difference they were trying to avoid.

Managed Services Are Lock-In

Here’s what kills portability: managed databases, message queues, authentication services, machine learning platforms, and serverless functions.

These are also the things that make cloud computing worthwhile.

Aurora Serverless is amazing—until you realise it’s very specifically an AWS thing. BigQuery is fantastic—and completely Google-specific. Azure Cosmos DB solves real problems—that you’ll need to solve differently if you ever leave Azure.

You can avoid these services. You can run PostgreSQL on EC2 instances, manage your own Kafka cluster, build your own auth system. You can also waste months of engineering time solving problems that managed services handle better.

The Kubernetes Escape Hatch

Kubernetes has become the de facto answer to “how do we stay portable?” And it helps—to a point.

If your workloads run in containers, Kubernetes gives you a common API across clouds. Your deployment patterns are similar. Your orchestration works the same way. Moving between clouds gets easier.

But you still need somewhere to run Kubernetes. EKS, AKS, and GKE all have quirks. The networking models differ. The authentication integrations work differently. The storage classes aren’t quite the same.

And the moment you start using cloud-native services alongside Kubernetes—which you will, because running everything yourself is exhausting—you’re locked in again.

What Actually Works

Be honest about your priorities. If cost optimisation matters more than portability, use managed services aggressively. If regulatory requirements mean you might genuinely need to move clouds, invest in abstraction.

For most organisations, the right answer is somewhere in the middle:

Use infrastructure as code so you can at least recreate environments. Use standard protocols where possible—PostgreSQL instead of proprietary databases, HTTP APIs instead of cloud-specific messaging. Keep business logic separate from cloud-specific code.

But don’t obsess over it. The cost of perfect portability usually exceeds the cost of potential migration.

The Negotiation Angle

Here’s what nobody tells you: the threat of leaving is often more valuable than actually being able to leave.

Cloud providers know migration is painful. They know you’re probably not going anywhere. But they also know that if you’re genuinely unhappy, you might try.

Having the conversation about alternatives—even if you never follow through—gives you leverage. When renewal time comes, mention that you’ve been looking at other options. Talk about the Azure EA you’ve been offered. Bring up that GCP has interesting pricing for your workload.

You don’t need to be able to migrate in a weekend. You just need to be credible that you could migrate eventually if the relationship goes badly wrong.

The Decision Framework

When evaluating a cloud service, ask yourself:

• How hard would it be to replace this if we needed to?
• How much would we lose in productivity if we avoided it?
• What’s the actual probability we’ll need to move clouds?
• What’s the cost if we do?

If a managed service saves your team two weeks per month and would take three months to replace, and the probability of moving clouds is less than 10% over five years, just use the service.

Your job is to deliver business value, not to maintain theoretical flexibility you’ll never exercise.

Lock-in is a risk. So is wasting engineering time on problems that are already solved. Balance accordingly.