Vendor lock-in: think about the exit before you enter the cloud
The benefit of PaaS has to be calculated alongside the cost of leaving - otherwise it is not a strategic decision, it is an expensive accident.
The conversation about moving to the cloud almost always starts with the upside: no hardware to buy and maintain, fast scaling, pay only for what you use. All of that is true. The problem is that the downside conversation happens rarely, and the exit cost conversation almost never.
By the time the question of leaving becomes urgent, the company is usually already deep in proprietary services. And then it becomes clear that "the cloud" is not just another place to run the same workloads. It is different contracts, different dependencies, and a different cost of switching. What the provider actually commits to - and the gap between what the SLA says and what it does not - is worth reading before you reach that point.
What actually creates lock-in
Cloud provider dependency comes in different depths.
The most superficial level is infrastructure: virtual machines, object storage, networking. This is relatively easy to migrate, though not free.
The next level is managed databases and queues. Moving to an equivalent service at another provider requires work, but it is achievable with the right will and budget.
The deepest level is proprietary PaaS services: specific functions, specific analytics platforms, specific ML pipelines built around a specific cloud. Moving away from these is not a migration - it is essentially a rebuild.
The depth of dependency grows quietly. The team picks a convenient service because it is right there and well integrated. Then another. Then the architecture starts to look like proper cloud-native design, and that is treated as an achievement. In reality, it is the moment when leaving becomes genuinely expensive.
How to calculate the real cost of PaaS
When the team proposes using a proprietary cloud service, the conversation usually stays within operational cost: how much per month, how much faster than building it yourself.
The right approach is to add one more dimension: the exit cost in three to five years.
That cost is made up of several components:
- the volume of code and configuration that will need to be rewritten;
- downtime or parallel running during the migration;
- functionality lost because there is no direct equivalent elsewhere;
- the team's time for retraining and adaptation;
- business risk during the transition period.
Nobody calculates this precisely. But even a rough estimate changes the conversation. A decision that looks cheap now can prove very expensive later - not because the provider is bad, but because the dependency accumulated.
Where portability is worth the effort and where it is not
Aiming for full portability is as much an extreme as ignoring lock-in entirely. If a company writes all its code to run on any cloud, it gives up much of the benefit of using a cloud in the first place.
The sensible approach is to differentiate.
For components that carry the core business logic or form the heart of the product, prefer standard interfaces and portable solutions. That core should not be hard-coupled to a single provider.
For supporting services - monitoring, logging, CI/CD - proprietary cloud tools are often justified: they are convenient, well integrated, and replacing them is not critical to the product.
For experiments and prototypes - use whatever is available. A prototype is by definition not meant to last forever.
Questions worth asking before deciding
Before choosing a proprietary service or platform, I usually ask myself a few questions:
- What happens to this component if we want to change providers in three years?
- Is there an open or standard alternative that solves the same problem with acceptable extra effort?
- How much of our own code will be tied to a proprietary API?
- Does the team understand what is creating the dependency, and are they accepting it consciously?
- Is this recorded as an architectural decision with an explicit rationale?
The last question matters more than it appears. Most cases of deep lock-in arise not from a strategic decision but from a series of convenient small steps that nobody tracked in aggregate.