Move off VMware without having to build and run a new platform yourself
THE STARTING POINT
Why the decision is live now
Following Broadcom’s acquisition, sales of new perpetual licences have stopped in favour of subscription models, and general support for vSphere 7 ended on 2 October 2025.
At the same time, many organisations have seen higher or less predictable renewal costs.
For many, that means a foundation which used to be predictable now demands an active decision: extend, migrate, or take a different route.
WHAT CAN MOVE
Not every workload should be treated the same
A VMware exit starts by dividing up the estate. The assessment places each workload in one of three categories.
Can move as-is
Standardised virtual workloads that can be migrated without material changes to networking, storage, backup, appliances or integrations.
Can move after adaptation
Workloads with dependencies on networking, storage, backup, appliances or integrations that require technical adaptation before migration.
Needs a separate decision
Legacy systems, hardware-bound workloads or vendor-locked applications that require a separate decision on migration, modernisation, retirement or continued operation.
THE METHOD
How the migration runs
-
01
Discovery
Workloads, integrations, networking, storage, backup and operational requirements are surveyed.
-
02
Classification
Each workload is placed: can move as-is, needs adapting, or should stay where it is.
-
03
Pilot
Selected workloads are migrated to the target environment and tested before the rest of the estate moves.
-
04
Migration in waves
The estate moves in stages within agreed service windows, with a defined rollback plan for every wave.
-
05
Handover to operations
Responsibility for platform, workloads, monitoring, backup and support is clearly documented, after which Edora takes over the agreed platform operations.
BEFORE AND AFTER
What changes for you
| Feature | After moving to Edora | In the VMware estate |
|---|---|---|
| Virtualisation | KVM-based virtualisation via OpenStack | VMware vSphere |
| Platform operations | Operated by Edora | Your own team or an operations partner |
| Licensing model | No separate proprietary hypervisor licence | VMware subscription |
| Networking | Integrated into the Edora platform | Depends on existing architecture |
| Backup and recovery | Agreed as part of the target architecture | Existing solution and integrations |
| Automation | API, Terraform and self-service | Existing VMware tooling |
| Future exit | Open technologies, standardised interfaces and a documented exit | Depends on the VMware architecture |
THE DESTINATION
Out of one lock-in, not into the next
Edora Cloud is built on OpenStack, KVM and standardised interfaces. That reduces technical dependence on a proprietary hypervisor and makes access to resources and data easier to document.
A future exit still requires planning. Storage, networking, automation, security controls and operational responsibility all have to be described, so your organisation knows how workloads can be moved again.
Edora Cloud is European-owned and operated from Denmark. Data location, division of responsibility and exit terms are documented as part of the specific agreement.
-
A move away from VMware is an opportunity to tidy up and simplify, not just a necessity. Our role is to make the route there manageable, and to make sure the organisation lands somewhere it can also move on from.
THE ASSESSMENT
What you actually get out of the assessment
The migration assessment maps your workloads, integrations and dependencies. You get a workload map, a recommended target architecture, and a prioritised migration plan covering dependencies, service windows, expected downtime and a rollback plan. The assessment also includes a realistic timeline and a price estimate for the migration and for the platform operations that follow.
QUESTIONS & ANSWERS
What gets assessed most often before a move
Can our virtual machines be moved?
Most standardised workloads can be converted from vSphere to KVM along a well-trodden path. The assessment shows precisely what can move as-is, what needs adapting, and what should be assessed separately.
How much downtime should we expect?
That depends on the individual workload and is planned into service windows. The migration plan from the assessment states expected downtime per wave and a rollback approach.
Can we run in parallel and roll back?
Parallel operation and rollback can normally form part of the migration design, but the options depend on the individual workload, data synchronisation, and changes made during the migration. Each migration wave therefore gets its own validation criteria and a concrete rollback plan.
What changes for our operations team?
The platform is operated by Edora, so the team is relieved of hypervisor operations and licensing. In return, they work with APIs, Terraform and self-service rather than VMware tooling.
Are we tying ourselves to Edora?
Any change of supplier brings some operational and contractual dependencies. Edora Cloud is built on open technologies and standardised interfaces, which reduces the technical lock-in. Exit terms, data extraction and division of responsibility are documented in the specific agreement.
How long does a VMware exit take?
It depends on the size, complexity and dependencies of the estate. Standardised workloads can usually move first, while tightly integrated and vendor-bound systems need more planning. The migration assessment gives you a realistic timeline, split into a pilot and the migration waves that follow.