The VMware Exit Playbook: How to Bank an 85% Licensing Saving Without Losing Control Mid-Migration

Tottenham Hotspur just did what thousands of IT departments are being pushed to do right now: they dropped VMware. Per The Register, the club is citing an 85% licensing saving as part of a wider infrastructure replacement and upgrade project with HPE. They are not alone — since Broadcom's licensing overhaul, IT managers everywhere are evaluating Proxmox, Hyper-V, Nutanix, and HPE's own stack. This is the biggest replatforming wave in a decade.

Here's what nobody puts in the business case: the migration itself. The licensing saving is a line item. The migration is ten weeks of running two hypervisors at once, half your monitoring checks pointed at a vCenter you're about to decommission, and your helpdesk finding out about last night's cutover from an angry user.

If you're the sysadmin running that migration — or the MSP tech supporting a dozen clients doing it simultaneously — read on.

Why Hypervisor Migrations Break IT Operations

Your monitoring is married to the platform you're leaving

If your monitoring lives inside vCenter, Aria Operations, or host-level ESXi checks, decommissioning starts killing your visibility before you finish migrating. Wave 3 moves 60 VMs to the new HPE estate, and your capacity dashboards go flat because half your workloads stopped reporting to the old stack. The new environment? Someone will build dashboards for it. In week seven. Maybe.

Your RMM doesn't understand the virtualization layer

Most RMM tools — NinjaOne, ConnectWise, Datto — treat every device as a generic endpoint. They'll patch Windows and push agents, but they have no idea that VM-APP-041 sits on esx-prod-07, which shares a datastore with the SQL cluster you're moving in wave 4. So the tech who needs context opens vSphere in one tab, the RMM console in another, the ticketing system in a third, and a spreadsheet runbook in a fourth. Twelve tabs, five tools, one change window.

Nobody has a dependency map

Ask your team which applications break if you power off a given VM mid-cutover. The honest answer is usually a shrug. Infrastructure data lives in one system, endpoint data in another, the CMDB in a third — none of them current. Migration exposes that rot fast, usually at 11pm on cutover night.

The helpdesk is blind to the project

It's 8:45am after wave 3. The ERP is slow. Users file tickets. The helpdesk — with no link to your migration runbook — treats them as routine performance issues and starts the standard triage dance. Meanwhile the infra team knows exactly what happened: the migrated database VM landed on a host with a misconfigured storage policy. Time from first user complaint to correct diagnosis: 55 minutes. It should have been 5.

The compounding cost

• Longer downtime. Incidents discovered by users instead of monitoring add 30–60 minutes of diagnosis, because the first hour is spent proving where the problem isn't.
• Unnecessary rollbacks. Without before/after baselines, it feels slower since the move is unanswerable, so teams roll back VMs that were never the problem.
• Ticket spikes. A poorly coordinated wave cutover can double next-day ticket intake.
• Burnout. The engineer doing cutovers at 10pm in vSphere, documenting in Confluence, and answering tickets in a separate system is doing three jobs at once. That's how good people leave.

How AlertMonitor Changes the Migration Math

One agent, one console, one timeline. AlertMonitor monitors your hypervisor hosts, VMs, Windows endpoints, and network in the same console your techs use for remote sessions and script execution. When the old vCenter is decommissioned, your operations workflow doesn't break — because monitoring never depended on it.

Topology mapping before you move anything. AlertMonitor's network topology shows what talks to what. Before wave planning, you can see that the undocumented license server sits next to your ERP app servers — and avoid the 9am surprise.

RMM where the alerts are. The technician who gets the storage-latency alert on a wave-3 host opens a remote session to that host — or any of its VMs — from the same alert, in the same window. No context switching. No separate RMM login. No waiting for someone with vSphere rights.

Script jobs across device groups. Define a device group per migration wave. Push a pre-cutover health check to all 60 VMs in one job. Run post-cutover validation the same way. Script results feed back into the same timeline as alerts and tickets, so when someone asks what changed on VM-APP-041 last night, the answer is one filter away — not an archaeology project.

