How to export RMM scripts from NinjaOne, Atera and Datto before you cancel

Exporting RMM scripts before you cancel takes three steps on any platform: pull each script's source code out of NinjaOne, Atera or Datto RMM, record the variables, schedules and conditions that live outside the code, then file everything by the job it does in a folder you control. The code is the easy part. The context around it is what usually goes missing. Here is how to capture both, platform by platform.

Why scripts are the part people fear losing

Migration cost is the main reason MSPs and internal IT teams stay on a platform they have outgrown, and scripts are where that cost feels largest. Agents can be redeployed and tickets can be archived. Scripts hold years of small decisions: the registry key that fixes one client's line-of-business app, the cleanup routine someone tuned after a disk filled up.

The fear is reasonable but usually overstated. Most RMM scripts are plain PowerShell, Batch, Bash or Python. They run on the endpoint, not inside the vendor's product. What is platform-specific is the wrapper: how variables are passed in, how output is reported back, and when the script is triggered. Capture the wrapper and the script is portable.

Before you export: what to capture for every script

Whichever platform you are leaving, record the same fields for each script. A spreadsheet or a simple README per script is enough.

• Source code. The full script, saved with the right file extension so editors and version control treat it correctly.
• Inputs and variables. Every parameter, custom field or platform variable the script reads. Skip this and the script will run on the new platform with empty values, which is worse than failing loudly.
• Run context. Whether it runs as SYSTEM/LocalSystem or as the logged-in user, and on which operating systems.
• Trigger. Scheduled, run from a policy or condition, run on demand by a technician, or attached to an alert.
• Expected output. Exit codes, what counts as success, and any custom fields the script writes back to.
• Owner and last use. Who wrote it and whether it has actually run recently.

Exporting scripts from NinjaOne

NinjaOne keeps scripts in its automation library, under the administration area. Each script's editor shows the code, the language, the operating system and the script variables. Copy the code out into a file, then note the variables and their types separately, because those are defined in the NinjaOne interface rather than in the script body.

Then check where each script is used. Policies, scheduled tasks and condition-based automations reference scripts, and those references do not travel with the code. NinjaOne also offers a public API, which is worth exploring if your library is large, but confirm against NinjaOne's current documentation what script data it exposes before you plan around it. Our guide to leaving NinjaOne covers policies and agent removal alongside this.

Exporting scripts from Atera

Atera holds your scripts in its scripts area, alongside the shared script library contributed by its community. Separate the two first: only your own and edited scripts need exporting, since shared library entries can be found again. Open each of your scripts, copy or download the content, and record the file type and any parameters you pass when running it.

Atera runs scripts through automation profiles, IT automation schedules and threshold-triggered actions. List which profiles call which scripts before you cancel, because once the account is closed that mapping is gone. The wider move, including agents and tickets, is covered in our Atera migration guide.

Exporting scripts from Datto RMM

Datto RMM wraps scripts in components. A component bundles the script with its input variables, its category and any attached files, and Datto's component library lets you export components as files that can be imported elsewhere in Datto. That export is useful as a backup but is not portable to other platforms in that form, so also copy the raw script out of each component.

Pay attention to two Datto habits. Components read input variables as environment variables, so a script may reference values that only make sense inside Datto. And many components come from the ComStore rather than your own team. Mark those as vendor-supplied, since you will be looking for an equivalent rather than porting them. Our Datto RMM migration guide covers monitoring policies and jobs as well.

Catalogue scripts by the job they do, not the platform they came from

A pile of exported files is not a library. Most estates accumulate scripts the way lofts accumulate boxes: plenty of them, poorly labelled, with three versions of the same thing. Sort by job instead, using folders such as:

1. Diagnostics. Scripts that gather information without changing anything: disk usage, event log pulls, installed software.
2. Remediation. Scripts that fix a known problem: clearing print queues, restarting stuck services, repairing Windows Update components.
3. Maintenance. Scheduled housekeeping: temp file cleanup, log rotation, reboots.
4. Deployment. Installing and configuring software, including any package manager wrappers.
5. Security and compliance. BitLocker status, local admin audits, firewall checks.
6. Client-specific. Anything written for one organisation's peculiar setup, filed under that client or department.

The duplicate test: if two scripts sit in the same folder and do the same job, keep the one that ran most recently and archive the other. This is where most of the clean-up happens, and it shrinks the migration.

Make the library portable

Put the catalogued scripts in a Git repository, whether that is a private GitHub, GitLab or Azure DevOps repo. Version control gives you history, review and a single source of truth that no RMM vendor owns.

• Strip platform variables. Replace vendor-specific references with standard script parameters, so the script declares what it needs at the top.
• Standardise exit codes. Zero for success, non-zero for failure, documented in the README.
• Remove secrets. Exported scripts often contain hard-coded credentials or API keys. Move them to a secrets store and rotate anything that was ever in plain text.
• Test on a lab machine. Run each remediation script outside any RMM once, as SYSTEM, to confirm it works without the old wrapper.

A script library you own outlasts every platform you rent.

Failure modes worth avoiding

Exporting the code but not the triggers means scripts quietly stop running and nobody notices until something breaks. Exporting everything without cataloguing means porting dead scripts at full cost. Cancelling before the export is verified means discovering gaps when there is no longer an account to check. Run the old and new agents side by side for a short period, as described in our piece on running two RMM agents at once, and only cancel once each critical script has run successfully on the new platform.

Where this fits with Helios

Most of this process is discipline, not tooling, and the portable library is worth building whatever you move to. Where Helios helps is the rebuild: Helio, the AI agent built into the platform, can take a script from your library and rebuild it as a playbook, then grow that playbook library as it investigates and fixes issues across the machines you manage, whether they belong to clients or to your own company. You still need to review what it produces before it runs at scale. If you want to see how the platform compares with what you are leaving, the comparison pages set it out, and every feature is on every plan, from £20 a month, with 14 days free and no card required.

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