Your VMware renewal is a decision, not an invoice.
We migrate VMware estates to OpenStack or Proxmox with continuous replication and a per-VM cutover measured in minutes — not a weekend outage, and not a one-way door.
What changed
Broadcom ended perpetual VMware licences in January 2024 and moved everything to subscription. What followed is documented rather than anecdotal:
European cloud providers have reported increases in this range, with many seeing licensing costs rise roughly tenfold.
Reported by provider membersAT&T stated in a court filing that Broadcom proposed an increase of this size at renewal.
AT&T v. Broadcom, court filingCISPE, the European cloud infrastructure trade body, filed a formal competition complaint against Broadcom with the European Commission.
CISPE complaint, European CommissionIf your renewal quote looks unreasonable, it isn't a negotiating position aimed at you specifically. It's the model.
Your options, honestly
There are five, and three of them don't involve us.
Renew.
Sometimes correct. If your estate is small, your renewal increase is tolerable, and your team has no appetite for change, paying is cheaper than migrating. We'll tell you if we think that's your situation.
Negotiate.
Worth doing regardless. Multi-year commitments and larger bundles move the number. Get a migration plan costed first — it is the only leverage you have, and it works whether or not you use it.
Move to a hyperscaler.
Viable, and occasionally right. Be aware you're solving a lock-in problem with a lock-in problem, and that the running cost usually exceeds the VMware renewal you're escaping within two to three years.
Move to Proxmox.
The shortest path. Closest conceptual mapping to vSphere, lowest operational weight, fastest to get a team productive on. Best fit for straightforward VM consolidation.
Move to OpenStack.
More re-architecture, more capability. The right answer if you need multi-tenancy, an API-driven platform, or you're building something your own customers will consume.
We run both Proxmox and OpenStack, so we have no reason to steer you toward either. Most providers only run one, which is why they only recommend one.
How the migration works
Discovery
We inventory the estate: VMs, dependencies, storage layout, network topology, licensing exposure, and which workloads tolerate what. You get the plan and the risks in writing before anything moves.
Target build
The OpenStack or Proxmox environment is built and tested while VMware keeps running production. Nothing is touched yet, and you can walk away at this point having lost nothing but time.
Continuous replication
Disks replicate block-level from VMware to the target while the source VM keeps serving traffic. The copy stays current as the workload changes, so the final sync is small.
Cutover
A final incremental sync, then the switch. Per-VM downtime is the length of that last delta plus boot time — minutes, not hours. Cutovers run in waves, on your maintenance windows, at whatever pace your change process allows.
Rollback stays available
The VMware source is left intact and bootable until you sign off. If a workload misbehaves after cutover, you go back in minutes rather than restoring from backup.
What "without downtime" honestly means
Load-balanced and horizontally scaled tiers move with no user-visible interruption. Instances are cut over one at a time behind the balancer. Your users see nothing.
Stateful single-instance VMs need a brief stop to guarantee a consistent final sync — databases, legacy application servers, anything holding state in one place. That’s minutes, scheduled, and agreed in advance.
Anyone promising literally zero downtime for a stateful VM is either describing an HA pair you already have, or hasn’t done this.
What we commit to
What we will underwrite depends on the estate — how much of it is load-balanced, what holds state, and what your change process allows. We put the commitments in writing once we have scoped it, in the cutover plan, rather than publishing a guarantee before we have seen your environment.
If you want specifics before that, ask the team.
What tends to be difficult
Stated up front, because you'll find out anyway:
Windows guests
Need driver changes for VirtIO. Routine, but it's a per-image step.
Deeply nested vSphere features
DRS affinity rules, distributed switches, custom storage policies — these have equivalents rather than direct translations. Some get simpler; a few need redesign.
Third-party appliances
Shipped as VMware-only OVAs, they may need vendor support or replacement.
Licensing tied to hardware IDs
Can require reissue. Worth checking early, because vendors are slow.
Anything undocumented
The VM nobody owns, running something nobody remembers. Discovery finds these, and finding them is half the value.
Timeline and cost
Discovery, build and cutover length scale with the size and shape of the estate, and with how many waves your change process will absorb. We put a schedule in writing after discovery rather than publishing week counts that would not survive contact with your environment.
The comparison that matters isn’t migration cost against zero. It’s migration cost, plus what you’ll pay to run the target, against your renewal quote over the same period. Ask us for a costed plan — it is useful even if you end up renewing.
Frequently asked
Can you migrate while we're still under VMware contract?
Yes, and it's usually the right sequence. Build and replicate during the remaining term, cut over before renewal. That way the migration is finished when the invoice arrives rather than starting because of it.
How long do we need to keep VMware running?
Through cutover and your sign-off period. We size the overlap in discovery so you're not paying for both longer than necessary.
What if we're mid-renewal negotiation?
Talk to us anyway. A costed migration plan is leverage in that negotiation, and plenty of teams use it that way and then renew. We'd rather be part of an honest evaluation than not in the conversation.
Do we have to move everything?
No. Hybrid is common — move what benefits, leave what doesn't. Some estates keep a small vSphere footprint for one stubborn application.
Who runs it afterwards?
Whichever you prefer. Fully managed, co-managed, or we hand over documentation and training and your team runs it. The handover promise applies here as everywhere else.
Can we migrate to our own hardware rather than yours?
Yes. If your servers are already racked somewhere, that's often the cheapest good answer and we'll say so.
What happens if the migration goes wrong?
The VMware source stays intact and bootable until you sign off. Rollback is minutes, not a restore.
Tell us what needs to run.
Send us the workload, the constraints, and the region it has to live in. An engineer — not a sales rep — will tell you honestly whether we're the right fit.