Can you run two RMM agents at once? A safe two-week overlap during a switch

Yes, you can run two RMM agents at the same time on the same machine, and during a platform switch you usually should. The agents themselves rarely conflict. What conflicts is what they are told to do: two patch engines, two sets of reboot rules, two security stacks and two self-healing scripts all acting on one endpoint. A safe overlap is about deciding which tool owns each job, client by client, for about two weeks. Here is how to split it.

Why a parallel deployment beats a hard cutover

The tempting plan is to uninstall the old agent and push the new one in the same script. It looks tidy. It is a gamble, because any device that fails the install, is switched off that night or sits on a laptop in someone's car drops out of management entirely, and you will not know until it raises a ticket you cannot answer.

Running both agents means the old platform remains your safety net while the new one proves it can see, reach and fix every device. You remove the old agent only once the new one has checked in, reported inventory and completed a patch cycle. The wider sequence is covered in our guide on how to switch RMM platforms without dropping a single endpoint; this piece deals with the overlap itself.

Where two RMM agents actually conflict

Two well-built agents run as separate services, with separate folders and separate outbound connections. They do not fight over CPU or ports in any meaningful way. The trouble lives in the policies layered on top.

Patching: two engines, one Windows Update

This is the big one. Most RMM patching works by controlling the Windows Update agent, either through registry policy, through its own scheduler, or both. If the old tool writes one set of Windows Update for Business settings and the new tool writes another, the last writer wins, and that changes depending on which agent ran most recently. You get approvals ignored, deferrals reset and, worst of all, reboots at times nobody agreed to.

Third-party patching duplicates differently. Two tools each trying to update Chrome or Zoom will mostly just race each other, but two tools with different version rules can roll an application backwards and forwards. If your new platform uses winget under the hood, see our note on winget for patch management for how it decides what to install.

Reboots and maintenance windows

Each platform has its own idea of when a machine may restart and how users are warned. Two sets of prompts, at two different times, is how a client's finance director ends up rebooted mid-payroll. Treat reboot policy as part of patching ownership, not a separate setting.

Self-healing and scheduled scripts

Automated remediation is a quiet source of chaos. The old tool restarts the print spooler when it stops; the new tool's script stops it to clear the queue. Each is behaving correctly. Together they are a loop. Audit every scheduled script and condition-based action on the old platform before the overlap starts.

Antivirus and EDR

Two problems here. First, your security product may flag the new agent, because an unfamiliar binary that runs as LocalSystem, opens remote sessions and executes PowerShell looks exactly like what EDR exists to catch. Second, if the old RMM deploys and manages antivirus, the new one must not deploy its own alongside it. Two real-time AV engines on one machine is the one genuine, performance-wrecking conflict in this whole exercise.

Antivirus exclusions to set before deployment

Do this before the first agent goes out, not after the first quarantine.

• Exclude the new agent's install folder. Use the paths the vendor documents, typically under Program Files and ProgramData. Skip this and the agent may install, then be quarantined minutes later.
• Exclude its working and script folders. Agents usually drop scripts to a temporary directory before running them. Without an exclusion, every automation run is a potential alert.
• Allow its processes and signing certificate. Where your EDR supports publisher or certificate trust, prefer it over path exclusions, which are broader than they look.
• Leave the old agent's exclusions alone. Remove them only after that agent is uninstalled, as the last step of the cleanup.

If you manage Defender centrally, push these through the tenant rather than per device. Our piece on Microsoft 365 and Defender monitoring covers watching that layer properly.

How to split policies while you run two RMM agents

The principle is ownership by function and by client. The old platform keeps doing everything it currently does, except the jobs you have explicitly handed over. The new platform starts in observation mode and gains duties in waves.

Two details matter. Disable a policy in the old tool before enabling its equivalent in the new one, so there is a short gap rather than an overlap. And change ownership per client, not per function across the whole estate, so a problem stays contained to one site, whether the machines belong to clients or to your own company.

A safe two-week overlap, step by step

1. Before day one: audit the old platform. Export patch policies, reboot windows, scripts, alert thresholds and AV settings. You cannot split what you have not written down.
2. Days 1 to 2: deploy the new agent with every active policy switched off. Monitoring only. Confirm check-ins against the old tool's device list. The headcount test: every device in the old console has a twin in the new one, or a written reason why not.
3. Days 3 to 5: compare alerts side by side. Missed or extra alerts tell you which thresholds need tuning before you trust the new tool to wake you up.
4. Days 6 to 10: move patching for one or two pilot clients. Turn off the old patch and reboot policies for those clients first, then enable the new ones. Watch one full patch cycle land.
5. Days 11 to 13: roll the remaining clients across. Same order: disable old, enable new, verify. Hand over AV last, and only with a clear uninstall-then-install sequence.
6. Day 14: remove the old agent. Uninstall through the old platform while it still works, then remove its leftover exclusions and registry policy. Skip the cleanup and stale Windows Update keys will haunt your patching for months.

Failure modes compared

A hard cutover fails loudly but late: devices simply vanish, and you discover them one ticket at a time. A badly run overlap fails noisily and early: double reboots, AV alerts, scripts in a loop. A well-run overlap fails quietly and recoverably, because at every stage one tool still owns each job and the other is watching. That is the whole point. Platform-specific gotchas are in our guides to leaving Atera and other vendors.

Where this fits with Helios

Most of this plan is discipline, not tooling, and it applies whichever platform you move to. Helios is built to sit alongside an existing RMM during exactly this kind of overlap: you can deploy the agent with monitoring only, then switch on patching, scripts and remote access client by client as the table above suggests. Helio, the AI agent, can help port and test scripts, but deciding who owns what during the overlap is still your call. If you want to see how it stacks up against the tool you are leaving, the comparison pages are a sensible place to start, and the 14-day trial needs no card, which is long enough to run the full overlap described here.

Researched and written with Helio SEO, our AI writer for business blogs.