Leaving SuperOps: migrating RMM, PSA and client data to another platform

Four workstreams decide whether a SuperOps migration goes cleanly: swapping the agent on every device, rebuilding scripts and policies by hand, exporting tickets and contracts, and keeping billing running so no client gets a missed or doubled invoice. For a small MSP the work usually fits into a few weeks, provided you run the two platforms side by side rather than cutting over in a weekend. Here is the order we would do it in, and why.

Why the order matters more than the tooling

The received wisdom is that migration is a data problem: get everything exported and the rest follows. We think that is backwards. Data you can export at leisure. Coverage you cannot, because the moment a device has neither agent nor monitoring, nobody is watching it, and nobody knows nobody is watching it.

So the shape is simple: protect coverage first, then rebuild behaviour, then move history, and touch billing last and most carefully. It applies whether the machines belong to clients or to your own organisation.

Step 1: inventory before you touch anything

Export a full device list from SuperOps before you change a single endpoint: hostname, client, site, OS, last check-in and any custom fields you rely on. This list is your reconciliation baseline for the whole project.

• Flag the stale devices. Anything that has not checked in for weeks is either retired or broken. Decide which now, or you will spend the cutover chasing ghosts.
• Note the awkward ones. Servers with change windows, laptops that are rarely online, machines behind restrictive firewalls. These need a plan of their own.
• Record contract dates. Know your SuperOps renewal or notice date before you plan the timeline, not after.

Step 2: the agent swap, with an overlap

Deploy the new agent alongside the SuperOps agent rather than replacing it in one move. Most modern agents coexist happily for a short period, and we have written separately about running two RMM agents at once during a safe two-week overlap. The overlap is what lets you verify coverage without ever leaving a device unwatched.

The neat trick is to use SuperOps itself to push the new agent: a deployment script run from the old platform reaches every online device you already manage. Stragglers get a manual install or a group policy deployment.

Only once a device is confirmed reporting in the new platform, with monitoring and patching active, do you uninstall the SuperOps agent. Skip this and you get the classic failure: an uninstall that ran before the new agent ever checked in, leaving a machine nobody manages.

Step 3: rebuild scripts and policies, do not port them

Scripts and policies rarely transfer between RMMs in any automatic way. Variables, run contexts, alert conditions and scheduling all differ between platforms, so plan to rebuild rather than import.

That is less painful than it sounds, because estates accumulate scripts the way lofts accumulate boxes. A migration is the one time you are forced to open each box.

1. Export every script as plain text first. Copy out PowerShell, Bash and batch content before you cancel, because access usually ends when the subscription does. The same discipline applies on other platforms, as in our guide to exporting RMM scripts before you cancel.
2. Sort into keep, rewrite and bin. If a script has not run in months and nobody can say what it does, it goes in the bin.
3. Rebuild policies from intent, not settings. Write down what each policy is meant to achieve (patch approval rules, disk space thresholds, service checks) and recreate that intent natively in the new tool.
4. Test on your own machines first. Then one friendly client, then everyone.

Step 4: exporting tickets, contracts and client data

The PSA half of a SuperOps migration is where people overreach. Not every ticket needs to live in the new system.

Tickets: migrate open work, archive the history

Open and recently closed tickets should move, because technicians need them. Years of closed history is a different matter. A full import with mapped statuses, technicians and time entries is possible, often through a paid migration service, but it is expensive and fiddly. A read-only archive (CSV or PDF exports per client, stored where you can search them) covers most of the genuine need: answering "did we fix this before?"

Contracts and client records

Export clients, sites, contacts and contracts separately, and check the contract terms by eye. Recurring line items, included hours and per-device charges are where small mapping errors become real money. Documentation and credentials deserve their own careful export, kept encrypted and deleted from temporary locations afterwards.

A ticket history nobody searches is not an asset. It is a storage bill wearing a compliance costume.

Step 5: billing continuity, the part that actually hurts

Clients forgive a new portal. They do not forgive a wrong invoice. Billing is where migrations quietly fail, so it moves last.

• Pick a clean cut-off date. Ideally the start of a billing month. Everything before it invoices from SuperOps, everything after from the new platform.
• Run one parallel cycle. Generate the month's invoices in both systems and compare totals per client before anything is sent. Any difference is a mapping error.
• Reconnect accounting carefully. If you sync to Xero or QuickBooks, disconnect the old integration before connecting the new one, or you risk duplicate invoices and contacts. Our piece on MSP billing software that syncs to Xero and QuickBooks covers what to check.
• Close off unbilled time. Bill or write off all outstanding time entries in SuperOps before the cut-off.

How SuperOps migrations usually go wrong

The failure modes are predictable, which is the good news:

• Big-bang cutover: fast, and blind for a weekend. Devices fall through gaps nobody sees.
• Script hoarding: every old script ported, including the broken ones, so the new platform inherits the old mess.
• Full history import: weeks and money spent moving tickets no one reads.
• Billing switched mid-month: partial periods, missed recurring charges and an awkward call from a client's finance team.

Where this fits with Helios

Most of this plan is discipline, not tooling, and it works whichever platform you move to. Helios covers both halves of what SuperOps did in one product: RMM with monitoring and patching, plus a helpdesk with SLA clocks, contracts, time tracking and billing into Xero or QuickBooks. Its built-in AI technician, Helio, can investigate alerts and apply fixes within plain-English rules you set, which helps once rebuilt policies are live. Pricing is by fleet size with every feature on every plan, and you can check the current figures on the pricing page. There are 14 days free with no card needed, which is long enough to run the overlap on a pilot client.

Common questions about SuperOps migration

How long does a SuperOps migration take?

A SuperOps migration for a small MSP typically takes a few weeks rather than days. Allow time for inventory, a two-week agent overlap, script and policy rebuilding, and at least one parallel billing cycle. Larger estates, or those with many custom scripts, take longer because the rebuild work scales with how much automation has accumulated.

Can I import SuperOps scripts directly into another RMM?

SuperOps scripts generally cannot be imported directly into another RMM, because each platform handles variables, run contexts and scheduling differently. The script content itself, such as PowerShell, can usually be copied across and adapted. Export everything as plain text before cancelling, then rebuild and test each script in the new platform.

Do I need to migrate all my closed SuperOps tickets?

Closed SuperOps tickets rarely all need migrating. Open and recent tickets should move so technicians can keep working, while older history can sit in a searchable read-only archive exported per client. A full historical import is possible through migration services, but the cost is often hard to justify for tickets nobody consults.

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