Why infrastructure control matters more than ever in 2026
Vates runs near 150 people. We are growing internationally, and we do it mostly on open-source, self-hosted tools. Here is what that actually looks like in practice, and why it matters.
Every organization depends on software. The question is how aware it is of that dependency, and what happens when the terms change.
Over the past few years, several events have made that question harder to ignore. Broadcom's acquisition of VMware, Red Hat's decision to restrict access to RHEL source code, the growing geopolitical pressure on cloud providers: these are not isolated incidents. They reflect a broader pattern. The tools and platforms organizations build their operations around can shift, and when they do, the cost of not having planned for it can be significant.
At Vates, we have thought about this from day one. Open source and on-premises are not recent decisions. They are part of how the company was built. Of course, our main business is actually to sell support to our customers for their open-source virtualization infrastructure so we might be a bit biased. We run our own operations the same way. And as the company has grown to close to 150 people, that commitment has not changed.
🔗 Summary
What lock-in actually costs
The risks of vendor lock-in are not abstract anymore. The VMware acquisition by Broadcom illustrated them clearly.
Overnight, organizations running production infrastructure on VMware had to reassess licensing costs, renegotiate contracts, or start planning migrations they had not anticipated. We have been helping customers through that transition since 2022, and what it taught us is that migrating 100% of an infrastructure under time pressure is genuinely hard. It requires internal change management, team retraining, and significant engineering effort. For organizations that had not planned for it, those constraints were painful. Real-world examples, from Biocoop to Fujifilm MicroChannel, are well documented in our customer stories.
But virtualization is only one place where this happens. Three other patterns are worth looking at, because together they show that the problem is structural rather than tied to one acquisition.
Licensing terms can change even when you never move. Microsoft raised list prices on its standalone on-premises server products by around 10% in July 2025, followed by increases of 15% on the Core CAL Suite and 20% on the Enterprise CAL Suite. In the same wave, Exchange Server and Skype for Business Server moved to Subscription Edition, which requires active Software Assurance or cloud subscription licenses to deploy at all (Microsoft's own announcement). Nothing about those customers' infrastructure changed. The commercial terms around it did.
The self-hosted option can simply be withdrawn. Atlassian stopped selling Server licenses in 2021 and ended support in February 2024, pushing customers toward Cloud or toward Data Center, the remaining self-managed option. Many organizations in regulated sectors chose Data Center precisely to stay on their own infrastructure. In September 2025, Atlassian announced its end of life: no new Data Center subscriptions for new customers after 30 March 2026, a final purchase date of 30 March 2028, and licenses expiring into read-only mode on 28 March 2029. Those teams are now migrating a second time in five years, and this time there is no self-hosted destination to migrate to.
June 22, 2026•8 min
And the economics of rented infrastructure are being re-examined. Cloud repatriation has moved from contrarian opinion to documented practice. 37signals, the company behind Basecamp and HEY, is the clearest case. After an annual AWS bill above $3.2 million, it spent roughly $700,000 on Dell servers and cut about $2 million a year from its cloud costs, then moved its remaining petabytes off S3, bringing projected savings to more than $10 million over five years. Their CTO is honest that the comparison is never fully apples to apples, and he is right: hardware refresh cycles, power, and operational staffing all belong in the calculation. The point is not that on-premises is always cheaper. It is that for stable workloads, the assumption that it is not cheaper deserves to be tested rather than inherited.
Simon Sharwood
Four different vendors, four different mechanisms, one common thread: the customer had no say in the change and limited time to respond.
Broadcom's acquisition of VMware led many organizations to face licensing cost increases of 5x to 10x practically overnight. Those who had not planned for vendor dependency found themselves with limited options and short timelines.
The real question is no longer cloud versus on-premises
Public cloud is a legitimate option for many workloads. The flexibility it offers is real, and for organizations that need to scale quickly or avoid upfront hardware investment, it makes sense.
But flexibility comes with trade-offs worth understanding. Cloud spending tends to run higher than on-premises for stable workloads that do not require elastic scaling, which is exactly what the repatriation cases above illustrate. And cost is only one of the two forces at work here. Gartner has introduced the term geopatriation to describe something narrower than cloud repatriation: not moving out of the public cloud because it is expensive, but moving workloads under a jurisdiction you consider acceptable. The distinction matters because the second question does not go away once the first one is answered. Gartner found in November 2025 that close to two-thirds of CIOs and IT leaders in Western Europe expect geopolitics to increase their reliance on local or regional cloud providers.
Beyond cost and jurisdiction, there is an infrastructure control question worth asking. When your virtual machines run on infrastructure you do not manage, visibility into where your data sits, who else shares the same physical hardware, or what happens if a provider's policy changes becomes limited. For organizations handling personal data or operating in regulated sectors, that is a practical concern, not a theoretical one.
Which is why framing this as a binary choice misses what is actually happening in the field. Most organizations are no longer choosing between cloud or on-prem. They are building distributed infrastructures where workloads run wherever it makes the most sense: private cloud, public cloud, edge or dedicated environments. That model has a name, Distributed Hybrid Infrastructure, and it changes what you should be asking of your virtualization layer.
It has to run the same workloads in different places. XCP-ng runs on a datacenter cluster, on a two-host setup in a remote site, or on a small box at the edge, with the same hypervisor and the same VM format throughout. It has to be manageable as one system rather than as a collection of islands. Xen Orchestra provides that single management layer, so backups, replication, monitoring, and access control follow the same rules wherever a workload happens to live. And it has to make movement cheap. When the virtualization layer is consistent across environments, migrations become progressive instead of big bang: you move one workload, verify it, and move the next, on your own schedule rather than a vendor's renewal date.
Vates VMS provides the virtualization layer on which this model is built, combining XCP-ng and Xen Orchestra into a single platform. That is the same layer we run our own company on.
What we actually run
We are not describing an abstraction. Here is the self-hosted stack we use internally to run Vates as a company.
For email and calendaring, we use BlueMind instead of Gmail or Outlook. For analytics, Matomo instead of Google Analytics. For marketing automation, Mautic instead of Mailchimp. For CRM, EspoCRM instead of HubSpot. For video conferencing, BigBlueButton instead of Google Meet or Teams. For file storage and collaboration, Nextcloud instead of Google Drive. For internal chat, Element instead of Teams or Slack.
All of it runs as virtual machines on Vates VMS, on our own hardware, in our own racks. We are our own first customer, which is a useful position to be in: when something in XCP-ng or Xen Orchestra is awkward to operate, we find out the same week our users would. We have written before about how our own production infrastructure is built.
Nothing here depends on a proprietary platform whose pricing or availability could change without notice. And this is not a setup reserved for infrastructure specialists. These tools are used day to day by close to 150 people across engineering, marketing, sales, and support. Open source at scale is not a niche practice anymore.
Open source as a structural safeguard
The reason this stack is sustainable is not just about cost. It is about the nature of open-source software as a protection against commercial overreach.
When a vendor's business model starts to diverge from what users actually need, open source creates a credible alternative, and the code can be forked: it is what happened with XCP-ng.
In late 2017, Citrix announced significant restrictions on the free edition of XenServer, locking key features behind paid licensing with no public build documentation and no path for community contributions. The community was left without a clear path forward. Vates forked the project, launched XCP-ng in March 2018, and it is now the largest distribution of the Xen hypervisor. Users who would otherwise have been stranded had somewhere to go.
That backstop does not exist with proprietary software. If a vendor discontinues a product or restructures its licensing, users have limited options and limited time.
We should be clear about one thing, though: whether open source is reliable enough for production has not been a serious question for years: it runs the majority of the world's servers, networks, and cloud platforms, including the ones sold by the vendors discussed above. What still separates a good outcome from a bad one is whether there is active support and maintenance behind the software you depend on. An unmaintained project is a risk regardless of its license, and "we have the source code" is not an operational answer at three in the morning.
That is exactly where our model sits, and it is worth stating plainly. Customers are not buying access to software. They are buying expertise, support and long-term continuity around software that remains open. The code stays available either way. What you pay for is the guarantee that someone qualified is responsible for it, and the assurance that you are never locked out of your own infrastructure if you stop paying.
- Thierry Carrez, General Manager of Linux Foundation Europe (The Register, April 2026)
How does Vates reduce vendor risk?
Discover how its open-source model and support-driven strategy ensure long-term continuity and true infrastructure independence.
Sovereignty is becoming a requirement
Digital sovereignty used to be a concern for government agencies and a handful of regulated industries. That has changed significantly.
At KubeCon Europe 2026 in Amsterdam, digital sovereignty was one of the dominant topics across keynotes, vendor booths, and hallway conversations. A sold-out Open Sovereign Cloud Day opened the conference. Thierry Carrez puts it plainly: there is no purely technical answer if a government compels a US-based company to restrict access to your data or services. The risk is no longer theoretical.
Today, organizations across sectors are being asked to demonstrate where their data lives, who has access to it, and under what legal jurisdiction. Proprietary platforms have made moves toward European-compliant offerings, but the underlying question remains: do you control your infrastructure, or does someone else?
On-premises, self-hosted systems with auditable open-source software give a clear answer to that question. That answer is increasingly valued, and in some sectors it is becoming a requirement. Exodata and the DRAC Grand Est both went through that reasoning before choosing their platform.
Not about ideological purity
We are not arguing that every tool needs to be open source, or that the public cloud is never the right answer.
There are workloads where cloud flexibility makes sense. There are tools where proprietary solutions offer genuine advantages and where the dependency risk is low. The goal is not to avoid every external vendor. It is to understand your dependencies, evaluate them honestly, and avoid situations where a vendor's commercial decisions can force your hand.
That means asking real questions when adopting a new tool. Can the data be exported? Is migration realistic in three years? Is pricing predictable? Are we building operational knowledge around an open standard or a proprietary workflow? And the one the Atlassian case makes unavoidable: if the deployment model I chose disappears, what is my fallback?
Growing without defaulting to hyperscalers
There is a widespread assumption in the industry that growth naturally pushes companies toward centralized proprietary platforms. The operational convenience is real, and the path of least resistance points in that direction.
Our experience has been different. As Vates has grown, we have continued investing in open-source tooling across our internal operations. Sometimes that requires more engineering effort. But it also means we understand the systems we depend on, we can adapt them, and we are not subject to pricing changes we cannot anticipate.
That is the same thing we are building for customers: a distributed infrastructure that remains manageable, auditable, and resilient over time, wherever the workloads happen to run.
The conversation about infrastructure control is no longer niche. The conditions that used to make it easy to defer that conversation have changed. We think it is worth having now.
Want to see how Vates VMS fits your infrastructure? Talk to us directly and we will walk you through it.