Maintenance windows that actually work. Scope alert suppression per wave and per device group so cutover night doesn't generate 400 pages. The morning after, alerting is back at full sensitivity automatically.

Patching carries over. The new HPE estate and its VMs join your existing patch schedules on day one. A migration should never reset your compliance posture — in AlertMonitor, it doesn't.

The net effect: change-window verification drops from hours to minutes, and post-cutover incident diagnosis shifts from user-reported the next morning to caught by monitoring before users noticed. That's the difference between a migration and an outage with extra steps.

Practical Steps: A Migration Runbook With Unified RMM

1. Build the real inventory before touching anything

Export a complete VM inventory from vCenter so wave planning is based on data, not tribal memory:

# Requires VMware PowerCLI: Install-Module VMware.PowerCLI
Connect-VIServer -Server vcenter.corp.local
Get-VM | Select-Object Name, PowerState, NumCPU, MemoryGB,
    @{n='ProvisionedGB';e={[math]::Round($_.ProvisionedSpaceGB,1)}},
    @{n='Host';e={$_.VMHost.Name}},
    @{n='Datastore';e={(Get-Datastore -VM $_).Name}},
    @{n='Notes';e={$_.Notes}} |
    Export-Csv -Path 'C:\Migration\vm-inventory.csv' -NoTypeInformation

Use this inventory to build your wave plan — and matching device groups in AlertMonitor — so every migration wave is a managed set of devices, not a spreadsheet.

2. Run a pre-cutover health check on every VM in the wave

Schedule this as an AlertMonitor script job against the wave's device group, 24 hours before cutover:

$servers = Get-Content 'C:\Migration\wave3-targets.txt'
foreach ($server in $servers) {
    Invoke-Command -ComputerName $server -ScriptBlock {
        [PSCustomObject]@{
            Server      = $env:COMPUTERNAME
            OS          = (Get-CimInstance Win32_OperatingSystem).Caption
            LastBoot    = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
            StoppedAuto = (Get-Service | Where-Object {$_.StartType -eq 'Automatic' -and $_.Status -ne 'Running'}).Name -join ';'
            FreeDiskGB  = [math]::Round((Get-PSDrive C).Free/1GB,1)
        }
    } | Export-Csv -Path 'C:\Migration\wave3-precheck.csv' -Append -NoTypeInformation
}

Anything with stopped automatic services or low disk gets fixed before it moves — not diagnosed after.

3. Validate critical services immediately after cutover

The morning after a wave, run a validation job across the migrated group:

$critical = @('MSSQLSERVER','W3SVC','DNS','Spooler')
foreach ($svc in $critical) {
    $s = Get-Service -Name $svc -ErrorAction SilentlyContinue
    if ($s) { '{0},{1},{2}' -f $env:COMPUTERNAME, $svc, $s.Status }
}

In AlertMonitor, the job output lands in the same timeline as the alert history for those devices — so your validation evidence is attached to the change permanently.

4. Don't forget the Linux workloads

Your new HPE estate will likely carry Linux VMs too. A quick post-migration health snapshot:

#!/bin/bash
# Post-migration health check for a Linux VM
echo "=== $(hostname) ==="
uptime
df -h --output=source,size,used,pcent,target -x tmpfs -x devtmpfs
echo '--- Failed units ---'
systemctl list-units --state=failed --no-pager
echo '--- Network listeners ---'
ss -tulpn | head -20

5. Baseline, then compare after a week

Capture CPU, memory, and disk baselines immediately post-migration and again seven days later. When a user says it feels slower since the move, you answer with data. Because AlertMonitor holds monitoring data from both sides of the cutover in one platform, the answer takes minutes — not a war room.

The Takeaway

Spurs' 85% saving is real, and the industry-wide VMware exit isn't slowing down. But the saving only materializes if the migration succeeds — and migrations fail in the gaps between tools. The teams that come out the other side cleanly are the ones where monitoring, remote management, patching, and alerting were never separate things to begin with.

One console. One timeline. One place where the alert, the remote session, the script result, and the ticket all live together. That's how you bank an 85% saving without paying for it in downtime.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources