Migration from VMware

Migration from VMware

Phased migration to enterprise cloud without operational disruption

Many enterprises are reassessing their long-term dependency on VMware due to changing licensing models, cost predictability concerns, and strategic flexibility requirements.

Migrating away from VMware is not a single event. It is a controlled transformation that must preserve service continuity, application stability, and operational confidence.

whitesky provides a cloud platform and migration approach designed to support phased, low-risk VMware exits.

Migration as a process, not a project

Enterprise VMware environments typically include:

  • diverse workloads with different criticality
  • legacy systems alongside modern applications
  • complex networking and storage dependencies
  • strict operational and compliance requirements

For this reason, migration to whitesky is approached as:

  • incremental
  • reversible
  • application-aware

Coexistence between VMware and whitesky is expected during transition.

Supported migration sources

whitesky migration paths support workloads originating from:

  • VMware vSphere environments
  • hybrid VMware deployments
  • VMware-based private clouds
  • VMware workloads hosted by service providers

The same migration paths also work for workloads from Hyper-V, Nutanix, Proxmox, OpenNebula and the hyperscalers (AWS, GCP, Azure).

The focus is on workload portability, not feature-by-feature replacement.

Keep your storage arrays

Removing VMware should not mean replacing everything. VMFS ties storage tightly to VMware’s stack, so a platform change usually forces a re-evaluation of the whole storage layer: new arrays, new budgets, new procurement cycles.

With external storage integration, whitesky runs virtual machines directly on your existing SAN arrays. The design supports any SAN that can present LUNs to the servers of a Server-Set; compatibility is certified per vendor and SAN type. The feature is released and rolling out across deployed locations from October 2026.

  • keep your arrays and the investment in them, replace only VMware
  • migrate at your own pace: VM disks land on the same, familiar storage
  • no retraining: standard Linux building blocks (LVM, SANLock) instead of a proprietary datastore, conceptually similar to VMFS
  • live migration and online capacity expansion, with LUNs from different vendors in one pool
  • one management platform: everything through the whitesky portal and API
Keep your SAN arrays, replace only VMwareToday, VMware hosts run VMs on a VMFS datastore that is tied to the VMware stack, on your SAN arrays. After the migration, whitesky servers run the VMs on an External Storage Pool built from standard Linux LVM and SANLock, on the same SAN arrays. Only VMware is replaced; the arrays stay in production.TodayAfter the migrationVMware hostsVMVMVMFS datastoretied to VMware's stackYour SAN arrayswhitesky serversVMVMExternal Storage PoolLVM + SANLock, standard LinuxYour SAN arrays=Replace only VMware: the arrays stay in production
Keep your SAN arrays, replace only VMwareToday, VMware hosts run VMs on a VMFS datastore that is tied to the VMware stack, on your SAN arrays. After the migration, whitesky servers run the VMs on an External Storage Pool built from standard Linux LVM and SANLock, on the same SAN arrays. Only VMware is replaced; the arrays stay in production.TodayVMware hostsVMVMVMFS datastoretied to VMware's stackYour SAN arraysAfter the migrationwhitesky serversVMVMExternal Storage PoolLVM + SANLock, standard LinuxYour SAN arraysreplace only VMwareThe arrays stayin production
Only the layer above the arrays changes: VMFS and VMware make way for whitesky and the External Storage Pool.

A typical path: connect your existing SAN LUNs to the whitesky servers, let whitesky register and validate the storage pool, migrate VMs from VMware, then decommission VMware while the array stays in production.

A typical path that keeps the arrayFour steps: connect your existing SAN LUNs to the whitesky servers, let whitesky register and validate the storage pool, migrate the VMs from VMware, then decommission VMware. VMware runs until it is decommissioned, whitesky runs from the first step, and the SAN array stays in production throughout.1Connect yourSAN LUNs to thewhitesky servers2whitesky registersand validatesthe storage pool3Migrate VMsfrom VMware4DecommissionVMwareVMware, until decommissionedwhiteskyYour SAN array: in production throughout
A typical path that keeps the arrayFour steps: connect your existing SAN LUNs to the whitesky servers, let whitesky register and validate the storage pool, migrate the VMs from VMware, then decommission VMware. VMware runs until it is decommissioned, whitesky runs from the first step, and the SAN array stays in production throughout.1Connect your SAN LUNsto the whitesky servers2whitesky registers andvalidates the storage pool3Migrate VMs from VMware4Decommission VMwarestep 1step 2step 3step 4VMwarewhiteskyYour SAN array, in production
VMware and whitesky run side by side during the migration; the SAN array stays in production from the first step to the last.

