Switching your RMM: a migration checklist
Migrating an RMM is mostly a rollout problem, not a data problem, and it goes wrong in predictable ways: agents that conflict, monitoring gaps nobody notices for a week, and a decommissioning step that gets forgotten until the invoice arrives. This checklist is vendor-neutral and works in either direction.
Published August 7, 2026
The one rule
Never cut over in one step. Run both systems in parallel for a defined period, verify the new one against the old one, and only then remove the old agent. The parallel period is what turns a migration from an event into a process, and it costs one month of overlapping licence fees — far less than one missed outage.
The second rule follows from the first: decide the exit criteria before you start. Write down what "the new system is working" means in checkable terms, because otherwise the parallel period extends indefinitely and you end up paying for two systems out of nervousness rather than evidence.
The six phases
In order. Do not start the agent rollout before the policies exist, or you will have a fleet of monitored machines producing alerts nobody has configured.
- 1
Inventory and export
Export everything from the old system while you still have access: device list with identifiers, customer and site structure, monitoring thresholds, scripts, scheduled jobs, documentation and credentials. Do this first — access to an export gets harder once notice is given.
- 2
Rebuild the structure
Recreate tenants, sites and device groups in the new system before any agent arrives. Getting the hierarchy wrong is expensive later because policies, permissions and reporting all hang off it.
- 3
Rebuild monitoring policies
Do not copy thresholds mechanically. A migration is the rare chance to drop the alerts your team has been ignoring for two years. Start from what you actually act on, and add the rest only if you miss it.
- 4
Pilot rollout
Deploy the new agent to a small representative group — one machine per operating system, per customer type, per awkward network. Run both agents side by side and compare what each reports for a week.
- 5
Fleet rollout
Roll out through whatever deployment channel you already trust: the old RMM itself is usually the best distribution tool for the new agent, alongside GPO, Intune or a scripted install. Track coverage as a number and chase the stragglers explicitly.
- 6
Cutover and decommission
When coverage and alerting are verified, stop acting on the old system, then remove its agents, then close the contract. In that order — removing agents before you are confident leaves you blind, and closing the contract first can cost you the export.
The pitfalls that actually bite
These are the ones that generate incidents rather than annoyance.
Two agents fighting over patching
If both systems are approving and installing updates, machines get conflicting instructions and reboot at unhelpful moments. During the parallel period, exactly one system owns patching — usually the old one until cutover.
Silent monitoring gaps
Coverage is easy to overestimate. Machines that were offline during rollout, or that failed the install quietly, produce no alerts — which looks identical to a healthy machine. Reconcile the new device list against the old one by count and by name, not by impression.
Losing scripts and institutional memory
Automation accumulated over years is rarely documented anywhere but the old console. Export scripts and scheduled jobs early, and note what each one is for while someone still remembers.
Forgetting the decommission
Old agents left installed keep consuming licences, keep an unnecessary remote access path open on every endpoint, and become unpatched software. Removal is part of the migration, not an afterthought.
How long it realistically takes
For a fleet of a few hundred devices with a small team, plan four to six weeks end to end. Roughly one week for export and structure, one week for policies, one week of pilot, one to two weeks of fleet rollout, and a final week of parallel verification before cutover.
The variable that dominates is not device count but the number of distinct environments: operating systems, network topologies and customers with their own change processes. Two hundred identical office laptops migrate faster than forty machines across eight customers with different maintenance windows.
Do not schedule the cutover immediately before a period when nobody is available. The week after cutover is when the gaps surface, and that is exactly when you want the people who did the rollout still around.
Before you commit to a new platform
Worth confirming during the trial, because each of these is painful to discover mid-migration.
- Agents install unattended on every operating system in your fleet, including the versions you would rather not talk about.
- The new agent can be deployed through your existing channels — installer, GPO, script or the outgoing RMM.
- Monitoring policies can be applied by group rather than per device, or the rebuild will take far longer than planned.
- Your ticket history and documentation can be moved, or you have decided consciously to leave them behind and keep read access to the old system.
- Export from the new platform works, so this migration is not the last one you are ever able to do.
- Whether the trial is long enough to cover a full patch cycle — a two-week evaluation rarely surfaces what a month of real operation does.