You can't see the lock-in. Until the day you try to get out.

You can't see the lock-in. Until the day you try to get out.

It always happens the same.

A company chooses a cloud provider. The migration is free, fast, and seamless. The sales engineer is available, the documentation is excellent, and the initial price is competitive. All good.

Years pass. Workloads grow, data accumulates, integrations multiply. Infrastructure becomes part of the company's operational fabric—not visibly, but pervasively.

Then, for one reason or another—rising costs, a policy change, a corporate merger, a new strategic direction, a security incident—someone decides it's time for a change.

And that's where the problem begins.

The moment when lock-in becomes visible

Data costs to get out. Not to get in—that was free. To get out, you pay for every gigabyte transferred outside the provider's perimeter. AWS calls this cost "data transfer out." Azure calls it "bandwidth." Google Cloud calls it "network egress." The names vary, but the mechanism is the same: you brought the data here for free, but taking it elsewhere costs money.

The formats aren't compatible with anything else. The managed database that seemed so convenient to use uses proprietary extensions that aren't available in the open-source equivalent. The object storage system has a slightly different API than the S3 standard. The containers run on a custom runtime that doesn't behave like standard Docker. Every small technical choice—made in good faith, for convenience—has become a binding thread.

The only decent API documentation is that of the vendor you want to leave. Every migration tool, every best practices guide, every Stack Overflow answer is written assuming you're using their system. Leaving requires rebuilding that knowledge from scratch, on a platform you're less familiar with.

The freedom to choose, promised at the beginning, has evaporated without anyone noticing. There wasn't a specific moment when it vanished—it happened gradually, one small technical choice at a time.

The most sensational case in recent years

The Broadcom-VMware case is the most visible example of this mechanism applied on an industrial scale.

For years, VMware was the go-to virtualization platform for the enterprise market. Reliable, well-documented, and widely supported. Companies had built entire datacenters, operational processes, and in-house expertise on it.

When Broadcom acquired VMware in 2023, the rules changed. Perpetual licenses were eliminated. Mandatory bundles with features no one had asked for were introduced. Price increases of up to 1,500% for some customers. And the cost of exit? Vastly higher than anyone had calculated—not because of egress fees, in this case, but because of the technical complexity of migrating years of workloads optimized for a proprietary system to something completely different.

This isn't an isolated case. It's the lock-in business model applied at the moment of greatest negotiating power.

Why Lock-in Works — and Why It's Hard to Notice

Lock-in works because it builds slowly, through reasonable decisions made in good faith.

Using the cloud provider's managed database makes sense—it eliminates operational complexity. Using their serverless features makes sense—it speeds up development. Using their monitoring system makes sense—it's already integrated. Every single choice makes sense. The sum of all those choices creates a dependency that was never intended.

The problem is that the cost of lock-in doesn't appear in initial budgets. There's no "future migration difficulties" item in the TCO that presents itself to the board when choosing a cloud provider. It only appears when it's too late to make other, lower-cost choices.

The right question to ask yourself

The question that usually arises when choosing a cloud infrastructure is: how much does it cost to get started?

The right question is another: how much would it cost to go out, if I had to do it tomorrow?

Not in five years, in an ideal situation, with time and budget planned. Tomorrow—due to an acquisition that changes strategy, a security incident that forces a rapid change, or a unilateral price increase that makes the cost unsustainable.

If the answer is "I don't know" or "it would be very complex," that's already important information.

How we build infrastructure in Epic Edge

From Epic Edge we start from the opposite problem.

We build every infrastructure assuming, from day one, that the customer might one day want to change—vendor, architecture, technology, even us.

This isn't an altruistic approach. It's simply how we think professional infrastructure should be built. An infrastructure you can't leave behind isn't a service—it's a prison with a maintenance contract.

In practice, this means working exclusively with open standards. OpenStack for compute and networking. Ceph for distributed storage. Kubernetes for containerized workloads. Standard formats, standard APIs, standard protocols. Not because they're always the technically easiest choice—sometimes they're not—but because they ensure that skills, tools, and data remain portable.

This means working on hardware the company already owns or leases in colocation. We don't host anything ourselves, so there's no "exit" to negotiate with us. The data is physically located in the customer's datacenters or in a colocation the customer controls. There are no egress fees because there's no Epic Edge infrastructure to exit.

If a customer wanted to go elsewhere one day, it would involve changing support providers—like changing the company that maintains their systems. It wouldn't be a year-long migration project, it wouldn't involve a negotiable exit fee, it wouldn't involve a technical dependency to be dissolved.

Reversibility as an evaluation criterion

When evaluating an existing infrastructure or designing a new one, we always add a question to the assessment process: is this architecture reversible?

Reversible means that the data is in standard, exportable formats. Configurations are written in Infrastructure as Code (Terraform, Ansible) and versioned on Git—not locked into a proprietary control panel. Documentation exists and isn't dependent on the knowledge of a single person or vendor. The technical and operational cost of switching vendors is measurable and acceptable.

Reversibility isn't an additional cost. It's a feature you plan in from the start or pay dearly for later.

Conclusion

Cloud lock-in is a risk that almost no IT budget explicitly considers. It only appears when it's already expensive to address.

The good news is that it can be avoided—not with magical technologies, but with deliberate architectural choices made from the start. Open standards. Customer-facing hardware. Infrastructure as Code. Portable documentation.

If you don't know the answer to the question "how much would it cost to move from your current infrastructure if you had to do it tomorrow," now's a good time to find out.

→ Contact us for an assessment of your infrastructure