Your storage stays. VMware goes. No forklift upgrade, no budget overrun, no migration stall. How external storage works

Migration approaches

Offline migration (planned downtime)

Offline migration is the simplest and most predictable approach.

Typical workflow:

  • workloads are shut down during a planned window
  • disks or VM images are exported
  • virtual machines are imported into whitesky
  • validation is performed before reactivation

Offline migration is well suited for:

  • non-critical systems
  • batch workloads
  • environments with acceptable maintenance windows

Nearly online migration (minimal downtime)

For workloads with tighter availability requirements, nearly online migration can be used.

This approach:

  • replicates workloads while they are still running at the source
  • synchronizes changes incrementally
  • performs a short final cutover

whitesky supports nearly online migration using third-party replication tools such as:

With proper planning (including DNS TTL reduction and application coordination), downtime can often be limited to minutes.

Offline versus nearly online migrationOffline migration: shut down, export, import, validate and reactivate, with downtime during a planned maintenance window covering the first four steps. Nearly online migration with third-party replication such as Mobiti or RackWare: replicate while the source keeps running, synchronize changes, then a short cutover, so downtime is often limited to minutes.Offline migrationsimplest and most predictableShut downExportImportValidateReactivatedowntime: a planned maintenance windowNearly online migrationthird-party replication, such as Mobiti or RackWareReplicate while runningSync changesCutoverdowntime: often minutes✓ the source keeps running
Offline versus nearly online migrationOffline migration: shut down, export, import, validate and reactivate, with downtime during a planned maintenance window covering the first four steps. Nearly online migration with third-party replication such as Mobiti or RackWare: replicate while the source keeps running, synchronize changes, then a short cutover, so downtime is often limited to minutes.Offline migrationsimplest and most predictableShut downExportImportValidateReactivatedowndowntime: planned windowNearly online migrationreplication with Mobiti or RackWareReplicate while runningSync changesCutoverdowndowntime: often minutes✓ the source keeps running
Offline migration takes a planned window; nearly online migration replicates while the source runs, so only the cutover causes downtime.

Application-level migration planning

Enterprise migrations succeed when applications — not virtual machines — are the primary unit of planning.

whitesky migration projects typically include:

  • dependency mapping
  • application grouping
  • coordinated cutover
  • rollback planning

This avoids partial migrations that leave applications in inconsistent states.

Network and identity continuity

Migration from VMware often fails due to network and identity disruption.

whitesky supports:

  • controlled network segmentation
  • predictable IP addressing strategies
  • integration with enterprise identity models
  • phased user access migration

This allows enterprises to maintain continuity during transition.

Validation, rollback, and coexistence

Every migration path must include:

  • validation steps
  • rollback options
  • defined coexistence periods

whitesky environments can run alongside VMware until:

  • workloads are validated
  • performance is confirmed
  • operational teams are confident

There is no forced “big bang” cutover.

Beyond lift-and-shift

While lift-and-shift is often the first step, enterprises typically use migration to:

  • modernize operational models
  • introduce Kubernetes where appropriate
  • improve backup and recovery architectures
  • simplify long-term infrastructure strategy

whitesky supports this evolution without requiring it upfront.

Delivery model: managed service

whitesky is delivered as a managed service, reducing operational risk during migration.

A software edition for self-operation is planned, at the earliest in 2027.

Why enterprises migrate from VMware to whitesky

  • predictable cost and long-term control
  • open standards and workload portability
  • keep existing SAN arrays in production with external storage integration
  • phased, low-risk migration paths
  • hybrid coexistence during transition
  • enterprise-grade governance and auditability

Next steps

  • identify candidate workloads for pilot migration
  • define acceptable downtime and risk profiles
  • design a phased VMware exit strategy with whitesky