Every IT manager has lived a version of this moment. The migration plan is tested. The business case is approved. The new environment is staged and waiting. And then someone asks the question that changes everything: who keeps the old estate running while we cut over?
The answer, in most organizations, is the same team delivering the migration.
A recent CIO.com piece on modernization made the point bluntly: by the time a program reaches cutover, the technology itself is no longer the biggest risk — the operation around it is. Rip-and-replace assumes legacy infrastructure is the problem and replacement is the solution. In practice, the replacement creates a second estate to monitor, patch, and support, usually under a change freeze, with business units watching nervously and the same four technicians carrying both worlds on their backs.
If you are a sysadmin, an IT manager, or an MSP tech, this is not an abstract project-management concern. It is a 2 a.m. pager problem, a twelve-tab problem, and an SLA-report problem. And it is exactly the problem a unified RMM and remote management strategy can defuse.
The Parallel-Estate Tax: Why Rip-and-Replace Breaks Operations First
During any rip-and-replace program you are not running one environment. You are running two — and your tooling was never designed for that.
Fragmented tooling during dual running
The typical mid-migration stack looks like this: the legacy estate is monitored by the old RMM or a standalone Zabbix/Nagios instance, the new estate gets shiny new agents from the replacement platform, the helpdesk lives in a completely separate product, and remote access is handled by yet another tool. Every migration wave splits your endpoints further across consoles.
A scenario any MSP tech will recognize: an MSP managing 40 client tenants is migrating Windows Server 2012 R2 to Server 2022 over nine months. During wave 2, a tech supporting one client has a monitoring console, an RMM console, the ticketing system, a remote access client, and a shared drive full of runbooks open at once. The night after a cutover, a disk on an old file server fills to 100%. Its alert routes to a distribution list the project team quietly retired three weeks earlier. The first signal anyone gets is a user ticket at 8:40 a.m. — "the shares are slow." By then the disk has been pinned for nine hours, DFS replication queues are backed up, and the cutover window for that site slips by a week.
Why these gaps exist
- Siloed architecture. Monitoring, RMM, helpdesk, and patching were bought as separate products in different years. Their data never joins: an alert in one system, a ticket in another, the fix performed in a third, and no single timeline connecting them.
- Legacy endpoint reality. Old operating systems, odd builds, machines that cannot take the newest management agent. Your new tool simply cannot reach them, so a second console stays alive "just for those boxes."
- Decommissioning sequencing. Projects decommission legacy alert routing before legacy servers are actually gone. The estate keeps running — nobody is watching it.
- Human load. The team keeping the estate alive is also delivering the project. Every extra console is context-switching during the most error-prone weeks of the year.
The real cost
- Downtime gets detected by users, not monitors. Issues on the legacy estate surface as tickets, not alerts. Mean time to detect stretches from minutes to hours.
- Ticket volume climbs. Silent failures on unwatched servers become helpdesk noise, and the helpdesk data lives in a system the monitoring team never sees.
- Cutovers slip. Every operational surprise pushes the freeze date. Miss it twice and the steering committee starts questioning the whole program.
- Morale erodes. Your best infrastructure people spend their evenings in remote sessions doing manual verification, because the tooling cannot run a scripted checklist across both estates at once.
How AlertMonitor Turns a Big-Bang Cutover Into a Controlled Rollout
AlertMonitor combines infrastructure monitoring, RMM, helpdesk, patch management, and network topology mapping in a single platform — which directly attacks the operational risk the CIO article describes. Here is what that looks like in practice.
One agent, one console, both estates. Legacy and new endpoints report into the same platform, the same alert timeline, the same device groups. When a server moves from wave 1 to wave 2, it changes group — not console. Monitoring thresholds, patch baselines, and scheduled scripts follow the group, so treatment stays consistent on both sides of the cutover.
Built-in remote management where the alerts are. Technicians remotely view and manage endpoints, run scripts across device groups, push software, and open remote sessions — all from the same platform they use for monitoring. No tab-switching between a monitoring console and a separate RMM at 10 p.m. during a cutover window.
Script results feed back into the monitoring timeline. When a remediation script restarts a service at 22:14 and the alert clears at 22:16, both events sit on the same record. Automated remediations and manual technician actions are equally visible, so nobody asks "who fixed this, and did it stick?"
One patch compliance view during dual running. Instead of two consoles producing two compliance reports that nobody can reconcile, the steering committee gets one answer covering the entire estate.
The workflow, side by side
Fragmented: monitoring alert arrives by email → open the monitoring console → open the helpdesk, create a ticket → open the remote access tool, connect VPN, start a session → run commands manually → paste output into the ticket → close the alert in a different console. Four tools, seven steps, twenty minutes best case — if the alert even arrived.
AlertMonitor: alert appears on the device timeline → click through to the device → open a remote session or push a script to the group → remediation and alert-clear recorded on the same timeline. One console, one context, no relay race.
That difference is measurable. Alert-to-resolution time drops because handoffs disappear. The legacy file server disk hitting 90% produces an alert, a ticket, a remote session, and a fix in one place — and the wave-2 cutover does not slip because someone was watching the wrong dashboard.
Practical Steps: Modernize In Place, Wave by Wave
1. Group by migration wave, not by technology
Create device groups per wave — wave-1-legacy, wave-1-migrated, wave-2-legacy, and so on. Attach baseline checks and scheduled scripts to the groups so every server gets identical treatment no matter which side of the cutover it sits on.
2. Script your pre-cutover health checks and push them from the RMM
This is the checklist your techs currently verify by hand at 10 p.m. Push it as a script instead:
# Pre-cutover health check — push to a migration-wave device group
$issues = @()
foreach ($svc in 'DNS', 'DHCP', 'Netlogon', 'Spooler') {
$s = Get-Service -Name $svc -ErrorAction SilentlyContinue
if ($s -and $s.Status -ne 'Running') { $issues += "SERVICE DOWN: $svc" }
}
Get-PSDrive -PSProviderFileSystem -ErrorAction SilentlyContinue |
Where-Object { $_.Free -and ($_.Free / 1GB) -lt 10 } |
ForEach-Object { $issues += "LOW DISK: drive $($_.Name) has $([math]::Round($_.Free / 1GB, 1)) GB free" }
if ($issues) { $issues; exit 1 } else { 'HEALTHY'; exit 0 }
A non-zero exit code flags the device in AlertMonitor, and the result lands on the device timeline — visible next to the alerts and the ticket, not buried in a chat message.
For legacy Linux app servers that are part of the same wave:
# Quick health check on a legacy Linux server before cutover
df -h --output=source,pcent | awk '$5+0 > 85 {print "DISK WARNING: " $0}'
systemctl is-active nginx >/dev/null || echo "SERVICE DOWN: nginx"
uptime
3. Track patch compliance across both estates with one report
During dual running, patch posture is the question every auditor and steering committee asks. Make the check scripted and repeatable:
# Patch compliance check for a Windows migration wave
$requiredKBs = @('KB5034441', 'KB5031356') # adjust per wave baseline
$installed = (Get-HotFix).HotFixID
$missing = $requiredKBs | Where-Object { $installed -notcontains $_ }
if ($missing) {
Write-Output ("NON-COMPLIANT: missing " + ($missing -join ', '))
exit 1
}
Write-Output 'COMPLIANT'
exit 0
Run it against the whole wave group in one action. Compliance gaps surface before the cutover window, not during it.
4. Never retire legacy alert routing before legacy servers
Make it a golden rule: monitoring coverage moves with the workload, not with the project plan. In AlertMonitor this is structural — the old server stays monitored in the same console until the day it is powered off. There is no "second console nobody watches" to accidentally deprioritize in week three.
5. Log every out-of-hours action
Remote sessions and script runs are recorded on the device timeline. When a business unit asks after the cutover, "what exactly did you touch at 23:40?", the answer is a link to the record — not a technician's memory.
The Bottom Line
The core insight from the CIO article is that modernization risk is operational, not technical. You cannot eliminate the dual-running period, but you can make it cheap and safe: one console, one agent story, one patch report, one timeline for every alert, ticket, and fix. That is what turns a nerve-wracking rip-and-replace into a controlled, wave-by-wave rollout your team can actually deliver — without burning out the people doing it.
Related Resources
AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.