How to switch RMM platforms without dropping a single endpoint

To switch RMM platforms without dropping an endpoint, audit what you actually use, run both agents side by side, cut over one client at a time, and time the cancellation so you never pay for two tools longer than you have to. For a 200-endpoint book across a dozen clients, the whole migration fits inside a normal renewal window of about eight weeks. Migration fear keeps more MSPs on bad tooling than any contract clause does, but the migration is smaller than it looks and the overpayment compounds every month.

Audit what you actually use, not what you pay for

Before you evaluate anything, open the old tool and list what it genuinely does for you day to day. Not the feature list. The workload. For most small MSPs it comes down to a shorter list than they expect:

• Monitoring policies. Which alerts actually generate tickets you act on? Export the thresholds. Most estates run on a handful: disk space, service down, backup failure, offline device.
• Patch schedules. Rings, maintenance windows, approval rules, and which clients have exceptions. Write the exceptions down; they live in someone's head otherwise.
• Scripts. This is the big one. Export every script, then be honest about which ones ran in the last six months. In most estates it is a fraction of the library. The rest is sediment.
• Remote access habits. Who connects how, and whether any client has restrictions on unattended access.
• Integrations. Backup vendor, AV, documentation platform, accounting export. Each one is a task on the plan, not a surprise in week three.

This audit does double duty: it is your migration checklist and it is your evaluation criteria. If you have not yet picked the destination, do this first, because scoring feature lists is the wrong way to choose an RMM. Score it against your audit instead.

How to switch RMM platforms: the parallel run is everything

The single principle that makes a migration safe is boring: two agents on every machine, overlapping, for a defined period. Modern RMM agents coexist without drama. They are lightweight services; the exceptions are rare and show up fast in a pilot.

Deploy the new agent through the old one. Every RMM can run a script or push an installer, so your outgoing platform becomes the deployment mechanism for its own replacement. Write one deployment script per client site, using the new vendor's site-specific installer token so devices land in the right client folder automatically. Push it to a pilot group first: your own internal machines, then one friendly client.

Cut over per client, not per feature

The tempting mistake is to migrate horizontally: move all monitoring first, then all patching, then all scripts. Do not. It leaves every client half in each system for weeks, and nobody can answer the simplest operational question, which tool is authoritative for this machine right now.

Cut over vertically instead. Pick a client, move everything for that client, verify, then remove the old agent from that client and move on. At any moment you can state exactly which clients live where. Sequence them deliberately:

1. Your own estate first. You are your least demanding client and your fastest feedback loop.
2. One small, friendly client second. Somewhere a missed alert costs an apology, not a contract.
3. The awkward ones in the middle. The client with the legacy server, the one with the odd patching exception. Give them the most parallel time.
4. Your largest client last. By then the process is rehearsed and boring, which is what you want it to be.

Tickets and assets: move less than you think

Historical tickets are where migrations go to die. Teams spend weeks building CSV import pipelines to carry five years of closed tickets into the new PSA, then never open them again. Be ruthless:

• Open tickets: migrate manually. On a 200-endpoint book there are rarely more than a few dozen. An afternoon of copy and paste beats a week of import debugging.
• Closed tickets: export to CSV, store the archive somewhere searchable, and leave it there. You need the history to exist, not to live inside the new tool.
• Assets: let the new agent rebuild the inventory. Agent-discovered data is accurate on day one; imported data is stale on day one. Only import what agents cannot discover, such as warranty dates and purchase records.
• Client and contact records: import these properly. They are small, structured and worth getting right, because every ticket hangs off them.

Time the cancellation against your notice period

Read the outgoing contract before you deploy a single agent. Notice periods of 60 or 90 days are common, and some vendors auto-renew for a full year if you miss the window, a trap covered in more detail in our piece on getting out of a multi-year RMM contract. The sequencing matters:

1. Find your renewal date and notice period.
2. Send written notice as early as the contract allows. Notice does not switch anything off; it stops the clock on the next renewal.
3. Count backwards from the termination date and start the migration so the parallel run finishes at least two weeks before the old platform dies.

Yes, you will pay for two platforms for a month or two. Budget for it as a one-off cost and it stops being a reason to stay. On most small-MSP books the overlap costs less than a single quarter of the price increase you were about to accept.

A week-by-week timeline for a 200-endpoint book

Assume a dozen clients, two or three technicians, and the migration run as a background task rather than a full-time project.

Where migrations actually fail

The failure points are predictable, which means they are avoidable:

• Scripts that never get rewritten. The library gets exported in week one and ported never. Then a familiar problem recurs in month two and the fix lives in a dead console. Rewrite the working scripts in week two, while the old tool is still there to check against.
• The laptop in the drawer. Any device offline during the deployment window never gets the new agent. Run a weekly report of machines reporting to the old tool but not the new one, and chase it to zero before cancellation.
• Alert routing left half-configured. The new agent monitors perfectly and tells nobody, because email routing or ticket creation was never finished. Test the full path, alert to ticket to notification, per client.
• The missed notice window. The most expensive failure of all: a flawless migration followed by twelve months of paying for an empty console.

A good migration is not fast. It is boring, verified, and finished before anyone outside the team notices it happened.

Where this fits with Helios

Most of this playbook is sequencing and discipline, and no tool does that for you. What Helios removes is the friction around the edges: agents deploy with a per-client installer command you can push through your outgoing RMM, every feature is on every plan so there is nothing to license mid-migration, and billing is monthly with no contract, so the overlap period costs one flat fee rather than a second annual commitment. Flat pricing at £99, £199 or £399 a month by device band also means the migration maths is arithmetic you can do before the trial starts. We are open about gaps too: there is no network hardware monitoring yet, so if SNMP is on your audit list, plan for it.

Helios is a single RMM and PSA platform with an AI agent that investigates alerts and triages tickets, built by a working MSP. 14-day trial, no card to start, no feature tiers. Start free.

Related: Leaving NinjaOne: how to migrate off it without losing scripts, policies or endpoints, Leaving Syncro: moving RMM, PSA and invoices off the platform in one go, Can you run two RMM agents at once? A safe two-week overlap during a switch

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