Leaving NinjaOne: how to migrate off it without losing scripts, policies or endpoints

Getting into NinjaOne takes an afternoon. Getting out takes a plan, because the platform exports far less than most people assume, and the things that do not export are precisely the things you spent years building: patch policies, compound monitoring conditions, native automations. This guide covers the NinjaOne migration specifically: what you can pull out, what you must rebuild, how the common destinations handle each artefact, and a realistic timeline for a 500-endpoint estate. If you are still deciding where to go, start with our NinjaOne alternatives comparison and come back here once you have picked.

Check your contract before you touch anything

NinjaOne contracts are typically annual, with auto-renewal and a notice period, often 30 to 60 days before the renewal date. Find your renewal date and your notice window first, because the worst position in any RMM migration is finishing the technical work three weeks after your contract silently renewed for another year. Give notice in writing as soon as you are committed, even if the migration will not start for months. Notice does not cancel your access, it just stops the renewal.

What NinjaOne lets you export, and what it does not

Divide your NinjaOne estate into five artefacts. Each travels differently.

• Asset and device data. Exportable. Reports and device lists come out as CSV: hostnames, serials, OS versions, installed software, last user. This is the easy part, and also the least valuable, because most destinations rediscover this the moment their agent lands.
• Documentation. Partially exportable. NinjaOne Documentation records can be exported, but custom field structures and relationships between records need rebuilding by hand in the destination. Budget real hours here if documentation is where your passwords and runbooks live.
• Script library. Copy-paste, not export. There is no bulk script export, but every PowerShell, Bash or batch script can be opened and copied. Do this early and store them in a Git repository, not a folder called scripts-final-v2.
• Patch policies. Not exportable. Screenshot every policy: approval rules, schedules, reboot behaviour, exclusions. You will rebuild these from the screenshots, and the screenshots are the only record you will have once access ends.
• Monitoring conditions. Not exportable. Simple thresholds are quick to recreate. Compound conditions and condition-triggered automations are NinjaOne-native logic and do not travel anywhere. Document the intent of each one, not just the settings, because the destination will express the same intent differently.

Script portability: PowerShell travels, automation does not

Here is the distinction that decides how painful your migration is. A script that is plain PowerShell, taking parameters and writing to standard output, runs anywhere: Atera, Syncro, SuperOps, Level, Datto RMM, all of them execute PowerShell as LocalSystem in much the same way. A script that leans on NinjaOne-specific plumbing does not. Custom field reads and writes, Ninja-Property-Set calls, NinjaOne environment variables, and anything built in the visual automation editor rather than as code: all of that is rebuild work, not copy work.

The re-run test: paste each script into a plain PowerShell session on a test machine. If it runs, it migrates. If it errors on a Ninja cmdlet or an environment variable, it goes on the rebuild list. Doing this test in week one turns an unknown into a number.

How the five common destinations handle each artefact

• Atera. Agent deployment is straightforward and asset data repopulates on discovery. Scripts paste in cleanly. Patch policies are simpler than NinjaOne's, which means faster rebuilding but less granularity, so check your exclusion rules survive the translation.
• Syncro. Offers CSV asset import for the PSA side, which matters if you are moving customer records too. Scripts paste in, with Syncro's own variable syntax replacing Ninja's custom field calls. Monitoring is threshold-based and lighter than NinjaOne's compound conditions.
• SuperOps. Provides migration assistance for larger estates, worth asking for at 500 endpoints. Policy rebuilding is manual but the policy model maps reasonably closely to NinjaOne's, which shortens the translation.
• Level. Script-first by design, so a Git repository of clean PowerShell is nearly the whole migration. The trade is that you rebuild monitoring as automations rather than importing conditions, which suits teams who prefer code to configuration screens.
• Datto RMM. The most policy-rich destination, so nothing is lost in translation, but nothing imports either: every policy is rebuilt in Datto's own component and policy model. Read our note on multi-year Kaseya contracts before signing, because the exit you are executing now is one you may repeat.

A realistic timeline for 500 endpoints

Eight weeks is honest for a 500-endpoint estate with one or two technicians driving it part-time. Faster is possible; faster with the same people also running the service desk usually is not.

• Weeks 1 to 2: extract and document. Export asset CSVs, copy every script to Git, screenshot patch policies and monitoring conditions, run the re-run test. Give contractual notice.
• Week 3: pilot. Deploy the new agent to 20 to 30 machines, ideally your own, alongside the NinjaOne agent. Rebuild core policies against the pilot group and let them run.
• Weeks 4 to 6: wave deployment. Push the new agent site by site, using NinjaOne itself to deploy it: a script that installs the successor is the old platform's most useful final act.
• Weeks 6 to 8: parallel run. Both agents report, the new platform is primary, NinjaOne is the safety net. Compare alert behaviour and patch results before you trust the new estate.
• Week 8 onwards: decommission. Remove the NinjaOne agent at scale, from the new platform, with an uninstall script per wave. Verify removal against your asset export, then close the account.

What the parallel month actually costs

Suppose NinjaOne costs you £2.50 per endpoint per month, £1,250 for 500 endpoints, and the destination costs £2 per endpoint, £1,000. One parallel month costs £2,250. That is £1,000 more than your normal bill, recovered in four months of the £250 monthly saving. If the numbers frighten you, run them the other way: staying on tooling you have already decided to leave costs the difference every month forever. The parallel month is the cheapest insurance in the whole project. This works whether the machines belong to clients or to your own company; the arithmetic does not care who owns the laptops.

The pre-migration checklist

Print this, or paste it into a ticket, and do not deploy a single new agent until every item is done.

1. Confirm renewal date and notice period. Skip this and the contract renews mid-migration.
2. Export all asset and software CSVs. Skip this and you cannot verify agent removal later.
3. Copy every script to version control. Skip this and your library dies with your login.
4. Run the re-run test on each script. Skip this and rebuild work surfaces in week six instead of week one.
5. Screenshot every patch policy and monitoring condition, with a note on intent. Skip this and you rebuild from memory.
6. Export documentation and map custom fields to the destination. Skip this and runbooks vanish quietly.
7. List integrations: backup, AV, PSA, accounting sync. Skip this and something downstream breaks silently.
8. Write the pilot success criteria before the pilot. Skip this and the pilot proves whatever you want it to.

Where this fits with Helios

Most of this guide is discipline, not tooling: the exports, the screenshots, the notice letter are yours to do whatever you move to. Helios makes the destination side lighter. Plain PowerShell pastes straight into the script library, the agent covers Windows, macOS and Linux, and because monitoring, patching, helpdesk and remote access are one platform, you rebuild policies once rather than once per tool. Pricing is flat per plan with unlimited technicians, so the parallel month is a known number, not a quote.

Helios is an AI-native RMM and PSA built by an MSP that runs on it. Every feature on every plan, 14-day trial, no credit card and no feature gating. Start free.

Related: Leaving Datto RMM: how to migrate agents, ComStore scripts and policies without losing an endpoint