Rising VMware costs & vendor lock-in: Why we switched to OpenStack

The question was not whether we would change – but how quickly we could do it.

The sale of VMware and the subsequent realignment of licensing and pricing models triggered a discussion in many companies that had barely been had before. What had been regarded as a stable, predictable technological foundation for years developed within a short time into a strategic uncertainty factor.

It was not only about rising costs. What mattered was the type of change. Pricing logic was fundamentally adjusted, models simplified – but not in favour of operators or service providers, but according to a new, one-sided vendor perspective. For companies that run virtualisation not as an isolated IT component but as the foundation of their business, that is not a detail but a structural shift.

For us at UPONU it was quickly clear: the new cost structure and lack of reliability would have seriously endangered our business model in its previous form. And that did not affect a single service, but a large part of our infrastructure – including many customer platforms, services and projects that depend on it.

It was not about optimisation, but about future viability. And therefore not about whether we would react, but how quickly we would manage to do so.

When dependency suddenly becomes real

Vendor lock-in is not a theoretical risk

Vendor lock-in is often discussed as an abstract risk: something you know, factor in and consciously accept. As long as systems run stably, prices rise moderately and roadmaps are somewhat predictable, this dependency seems controllable.

But that is exactly where the fallacy lies.

Dependency does not show itself in stable phases. It becomes real only when framework conditions change unilaterally. The current global political situation clearly shows how quickly structures once taken for granted can collapse. Especially when decisions are made outside your own sphere of influence and have immediate economic and operational consequences.

In our case, price developments were the visible trigger. The real problem, however, lay deeper. We were highly dependent on individual vendors for the core technological foundation of our company. Planning certainty, economic viability and strategic freedom were not in our hands.

Vendor lock-in is not a mistake. It is often the result of conscious decisions: for convenience, for speed, for perceived security. It becomes critical only when that decision is not regularly questioned – and gradually develops from a calculated risk into a structural dependency.

Price increases are rarely the real problem

Why it's about predictability, not individual figures

Rising prices alone are not sufficient reason for a technological upheaval. Costs change, markets move, vendors adjust their models. What matters is not the absolute level, but whether a business model can still be operated predictably under the new conditions.

For infrastructure operators – especially in the B2B environment – predictability is essential. The overriding aim is not to have the lowest prices, but to offer the best predictability. Prices must be in proportion to the benefit and remain integrable into customer business models in the long term.

In our case, that was no longer true. The new pricing logic led to a situation where future cost developments could hardly be estimated reliably. That made strategic planning difficult and business decisions risky.

The point had been reached at which “enduring” was no longer an option. Waiting would have meant accepting a dependency whose consequences we could no longer control.

A decision under massive time pressure

Why we had no transition phase

The decision to migrate did not only affect individual services or new projects, but our entire data centre operation – the foundation of internal systems and customer systems. Building a parallel test environment over years or migrating step by step was unrealistic in terms of time, as the previous vendor only allowed a 12‑month window until the terms were adjusted.

Ongoing operations had to remain stable. Customers expected availability, security and reliability – regardless of internal restructuring. At the same time it was clear: every delay increased the risk of falling into an even stronger dependency.

We had to decide under uncertainty. Not every detail was fully clear at the start, not every dependency immediately visible. Nevertheless, action was required. In such situations it becomes clear whether a company is able to take responsibility – even without perfect information.

What a complete infrastructure change really means

It was not about a platform – but about the foundation

A change of this magnitude is not a classic migration project. It is an intervention in the very foundation of the company.

We rebuilt our data centre at its core. Technical architectures, operational processes and established structures had to be questioned. Dependencies that had been barely visible before suddenly became clear.

Many assumptions that had been taken for granted for years did not stand up to closer scrutiny. That was uncomfortable, but necessary.

New build instead of refurbishment

It quickly became clear: a simple “switchover” is an illusion. Instead, a structured new build was required – technically, organisationally and in terms of processes. That meant more effort, but also the chance not to carry legacy issues forward. The financial double burden also had to be considered. Both the increased costs of the existing solution and the substantial investments in a new build had to be taken into account.

Risks, setbacks and corrections

Not everything went smoothly. Decisions that seemed to make sense in theory proved inadequate in practice. Some approaches had to be abandoned, others refined. These setbacks were time-consuming and demanding – but they forced us to analyse more deeply and plan more rigorously.

Migrations are never just an internal matter

Dependencies on third-party service providers as a critical factor

One aspect that is often underestimated in migrations is dependence on external service providers and partners. Hardly any system landscape is fully self-sufficient. Interfaces, connected services, specialised providers – all of this significantly affects scheduling and complexity.

In migration projects it quickly becomes clear: schedules can be defined internally, but not fully controlled. External dependencies have their own priorities, their own processes and their own response times. That is not a criticism, but reality.

Especially with larger changes, it becomes clear that technical feasibility alone is not enough. Successful migrations need realistic scheduling, clear communication and a willingness to plan for buffer. Anyone who ignores these dependencies risks delays and unnecessary pressure – internally and externally.

Why we consciously chose open source

Control instead of dependency

Our decision in favour of OpenStack was not a cost decision. It was a strategic one.

For us, open source means above all one thing: control. Control over our own infrastructure, over further development, over dependencies. No one-sided licence changes, no black box, no externally determined roadmaps.

This control comes with responsibility. Operations, maintenance and further development cannot be delegated. But that is exactly where the benefit lies: decisions are made in-house again – on the basis of our own requirements and priorities.

Community instead of black box

Another central aspect is the community behind open source. Knowledge is accessible, problems are transparent, further development is traceable. Instead of passive use, we participate actively, contribute experience and benefit from exchange with others.

Open source is not a counter-model to enterprise. It is a different model of responsibility.

We deliberately chose to use the OpenStack operations platform of the Sovereign Cloud Stack.

What we learned from the migration

And why we work and advise differently today

The change has lastingly changed the way we work.

Planning is now significantly more detailed and long-term. Especially with complex system landscapes, it is not enough to check technical feasibility. Dependencies, operating models and future development must be considered from the outset.

We now assess system landscapes more deeply before discussing migration strategies. Not every environment needs a complete change immediately. But every one should be understood.

And we no longer evangelise. We tell our story. Anyone who does not see the pain in it has either already resolved the issue for themselves – or has not yet felt the effects.

What this means for companies that are still dependent today

Not everyone can or must migrate immediately – but everyone needs a plan

This article is not a call for an immediate platform change. It is an invitation to actively engage with data sovereignty and dependencies.

Companies should know:

• How dependent they really are
• Which factors would enable or block them in an emergency
• Which alternatives are realistic
• How long an exit would take – and what that duration depends on

Asking these questions before external pressure arises is not activism. It is entrepreneurial responsibility.

Our conclusion

We have successfully completed the migration of our entire infrastructure. Not because it was easy – but because it was necessary. Today we operate our OpenStack platform completely autonomously, have deep migration experience and are able to safely support customers from a wide range of environments.

We do not offer a blueprint or a one-size-fits-all solution. But we show that a controlled exit is possible – if you approach it consciously, realistically and with foresight.