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

Choosing where to go after Datto RMM is the easy half of the job. The hard half is the part nobody writes up: getting several hundred agents, a folder of ComStore components, years of accumulated UDFs and a monitoring policy tree out of one platform and into another without a single machine going dark. That gap is why so many MSPs who are certain about leaving Datto RMM are still paying for it eighteen months later. Migration fear is the real renewal mechanism.

It should not be. Done in the right order, a migration off Datto is a series of boring, checkable steps, not a leap. Here is the working plan, step by step, with realistic timings per 100 endpoints and the gotchas that catch people out.

Step one: export everything Datto knows before you touch anything

Start with a full inventory export while your access is still unrestricted. From the Devices view, export to CSV with every column enabled: hostname, site, last user, OS, agent version, IP, and critically every user-defined field. Datto's UDFs tend to accumulate operational knowledge over the years: BitLocker keys, warranty dates, backup job names, flags that scripts key off. If it lives only in a UDF, it lives only in Datto until you export it.

Then document the site structure itself: site names, site variables, site-level credentials and any site-specific settings such as local cache nodes. The Datto API can pull most of this if you prefer JSON to screenshots, and for anything over 500 endpoints it is worth the hour to script it.

Skip this and you will discover, three weeks after your Datto access ends, that the only record of a client's server room door code was UDF 7.

Step two: map ComStore components to their destination equivalents

This is the step people overestimate. Open your component library and be honest about what is actually in use. Most estates run ten to twenty components regularly and carry a hundred more as sediment. Check the last-run date on each: anything untouched in twelve months does not need migrating, it needs deleting.

For the live ones, sort them into three piles:

• Plain PowerShell or batch. These move almost unchanged. Every serious destination platform runs arbitrary PowerShell, so a script that queries WMI and writes to a log needs nothing more than a paste.
• Components that use Datto input variables. Datto passes component variables into scripts as environment variables. Any script reading $env:SomeVariable set by the component, or referencing site variables or UDFs, needs those references rewritten to the destination's parameter and custom-field syntax. Budget fifteen to thirty minutes per script.
• ComStore black boxes. Closed components you deployed but cannot read are the one genuine loss. You cannot port what you cannot see, so find the equivalent in the destination's script library or rebuild the behaviour from its description. There are usually only two or three of these that matter.

Step three: rebuild monitoring policies and patch rings, but smaller

Do not recreate your Datto policy tree one for one. Policy trees grow by accretion: a monitor added for one noisy server in 2021 is still firing on forty machines today. A migration is the one moment you get to rebuild from intent rather than history.

Write down what you actually want to know about a workstation and a server: disk, critical services, backup job status, event log patterns that have ever preceded a real ticket. Build that, and only that, in the destination. The same applies to patch policies: most estates need two or three rings, pilot, general and cautious, not the nine overlapping schedules that Datto has accumulated. If your rings have drifted from your intentions, our piece on how fast you should actually patch is worth reading before you rebuild them.

Step four: run both agents side by side

Deploy the new agent while the Datto agent is still running. This is the single decision that makes the migration safe, because at no point is any machine unmonitored. Datto itself is a convenient deployment mechanism: a component that silently installs the new agent will cover 95 per cent of the fleet in a day, with the stragglers picked up by GPO, Intune or a technician.

Two agents coexist happily with three caveats:

• Duplicate alerts. Both platforms will page you about the same full disk. Mute the destination's alerting, or route it to a separate channel, until cutover. Otherwise your technicians learn to ignore the new platform in week one, which is the worst possible training.
• Patch policy conflicts. Two patch engines with different schedules will fight over reboot windows. Leave patching disabled in the destination until the Datto patch policy for that site is switched off.
• Remote access tools. Datto bundles Splashtop, and some destinations do too. Two Splashtop streamers on one machine occasionally sulk. Test on the pilot site before assuming.

Step five: the per-site cutover checklist

Cut over site by site, smallest and friendliest first, never the whole estate at once. Per site: confirm every device in the Datto export appears in the destination, enable alerting and patching in the destination, disable them in Datto, run for 48 hours, then push the Datto agent uninstall as your final component. Reconcile the counts at the end: the number removed from Datto must equal the number live in the new platform. Any gap is a machine that was offline during deployment, and it is a named machine on a list, not a mystery. The general version of this discipline is covered in how to switch RMM platforms without dropping an endpoint.

Realistic timings per 100 endpoints

For a typical small MSP doing this alongside the day job: exports and documentation, half a day. Script triage and porting, one to three days depending on how many components read Datto variables. Policy and patch rebuild, one day. Side-by-side deployment, one day of pushing plus a week of stragglers. Cutover and reconciliation, half a day per site. Call it two to three weeks of elapsed time per 100 endpoints, of which perhaps five days is actual work. Larger estates do not scale linearly: the scripts and policies are fixed costs, so the second hundred endpoints cost far less than the first.

Mapping Datto features to the alternatives

The names differ; the shapes are the same. Nothing in Datto RMM lacks a workable equivalent elsewhere, which is worth remembering when the migration feels large.

Choosing the destination

This guide deliberately does not tell you where to go. If you have not settled that yet, we have compared the main Datto RMM alternatives head to head, and if a multi-year Kaseya agreement is the thing actually holding you in place, the contract exit piece covers timing your migration against the renewal window. Pick the destination first, run its trial against this plan, then execute.

Where this fits with Helios

Most of this guide is discipline, not tooling: exports, triage, reconciliation. Where Helios helps is on the receiving end. Scripts port in as playbooks that Helio, the built-in AI agent, can run and extend, monitoring policies come with investigation rather than raw alerts, and because monitoring, patching, remote access and the service desk are one product, you are consolidating rather than rebuilding tool by tool. Flat monthly pricing also means the migration itself costs nothing extra: no per-endpoint meter running while both platforms overlap.

Helios is an AI-native RMM and PSA in one platform, with every feature on every plan. 14-day trial, no feature gating, no card required. Start free.