November 3, 2026
Adding cloud APIs directly into core code creates severe vendor lock-in and destroys software portability. Maintaining a platform-agnostic code layer built on universal open standards ensures applications can easily migrate and remain completely independent.
Infrastructure consultants see cloud vendor lock-in so often that it feels like Groundhog Day. At the start, a cloud giant feels like the right call: prices are great, convenience is high. But over time, vendor-specific SDK calls spread through the business logic because decision makers aren’t keeping leaving in mind.
That becomes a problem when something changes. Startup credits run out, a better host comes along, there’s a major security incident, or a feature is deprecated. The business wants out, but the time and cost required to do so hold it hostage.
At Liber, we don’t believe you need to forgo managed services entirely, though there are benefits to doing so. Instead, we think you should design your architecture so that a move remains feasible.
On paper, leaving a cloud provider has never been easier. AWS, Google, and Azure waived egress fees for customers moving out in 2024, and the EU Data Act will ban switching charges from January 2027. Moving the data itself is rarely the hard part: 37signals moved billions of files off S3 with zero downtime, partly because its storage replacement spoke the same API as S3. What slows an exit down is code built around one vendor’s services, and cloud giants make those very tempting.
Alongside raw computing power, customers are spoon-fed managed queues, proprietary databases, and serverless compute platforms, often with generous free tiers, startup credits, onboarding nudges, and easier setup.
Once you’re in the ecosystem, small decisions to optimise for it can compound. A “place order” calls the DynamoDB SDK directly. Download links on profile pages generate S3 pre-signed URLs inline. API endpoints parse requests and return responses in API Gateway’s Lambda event format. Eventually, the dependency reaches your data. DynamoDB has no joins, so teams design around partition keys, secondary indexes and single-table design, storing related data together in the exact shape each query needs.
It can also shape the architecture, with serverless products splitting one application into many small functions triggered by vendor-specific events. Each step ties a little more of the codebase to one provider until moving means significant rework.
If you never feel the need to move, then that dependency perhaps doesn’t matter too much. That, however, relies on the terms staying the same as when you joined. When Google shut down Firebase Dynamic Links in August 2025, every link it served started returning a 404. Devs had to rewrite link creation and handling, fix login flows, migrate existing links (where possible), and in some cases, integrate and pay for a new third-party provider.
Then there are pricing changes. In February 2024, AWS started charging $0.005 an hour for every public IPv4 address, including in-use addresses that had previously been free. The same month, it also began charging RDS databases still running MySQL 5.7 or PostgreSQL 11, which had been automatically enrolled into paid Extended Support. In US East, that meant an extra $0.10 per vCPU per hour on top of the normal instance price, which doubled to $0.20 in March 2026.
Lock-in can even touch staff and recruitment. You can end up with a team whose skills are tied to one platform, making it harder to staff any move. All of this can cause early development speed to morph into spiralling migration costs as the product grows and the vendor’s terms change.
The practical solution to the issues above is to be very deliberate about where and how managed services touch your code. Alistair Cockburn’s Hexagonal Architecture, also known as ports and adapters, provides a widely used blueprint for this. The idea is simple: your core code shouldn’t know what cloud it runs on. That place order function we mentioned earlier should call a plain internal interface such as SaveOrder (or StoreFile for those download links) rather than the DynamoDB SDK directly. Behind that sits an adapter which knows about DynamoDB so that nothing else has to. If you later move to PostgreSQL on your own hardware, you write a new adapter and the order logic stays as it is.
Obviously, you can go too far with this. Every interface adds a layer of indirection, and abstracting a library you’ll never replace is a waste of time. Instead, the focus should be on stateful and fast-changing dependencies like databases, queues, file storage, and identity. That’s where vendor changes are most likely to bite you during migration.
Naturally, a wrapper can change how your code talks to a service, but not how the service works. Standard SQS queues, for example, can deliver the same message twice. That’s normal for most message queues, so if your code already handles duplicates safely, it will carry over to any provider. The lock-in comes from relying on features specific to one service, like SQS FIFO’s ordering and deduplication, or its particular retry and timeout behaviour. Know which of these your app depends on, and design so that handling a message twice does no harm.
As mentioned earlier, talent ties you to a provider just as easily as code. If an engineering teams’ primary expertise is vendor specific, migrating away creates a skills gap that you’ll need to solve with investment in talent or training.
At Liber, we see this as another reason to build and hire for open tools from the beginning. Engineers who work with Linux and PostgreSQL can take those skills to any environment, whether a hyperscaler, a VPS, or your own hardware.
Building on open standards also gives you access to a broader global talent pool. For example, PostgreSQL is the most-used database in StackOverflow’s 2026 Developer survey at 57.9%. DynamoDB sits at just 9.3%. That huge increase in talent availability enables not just more flexibility, but also allows you to scale your team faster as you grow.
Lock-in isn’t always bad. If you weigh the benefits and drawbacks and decide there will never be a better option for your use case, fair enough. The real problems arise when a team chooses a hyperscaler as a good early strategy and ends up with their product built around it.
The goal isn’t to be able to leave your hyperscaler at the drop of a hat — that’s unrealistic. Rather, it’s about having the flexibility to move without a crisis and knowing what it would involve. The egress waivers provide a useful framing: if you had to move in sixty days, what would stop you? Ask yourself:
If the answers point mostly to moving your data, you’re in decent shape. However, multiple blockers in your code, architecture, or team could leave you in a vulnerable position.
At Liber, we endeavour to build products that are mobile from the beginning by choosing control over convenience, using open standards, and advocating for sovereign infrastructure.
Ultimately, no team should be planning to migrate their product often. Rather, infrastructure mobility is about maintaining leverage and control over the future of your product if the terms change. You might decide to stay with a hyperscaler indefinitely, but a mobile infrastructure ensures that you’re doing it because it’s best for your organisation, not because it would cost you too much to leave.