Solution Atlas
EverydayUser storyConsultative playbook

We need to leave VMware before our next renewal

After Broadcom's price changes, the VMware bill has tripled. The CIO has approved a 12-month programme to move the workloads to Azure. The platform team needs a defensible plan covering compute, storage, networking, and disaster recovery — without disturbing what runs today.

Trigger
Renewal cost shock from VMware; board has mandated an exit.
Good outcome
The customer leaves VMware before the renewal hits. The first wave of workloads is already running on Azure, the disaster-recovery story is proven end-to-end, and Finance has a clear picture of what comes off the VMware bill each quarter.
Discovery — signals and questions

Signals validating this story

  • ·VMware renewal quote materially higher than prior term
  • ·VMware estate at or near the next hardware refresh cycle
  • ·Engineering team has limited Azure-native experience
  • ·DR currently dependent on VMware Site Recovery Manager
  • ·Board mandate to exit or materially reduce VMware spend

Discovery questions

  1. 1.What is the current VMware estate — hosts, VMs, vSAN, NSX, SRM?

    WhySizes the migration surface and identifies dependencies that travel forward.

  2. 2.When does the next VMware renewal hit and what is the indicative quote?

    WhySets the deadline. Renewal date drives migration cadence.

  3. 3.Which workloads must stay on-prem — latency, regulatory, OEM-bound?

    WhyDetermines Azure Local scope vs Azure VM placement.

    Listen for: “plant floor” · “regulated data” · “specialised hardware”

  4. 4.What is your migration capacity — internal team, partner-led, or hybrid?

    WhyDrives the programme shape and timeline.

  5. 5.What does DR look like today and what would replace VMware SRM?

    WhyAzure Site Recovery is the canonical replacement but needs explicit RTO/RPO design.

  6. 6.What is the app-modernisation appetite — replatform vs refactor?

    WhySurfaces whether this is a pure-lift programme or also a modernisation opportunity.

Baseline architecture → Target architecture
Baseline architecture

VMware vSphere clusters with vSAN storage, NSX networking, and (in many estates) Site Recovery Manager for DR. Aging hardware on a 3–5 year refresh cycle. VMware tooling not Azure-aware. No central security posture across the VMware estate.

Typical concerns

  • ·Renewal cost spiking; budget exposure
  • ·Hardware refresh due alongside renewal
  • ·Engineering team scarce on Azure-native skills
  • ·DR posture tied to VMware-specific tooling
  • ·No unified security view across VMware + cloud

Capability gaps

  • ·Migration runbook with workload-by-workload sequencing
  • ·Azure Local for workloads that must stay on-prem
  • ·Hybrid governance via Azure Arc
  • ·ASR replacing SRM
  • ·Defender for Servers across the new estate
Target architecture

Mixed Azure VM + Azure Local landing pattern. Azure Local hosts workloads that must remain on-prem (latency, regulatory, OEM-bound). Azure VMs absorb the rest. Azure Arc governs the hybrid estate. Defender for Cloud provides security posture; Azure Monitor replaces vCenter operational tooling. ASR replaces SRM for DR.

Key capabilities

  • Workload-fit landing pattern
  • Hybrid governance via Arc
  • Unified security posture
  • ASR-based DR
  • Azure-native ops substrate
Architecture decisions

  1. 1.Landing pattern — Azure VMs only vs Azure Local + Azure VMs

    Azure VMs only

    Fits whenAll workloads can move to public cloud; no regulatory or latency blockers.

    Trade-offsSome plant-floor or regulated workloads cannot move.

    Azure Local + Azure VMs (mixed)

    Fits whenSome workloads must stay on-prem (latency, regulatory, OEM-bound).

    Trade-offsTwo operating environments; hardware refresh cost.

    Default recommendationMixed pattern by default. Use Azure VMs as the destination; Azure Local for the explicit on-prem residue.

  2. 2.Migration shape — big-bang cutover vs phased per workload

    Big-bang

    Fits whenSmall estate (<200 VMs); appetite for coordinated cutover.

    Trade-offsHigh single-point risk; rollback complex.

    Phased per workload

    Fits whenMid-to-large estate; multiple workload classes with different consumers.

    Trade-offsVMware and Azure running in parallel for months.

    Default recommendationPhased per workload. Run VMware and Azure in parallel during migration.

  3. 3.Replacement tooling — native Azure only vs Veeam / partner continuity

    Native Azure

    Fits whenGreenfield team; comfort retraining on Azure tooling.

    Trade-offsSteeper learning curve; some VMware-specific features take time to replicate.

    Veeam / partner tooling

    Fits whenExisting investment in Veeam for backup; minimise change for the operations team.

    Trade-offsContinued third-party licensing; Azure-native features not fully exploited.

    Default recommendationVeeam for backup continuity in phase 1; transition to Azure Backup in phase 2 once the operations team has adapted.

Low-risk trial — proof of value

8-week assessment + first-wave migration of 50 VMs

~8 weeks

Estate discovery (Azure Migrate). Workload-fit assessment per VM class. Azure Local provisioned for the on-prem residue. First wave of 50 VMs migrated to Azure VMs. DR strategy documented with one workload validated via ASR. Defender for Cloud and Azure Monitor extended via Arc.

Success criteria

  • 50 VMs migrated with zero data loss and SLA met
  • Azure Local cluster provisioned and validated
  • ASR-based DR demonstrated for one production workload
  • Migration runbook published and validated end-to-end

InvestmentAssessment + first-wave migration ~€80–120k depending on partner involvement. Azure Local hardware capex separate (~€40–80k per cluster typical). VMware contract untouched during trial.

Proof metrics

  • ·Migration velocity (VMs per week) measured and forecastable
  • ·12-month TCO projection — Azure vs VMware renewal
  • ·Application uptime through migration above 99.9%
  • ·DR test passed with documented RTO/RPO per tier

Recommended cards

The SKUs and capabilities most likely to be part of the solution, with the editorial rationale for each in the context of this story. Add the ones that fit your situation.

Why for this story

Hosts the workloads that cannot move to Azure proper (regulatory, latency, OEM-bound). Microsoft-managed lifecycle on validated OEM hardware.

Why for this story

The governance plane across cloud + on-prem during and after migration. Brings Azure Policy, Defender, and Monitor to the hybrid estate.

Why for this story

Replaces VMware vCenter as the unified security posture surface. CSPM secure-score baseline + Defender for Servers on the migrated estate.

Why for this story

Operational substrate that replaces vCenter and vROps. Logs, metrics, alerts for the new hybrid estate.

Back to Cloud migration and modernisation