Key Takeaways
- Read your contract before you shortlist anything. Kaseya’s published Master Agreement makes mid-term termination trigger a lump sum equal to 100 percent of remaining fees. Notice periods of 30 to 90 days are common, and a missed notice date usually costs a full year.
- Export your data before you give notice, not after. Kaseya’s agreement states that on termination it may permanently delete all related content and will not be liable for doing so. Assume no guaranteed export window anywhere.
- Remove the old agents while the old platform still works. Cancel the tenant first and you have thrown away the tool you were going to use to clean up.
- Parallel running is the right approach and it needs one rule: run the new platform monitoring-only. Two active patch engines on one endpoint means two reboot schedules, and that is where the actual outage risk lives.
- Your scripts mostly move and your automation mostly does not. PowerShell transfers with wrapper edits. Proprietary engines, ConnectWise Automate’s designer, Kaseya Agent Procedures and N-able AMP files, are rebuilt from scratch.
Most Migration Guides Stop at the Hard Part
Search for RMM migration and you will find plenty of advice about deciding to switch. Build the business case, get buy-in from your team, evaluate vendors, weigh the total cost of ownership. All of it is reasonable, and none of it helps on the day you actually have to do this.
The execution guidance across those guides reduces to one sentence: uninstall the old agent, install the new one. That sentence is doing an enormous amount of work. Removing an agent at scale is, depending on your outgoing vendor, either a documented feature or a weekend with a PowerShell script and a registry cleanup. Nobody tells you which one you are walking into.
So this guide assumes the decision is made. If you are still choosing a platform, start with our roundup of the best RMM software. If you are still building the case internally, the short version is that the arguments that land are the ones with numbers attached: the licence delta, the hours per week your team loses to the current platform, and the tickets that never got billed because two systems did not talk. Bring those three and the conversation is usually short.
Everything below is about executing without taking clients offline.
Before You Give Notice: Read the Contract
This is first because it is the only step that can cost you five figures, and it is the step every other guide skips.
Find your notice date and diary it 60 days early
Most RMM contracts auto-renew unless you cancel within a defined window before the term ends. N-able’s published Software Services Agreement requires at least 30 days’ notice before the subscription end date, after which a fixed term renews for another year. Kaseya’s Master Agreement also specifies at least 30 days before term end, and after partner complaints in 2022 the company moved its renewal notice to 90 days.
Diary the date well before the deadline, because the work that has to happen first, exporting data and confirming your replacement, takes longer than the notice window allows if you start at the deadline.
Check whether early termination has a number attached
Kaseya’s Master Agreement is the most explicit published example. Terminating mid-term, absent a material breach by Kaseya, triggers a lump sum payment equal to one hundred percent of the remaining fees, immediately due. That is not a penalty clause in the abstract. On a three-year term signed eighteen months ago it is half the contract value, payable on exit.
Not every vendor publishes terms like this, and it would be wrong to assume Kaseya’s are the industry standard. Most competitors do not make their agreements public in a comparable way. The point is to read your own agreement rather than to assume, and to know the number before you negotiate rather than after.
Export everything before you give notice
Kaseya’s agreement states that upon termination of subscriptions it may permanently delete all related content or disable access to it, and will not be liable for doing so. There is no guaranteed export window written into it.
Treat that as the general case. Before any notice is served, export your asset inventory, client and contact records, agreements and contracts, scripts and automation definitions, monitoring configurations and thresholds, and a full ticket export if the platform allows one. Store it somewhere outside both platforms. You are unlikely to need most of it, and the one thing you do need will be the thing you did not export.
Check what else is on the same term
RMM rarely sits alone. Documentation, password management, remote access, backup and EDR are frequently co-termed with the RMM contract, and replacing the RMM alone can leave you paying for the rest of the bundle for another year. Map your co-termination dates before you plan the sequence, because they often decide it for you.
The Migration, in Five Phases
Phase 1: Audit and cull, one to two weeks
Do not migrate what you are not using. Most MSPs carrying hundreds of scripts and monitoring policies are actively running a fraction of them.
Pull a usage report from the outgoing platform and rank every automation by last run date and run frequency. The ones that ran this month are your real inventory. Everything that has not fired in a year is a candidate for deletion rather than migration, and deleting it is the cheapest work in this entire project.
Do the same for monitoring policies, alert rules and client-specific exceptions. Build one spreadsheet listing what exists, what runs, and what you are actually going to rebuild. That list is your scope, and having it in writing is what stops a four-week migration turning into a four-month one. Our data migration checklist covers the same discipline for the data itself.
Phase 2: Pilot on one client, one to two weeks
Pick a client that is representative rather than easy. You want a mixed operating-system estate, at least one server, and at least one remote worker on a home connection. An all-Windows office of fifteen desktops will not surface the problems.
Deploy the new agent alongside the existing one. Rebuild your core monitoring set and your five most-used automations. Then use the pilot to answer three questions: does agent deployment work through your existing method, do alerts reach the right person, and does the thing your team does forty times a day take fewer clicks than before.
Do not skip this to save a week. Everything you learn here you would otherwise learn across your whole client base simultaneously.
Phase 3: Parallel running, two to four weeks per client group
This is the phase that protects you, and it is also the phase with the one real outage risk in the whole project.
Two RMM agents can coexist on an endpoint. What cannot coexist is two active patch engines. If both platforms are managing patching, you get double patching, competing reboot schedules and a machine that restarts during business hours because two systems each thought they owned the maintenance window. That is the scenario that takes a client offline, and it is entirely avoidable.
The rule: during parallel running, the new platform is monitoring-only. Patching, scripted automation and automated remediation stay disabled in the new platform until the old agent comes off. You are validating that monitoring and alerting work, not running two RMMs.
Three other things break during parallel running and all three are manageable if you expect them.
- Security software flags the other platform. Each RMM’s remote-control component looks like remote-access malware to the other one’s EDR. Whitelist both before you deploy, not after the first alert.
- Alerts duplicate into your PSA. Two platforms watching the same endpoint means two tickets for one event. Either suppress ticket creation from the new platform during parallel or route its alerts to a separate queue.
- You pay twice. Dual licensing during overlap is unavoidable. Budget one to two months of it and put it in the business case up front, because discovering it later makes the whole project look like it overran.
The MSP community maintains monitor sets specifically for detecting conflicting RMM services on an endpoint, which is a reasonable signal that this problem is real enough to be worth planning for.
Phase 4: Agent removal, and the trap nobody writes about
Remove the old agents before you cancel the old tenant. The moment that subscription lapses, you lose the mechanism you were going to use to remove the agents. Every guide tells you to decommission the old platform. None of them tells you the order matters, and getting it wrong means touching every endpoint by hand.
Work down this list, in order, and stop at the first one that works.
- Push the uninstall from the outgoing platform while it still has agent control.
This is the cleanest route and the reason the order above matters. Some vendors make it easy: Datto RMM has a mass-offboarding feature, and Kaseya VSA can do it through Agent Procedures. Use the documented feature rather than scripting around it. If Datto is the platform you are leaving, our guide to Datto alternatives covers where MSPs typically go next.
- Push a removal script from the new platform.
Because the new agent is already deployed from phase three, it can clean up after the old one. This is the standard fallback and the reason parallel running is worth the licence overlap.
- Use your existing deployment infrastructure.
Group policy, Intune or a deployment tool will run an uninstaller across a fleet without either RMM being involved.
- Manual removal, last resort only.
Practitioners who do this professionally treat manual removal as unjustifiable above about five machines. If you are contemplating it at scale, one of the three routes above has not been exhausted.
Vendor-specific notes worth having before you start. ConnectWise Automate, formerly LabTech, is the documented worst case: its official offboarding script fails if the agent has not first been marked as offline, it does not remove third-party software the RMM deployed, so antivirus and backup agents orphan themselves, and it does not delete the corresponding remote-control sessions, leaving ghost entries behind. The services and paths to check afterwards are LTService, LTSvcMon and the LTSvc folder in your Windows directory. A community-maintained removal tool exists on GitHub purely to clean up what the official uninstaller leaves, which tells you most of what you need to know.
N-able documents agent removal as a per-device operation with no bulk uninstall from the dashboard, though it publishes a community PowerShell uninstaller in its own GitHub repository. Removed devices do not disappear from the console, they move to a stale state and need clearing separately. Probes need their own pass. If N-able is the platform you are leaving, see our breakdown of N-able alternatives.
Whatever the vendor, verify removal rather than assuming it. Run a report from the new platform for any endpoint still showing the old agent’s services, and expect a tail of five to ten percent that needs individual attention.
Phase 5: Decommission, one week
Confirm zero active agents, confirm your exports are complete and readable outside the platform, then cancel. In that order.
Keep the old PSA or ticketing system in read-only mode for a retention window rather than trying to migrate closed tickets. Twelve months is a common choice. Budget the read-only licence as a real line item, because it is the cost MSPs most often forget and it turns up on a renewal invoice they thought they had cancelled.
What Does Not Come With You
Scripts move. Automation does not.
PowerShell transfers between platforms with light editing. What breaks is not the logic, it is the scripting wrapper: variable syntax, script parameters and inputs, exit-code handling, output capture, credential injection, and the platform-specific tokens each RMM uses to pass in device details. Budget an hour per script for rework and testing rather than assuming a copy and paste.
Proprietary automation engines do not move at all. ConnectWise Automate’s drag-and-drop script designer, Kaseya VSA’s Agent Procedures, which are XML-native even when they call PowerShell, and N-able’s AMP policy files are all rebuild-from-scratch. If your automation lives in one of those, you are not migrating it, you are reimplementing the forty things you actually use and letting the rest go.
Monitoring thresholds move. Tuning history does not.
Re-entering thresholds is quick. What you lose is everything layered on top of them over years: the per-client exceptions, the suppressions, the alert-to-ticket mapping, the escalation chains, and the accumulated knowledge that one particular server always spikes at three in the morning and it is fine.
You also lose historical baselines, which means any anomaly-based alerting is blind until the new platform has built its own history. Expect an alert storm in week one from default thresholds, plan for someone to own tuning during that week, and resist the urge to read it as a defect in the new platform.
Ticket history, realistically, does not move
Open tickets get recreated by hand, which is manageable because there are rarely many. Assets, contacts and agreements usually move by CSV. Closed ticket history generally stays where it is, behind a read-only licence, because the effort of migrating it exceeds how often anyone looks at it.
How Long This Actually Takes
There is no published dataset segmenting RMM migration timelines by MSP size, and any table claiming otherwise is estimating. So rather than invent one, here is the model built from the components above, each of which is verifiable on its own.
| Phase | Duration | What drives it |
|---|---|---|
| Contract notice | 30 to 90 days | Your agreement. This runs in parallel with everything else. |
| Audit and cull | 1 to 2 weeks | How much automation you have accumulated |
| Pilot | 1 to 2 weeks | One representative client, start to finish |
| Parallel run | 2 to 4 weeks per group | Confidence, not technology |
| Agent removal | 1 to 2 weeks | Which vendor you are leaving |
| Decommission | 1 week | Verification and exports |
For most mid-sized MSPs that lands somewhere between six and twelve weeks from first pilot to final decommission, with client groups overlapping rather than running end to end. The contract notice period usually sets the real deadline, which is why it is step one rather than step ten.
The one published figure in this space puts a general migration at two to eight weeks, which is consistent with the shorter end of this range for a smaller MSP with less automation to rebuild.
Migrating to Syncro
Syncro’s RMM software for MSPs deploys agents by script, group policy or direct installer, so a migration can be staged client by client rather than committed to a single cutover date. Because it is priced per technician with unlimited endpoints, running it alongside your existing platform during the parallel phase does not scale with the number of endpoints you are double-covering.
If you want the migration plan for your specific outgoing platform, that is a conversation worth having before you serve notice, not after.
Frequently Asked Questions About RMM Migration
Six to twelve weeks for a typical mid-sized MSP from pilot to decommission, with client groups running in parallel rather than sequentially. The contract notice period, commonly 30 to 90 days, usually sets the actual deadline. The work that takes longest is rebuilding automation, not deploying agents.
Yes, and you should for two to four weeks per client group. One rule makes it safe: the new platform runs monitoring-only, with patching and automated remediation disabled until the old agent is removed. Two active patch engines on one endpoint cause competing reboot schedules, which is the main way a migration takes clients offline.
In this order: push the uninstall from the outgoing platform while it still has agent control, then from the new platform if that fails, then through group policy or your deployment tooling, and only then manually. Some vendors have a documented bulk offboarding feature, so check before scripting. Whatever you do, remove the agents before you cancel the old subscription.
You lose remote access to the very tool you needed for the cleanup, and removal becomes a manual, per-device job or a script pushed from whatever else you have on the endpoint. This is the most common avoidable mistake in an RMM migration. Removal comes before cancellation, always.
PowerShell scripts transfer with wrapper changes: variable syntax, parameters, exit codes, output capture and credential handling all differ between platforms. Anything built in a proprietary engine, including ConnectWise Automate’s script designer, Kaseya Agent Procedures and N-able AMP files, has to be rebuilt. Budget rebuild time for those rather than migration time.
They should not, if you run the parallel phase properly and keep the new platform monitoring-only until cutover. What clients actually notice is a reboot at the wrong time from two patch engines disagreeing, and an unfamiliar remote-access prompt. Tell them the remote-support tool is changing before the first technician uses it.
Usually not. Most MSPs recreate open tickets by hand, move assets, contacts and agreements by CSV, and keep the old system in read-only mode for around twelve months instead of migrating closed tickets. Budget the read-only licence, because it is the cost most often forgotten.
Four things: the notice period and the exact subscription end date, whether early termination carries a fee and how it is calculated, what rights you have to export your data and for how long, and what else is co-termed with the RMM. Export everything before you serve notice rather than after.
Share
Related Resources
