Cloud Vendor Lock-In: A Portability Checklist for 2026
by
-
7 minutes read
-
August 6, 2026

Lock-in is a math problem, not a loyalty problem
Most teams do not choose vendor lock-in on purpose. It accumulates one convenient managed service at a time: a proprietary queue here, a vendor-specific database extension there, a data warehouse format that only one provider’s tools read natively. Each choice is individually reasonable and ships faster than the portable alternative.
The problem shows up later, when a pricing change, a regional outage, or a new compliance requirement makes switching providers the right call and the migration turns out to cost more than the original build. By then it is a negotiating-leverage problem too: a vendor that knows you cannot leave has little reason to compete on price.
The problem shows up later, when a pricing change, a regional outage, or a new compliance requirement makes switching providers the right call and the migration turns out to cost more than the original build. By then it is a negotiating-leverage problem too: a vendor that knows you cannot leave has little reason to compete on price.
Where lock-in actually comes from
In practice, lock-in concentrates in four places:
- Proprietary managed services with no equivalent elsewhere, such as a database’s vendor-specific extensions or a serverless orchestration product with a unique execution model.
- Data gravity: large datasets stored in a provider-native format, where the cost and time of exporting and reformatting exceeds the value of switching.
- Egress fees: the per-gigabyte charge to move data out, historically one of the biggest deterrents to changing providers even when the workloads themselves are portable.
- Committed-use contracts: multi-year spend commitments signed for a discount, which quietly become a switching cost of their own.
What changes under the EU Data Act in 2027
Egress fees are also becoming a live regulatory issue, not just a line item. Under the EU Data Act, cloud providers serving EU customers are currently only permitted to charge switching fees, including data egress charges incurred during a provider switch, that are “cost-covering” rather than punitive. From 12 January 2027, that transition allowance ends: providers will be prohibited from charging any switching fees at all, egress included, for moving data to another provider or back on-premises.
That deadline matters even for teams outside the EU. Global providers tend to standardize pricing mechanics rather than run two different egress models, and the change removes the single biggest financial argument for staying put once switching fees are gone. The architectural lock-in, proprietary services and data formats, does not disappear on its own, so 2026 is a reasonable year to start reducing it ahead of a rule change that removes one of the excuses for not moving.
That deadline matters even for teams outside the EU. Global providers tend to standardize pricing mechanics rather than run two different egress models, and the change removes the single biggest financial argument for staying put once switching fees are gone. The architectural lock-in, proprietary services and data formats, does not disappear on its own, so 2026 is a reasonable year to start reducing it ahead of a rule change that removes one of the excuses for not moving.
A portability checklist to run before you sign
Run this before renewing a contract, adopting a new managed service, or picking a provider for a new workload:
- Audit proprietary dependencies: list every managed service in use and flag which ones have no equivalent elsewhere versus which are a thin wrapper over something portable, like Postgres, Kafka, or standard object storage.
- Containerize and use infrastructure as code: workloads packaged in containers and defined in Terraform or an equivalent tool move between providers with far less rework than services hand-configured through a console.
- Keep the data layer in open formats: prefer standard formats and portable schemas over provider-native warehouse or storage formats when the functional difference is small, so export is a job, not a rebuild.
- Model real switching cost today, including the “cost-covering” egress fees that still apply until January 2027, so the decision to diversify is based on numbers rather than a guess.
- Negotiate contracts with an exit in mind: watch for multi-year committed-use terms that lock in spend well beyond when the discount stops mattering.
- Pilot a second provider on one real workload before assuming portability works in theory. A small, working proof is worth more than an architecture diagram.
How Innvente can help
Innvente designs and runs workloads across AWS, Google Cloud, and Alibaba Cloud, so portability is something we build for from the start rather than retrofit after a vendor relationship goes wrong.
Explore our cloud solutions, see how provider choice fits into a move in our cloud migration checklist, or book a free software project audit to get a portability and lock-in review of your current architecture.
Explore our cloud solutions, see how provider choice fits into a move in our cloud migration checklist, or book a free software project audit to get a portability and lock-in review of your current architecture.
Quick checklist
- Audit which managed services are truly proprietary versus portable.
- Containerize workloads and manage infrastructure as code.
- Keep the data layer in open, portable formats where practical.
- Model switching costs now, including egress fees, ahead of the EU Data Act’s January 2027 switching-fee ban.
- Avoid multi-year commitments that outlast their discount value.
- Pilot a second provider on one real workload before you need to.
Share on :