Skip to content
    Back to blog

    Cloud

    Avoiding Cloud Vendor Lock-In: Practical Choices for SMEs

    Your bill keeps rising and a competitor has a better offer, but when you actually run the numbers on switching, the conversation goes quiet: half your data sits in a proprietary database and your serverless workflows only work with one provider. We explain where vendor lock-in arises, how the EU Data Act (in force since September 2025) strengthens your position as an SME customer, which six architecture and six contract choices keep your exits open, and what multi-cloud really delivers.

    Author
    TRON Group, Managed Cloud Experts
    Published
    Reading time
    10 min read
    Avoiding cloud vendor lock-in for SMEs: open data formats, containers, IaC and EU Data Act switching clauses
    Contents

    Three years ago you moved everything to the cloud. The bill keeps climbing and a competitor has made you a better offer, but when you actually run the numbers on switching, the conversation goes quiet: half your data sits in a proprietary database, your authentication is tied to a single identity provider, and your serverless workflows are written in a syntax only your current provider understands. In 2026, vendor lock-in isn't just an IT term; it's a reason to lose commercial negotiations. In this guide we look at how to recognise lock-in as an SME, why the EU is now actively on your side, and which choices really make a difference today.

    What exactly is vendor lock-in?

    Vendor lock-in means the cost or complexity of switching is so high that, in practice, you're stuck with one supplier. It's rarely a single link. Usually it's three layers stacked together into a thick wall: proprietary data formats and storage services, APIs that only work on that one platform, and commercial arrangements (reserved instances, discounts in exchange for longer terms) that make leaving expensive.

    Lock-in isn't necessarily bad. Choosing a managed service that only exists at provider X can be the right decision if that service is genuinely better. Lock-in becomes a problem when you don't choose it consciously, have no exit strategy, or when the cost of staying grows larger than the cost of migrating.

    Why lock-in is so urgent right now

    In 2026, three things are changing at once that make lock-in more visible.

    First, the EU Data Act. This regulation (EU 2023/2854) has applied to cloud services since 12 September 2025 and requires providers to remove commercial, contractual, technical and organisational barriers to switching. Every cloud contract must include a switching clause with a maximum transition period of 30 days, following a notice period of no more than two months. From January 2027, providers may no longer charge switching or egress fees.

    Second, the big providers got ahead of this. AWS, Google Cloud and Microsoft Azure already scrapped their egress fees in 2024, each with its own conditions: Azure requires you to cancel all your Azure subscriptions to receive the credit at invoice level, and specialist services such as ExpressRoute and VPN are excluded. AWS requires a support request and applies a 60-day window. Google put egress at roughly 2 percent of total migration costs, so it's no reason to migrate in itself, but it does lower the political threshold.

    Third, since March 2026 the UK competition regulator, the CMA, has also been putting pressure on egress fees and interoperability, prompting AWS and Microsoft to make voluntary commitments.

    In other words, your chances of switching have improved, but only if your architecture and contracts allow it. If you've built your entire operation on proprietary services, you still can't leave, however low the egress price.

    The three layers where lock-in arises

    Data and storage

    This is often the hardest knot to untie. If your data sits in a proprietary format (such as a vendor-specific NoSQL database) or in a storage service with no direct equivalent, migration is painful. A PostgreSQL database can be moved within a week; a Cosmos DB or DynamoDB setup with triggers and stored procedures calls for a rebuild project.

    Compute and runtime

    Serverless functions are tempting because there's nothing to manage, but the code interfaces diverge. A Lambda function using an AWS SDK is not an Azure Function. Containers on Kubernetes are virtually universal; a proprietary PaaS is not.

    Identity and integration

    Your authentication, your monitoring stack, your CI/CD pipelines: if they're all intertwined with one provider, you're not just moving your workload but your entire operational process. This is the layer SMEs underestimate most.

    How serious is lock-in for your business?

    Not every case of lock-in warrants an architecture overhaul. Here's a practical three-question test:

    1. What does staying cost? Map out your annual cloud bill, including growth. Compare it with market rates from alternatives.
    2. What does leaving cost? Estimate the number of person-months for data extraction, code rebuilds and integration changes. Add an extra quarter for the unexpected.
    3. How much strategic room are you giving up? A provider that stubbornly raises prices or discontinues a service, while you have no realistic exit option, will beat you in every negotiation.

    If the answer to question three is "hardly any" and price increases are limited, consciously staying put is a perfectly good choice. If one or more answers are cause for concern, it's time to take action, even if you don't want to switch right now.

    Six architecture choices that limit lock-in

    1. Open data formats, not proprietary models

    Keep data in open formats such as Parquet, Avro or a classic relational form (PostgreSQL, MySQL). Every provider offers managed versions of these. You stay portable without sacrificing performance.

    2. Kubernetes and containers instead of proprietary PaaS

    A container runs anywhere. The same Docker image moves from AWS ECS to Azure AKS to on-premises Kubernetes without a rebuild. Serverless (Lambda, Azure Functions) is quicker to set up, but ties you in more tightly. For most SME workloads, a lightweight Kubernetes cluster or a containerised app service is more than enough, and future-proof for years.

    3. Infrastructure as code with provider-independent tools

    Terraform, OpenTofu and Pulumi define your infrastructure in code that can (with adjustments) move to multiple providers. An environment clicked together by hand in a portal can't be lifted anywhere. IaC also pays off in your day-to-day operations: think reproducible environments and version control for your infrastructure.

    4. A thin layer of proprietary logic

    Can you use a proprietary service? Certainly, as long as you don't build heavily on top of it. The rule of thumb: use proprietary services only at the edges of your architecture (for example a managed queue or a specific AI service), and abstract them so that replacing them doesn't touch your core logic.

    5. Open identity, open monitoring

    Use the OpenID Connect and OAuth 2.0 standards. A modern identity provider such as Microsoft Entra ID still isn't 100 percent portable, but standard protocols make it much easier to put an identity-brokering layer in between. Put your logs and metrics on OpenTelemetry so they can be used in any observability platform.

    6. Multi-region for cloud dependency; consider multi-cloud only deliberately

    Multi-cloud sounds like the ultimate answer to lock-in, but in practice it's expensive and complex. For most SMEs, multi-region within a single provider is more than enough for availability; go multi-cloud only if you have a clear business or regulatory reason. Experience shows that only a minority of businesses have genuine portability between providers properly in place.

    Six contractual choices that keep exits open

    • Annual or monthly contracts, no multi-year lock-in without a clear discount. A 10 percent discount over three years is rarely worth three years of flexibility.
    • An exit clause with an SLA for data transfer. The EU Data Act effectively requires this from September 2025, but put it in writing explicitly: which format, within what timeframe, and with what cooperation.
    • A benchmark clause. An agreement that you can test your prices against the market every year and renegotiate if there's a material difference.
    • Portable tooling. All configuration as IaC, documented integrations and open-standard backups.
    • Transparent pricing models. A fixed rate per user or per unit of consumption is transferable; obscure discount columns in enterprise contracts much less so.
    • Don't accept free credits without an exit plan. Startup credits and migration bonuses are tempting, but they pull you deeper into a stack you could find yourself stuck in for three years without meaning to.

    Microsoft 365 and Google Workspace: lock-in too?

    Certainly, but of a different kind. Your data in Microsoft 365 or Google Workspace can be exported (OneDrive exports, mailbox exports), and the main file formats are open. The lock-in lies in user adoption: your staff know Outlook or Gmail, and your processes are built on SharePoint or Drive. Switching therefore calls mainly for change management and training rather than data portability. For background, see our comparison of Google Workspace and Microsoft 365 and our complete guide to outsourcing cloud management.

    What the EU Data Act means for your contract

    The short version: every cloud contract you sign or renew today must include a switching clause. Providers may take no longer than 30 days to transfer your data, following a notice period of no more than two months. Switching and egress fees are still allowed in limited form until January 2027, after which they're banned entirely for standard services.

    What you can do in practice: in every new contract, ask for an explicit switching section covering formats, timeframes and the obligation to cooperate; for existing contracts, ask for an addendum. The EU Data Act places this requirement on the provider, so resistance should be limited. Our guide to SaaS, PaaS and IaaS for SMEs explains how responsibilities shift with each service model.

    A real-world example, lightly anonymised

    An SME online retailer with around 40 employees was running on a proprietary PaaS with a managed database and serverless functions. The bill grew every year. Over four quarters we abstracted the database behind a PostgreSQL-compatible interface, rebuilt the serverless functions as containers, and captured the infrastructure in Terraform. Suddenly, a quote from a competing provider became a genuine bargaining chip.

    Frequently asked questions about cloud vendor lock-in

    Does the cloud automatically mean lock-in? Not automatically, but often. Every cloud has its own managed services that tempt you into using proprietary features. Lock-in arises from the choices you make within the cloud, not from "being in the cloud" as such. With open formats, containers and infrastructure as code, you keep realistic exit options even in the cloud.

    So is multi-cloud the solution? Rarely for SMEs. Multi-cloud doubles operational complexity, the expertise you need and sometimes your costs. For most SMEs, multi-region within a single provider delivers more value than multi-cloud. Multi-cloud becomes interesting with strict regulatory requirements, for vendor-independent SaaS products, or for specific continuity requirements.

    How quickly can I reduce lock-in without rebuilding everything? You can often get a long way within a year. Start with IaC for new environments, migrate one proprietary database to an open equivalent, and agree a switching clause for every new contract. Major rebuilds take longer, but most of the gains lie in the 20 percent of architecture choices that determine 80 percent of your portability.

    Are cloud providers already banned from charging me for switching? No. Under the EU Data Act, that ban only applies in full to standard services from January 2027. For now, providers must lower the barriers and offer switching clauses, and most major players have already voluntarily scrapped their egress fees for moving data out (with conditions).

    What does lock-in mean for our cybersecurity? Lock-in amplifies the impact of an incident at your provider: if you can't easily leave, a prolonged outage or security problem hits you harder. An exit strategy with a tested handover to an alternative is effectively a continuity measure too. Our guide to business continuity planning shows how to link this to your BCP.

    Conclusion

    In 2026, vendor lock-in is no longer an inevitable fact of life. The EU Data Act forces providers to open up, egress fees are disappearing, and most of the technical tools for portability (containers, open formats, infrastructure as code) are mature enough for SMEs to use. The question is whether your contracts and architecture actually give you the exit option the law now promises. Start with an honest inventory of where you use proprietary services, draw up a short list of open alternatives, and from today agree a switching clause for every new contract.

    Want to know how locked in your current cloud environment really is, and which steps would deliver the most in your situation? TRON Group assesses cloud architectures for SMEs and builds in portability step by step, without putting you through a painful migration. Call us with no obligation on +31 85 303 5869 or explore our cloud management services to arrange an initial conversation.

    Topics

    • Vendor Lock-In
    • Cloud Strategy
    • EU Data Act
    • Multi-Cloud
    • Egress Fees
    • Kubernetes
    • Terraform IaC
    • SMEs

    TRON Group

    Managed Cloud Experts

    Back to blog

    Keep reading

    More articles

    All articles

    Want to know more about these IT solutions?

    Get in touch for a no-obligation chat with our experts

    A real person picks up.
    No phone menu, no ticket number.