Datto RMM migration plan: from contract notice to the last agent removed

Moving off Datto RMM rarely fails in the middle. It fails at the edges. A sound Datto RMM migration plan has five stages: confirm your contract dates and serve notice in writing, export what you need to keep, tell clients before their machines change, roll the new agent out one client at a time with a short overlap, then decommission Datto agents, policies and integrations deliberately. Most of the risk sits in the first and last stages. Here is the plan, stage by stage.

Why a Datto RMM migration plan starts with the contract, not the agents

The technical work is the part everyone plans for. The contract is the part that bites, because a missed notice date can commit you to another full term of a tool you have already stopped using.

Before you install anything new, find the signed agreement and answer three questions:

• When does the current term end? Not the date you think it renews. The date written in the order form or master agreement.
• How much written notice does it require? Notice windows on RMM and PSA contracts are commonly measured in tens of days before renewal, and some vendors require it through a specific channel. Check yours rather than assuming.
• Is Datto RMM bundled with anything else? If it sits inside a wider Kaseya agreement with Autotask, backup or security products, cancelling one line may not be straightforward, and the bundle may have its own minimums.

Serve notice in writing as soon as you are sure, and ask for written acknowledgement. Notice does not usually switch the tool off early, so you keep working access until the term ends. That is your migration window. Plan the rest backwards from it.

Export before you need it

Your Datto data is easiest to reach while you still have a full licence and a technician who remembers why each component exists. Leave it to the final week and you will be exporting under pressure, which is when things are forgotten.

At minimum, capture components and scripts, monitoring policies and their thresholds, device lists by site, custom fields, and any audit or software inventory you rely on for client reporting. The detail of getting scripts out is covered in our guide to exporting RMM scripts from Datto before you cancel. If you also run Autotask, plan that side separately, because tickets, contracts and time entries carry billing consequences; our Autotask migration guide walks through keeping a billing cycle intact.

Treat the export as a review, not a copy. Policies accumulate the way garden sheds accumulate broken chairs. Anything nobody can explain should not survive the move.

Tell clients early, and tell them precisely

Clients do not care which RMM you use. They care whether anything will change on their machines, whether their data is being handled by someone new, and whether they need to do anything. Answer those three things and you have answered almost every question they will raise.

A good client notice is short and covers:

• What is changing: a new management agent replaces the old one on their devices. Name the window.
• What they will notice: ideally nothing, but say if a reboot, a new tray icon or a brief remote session prompt may appear.
• Data and security: where monitoring data will be held, and that you will update any data processing terms if your contract with them requires it.
• Who to contact: one named person for the duration.

For internal IT teams the audience is your own staff and management, but the logic is the same. Skip this and the first unfamiliar prompt on a finance director's laptop becomes a security incident ticket.

Phase the rollout by client, not by device count

The tempting plan is to push the new agent everywhere in one evening. It is fast. It is also the plan where one bad policy hits every estate at once.

Roll out in waves instead, whether the machines belong to clients or to your own company:

1. Your own estate first. Your devices, your mistakes, no client affected.
2. A small, friendly client. Simple environment, forgiving contact, good for proving patching and alerting.
3. The awkward ones. Servers, line-of-business applications, unusual network rules. Do these with full attention, not at the end of a long week.
4. Everyone else in batches. Group by similarity so one set of policies can be validated once.

For each wave, define what "done" means before you start: every device reporting, monitoring alerts firing on a test condition, a patch cycle completed, remote access working. A wave is not finished because the installer ran.

Overlap briefly, then cut

Running both agents for a short period lets you compare inventories and catch devices that never checked in to the new platform. It is safe if you avoid two tools fighting over the same job, chiefly patching and reboots. Disable Datto patch policies on a site before the new platform starts patching it. We cover the mechanics in running two RMM agents during a switch.

An overlap is a check, not a holiday. If it has no end date, it is a second RMM bill.

Decommissioning: the stage everyone skips

A migration is finished when nothing of Datto remains that could act on a device or hold client data. That is a longer list than uninstalling the agent:

• Agents: uninstall from every device and reconcile against your exported device list. Offline laptops are the usual stragglers, so chase them by name.
• Integrations: remove API keys and connections to Autotask, Microsoft 365, backup and documentation tools.
• Accounts: disable technician logins and any service accounts the agent used.
• Network rules: retire firewall allowances that existed only for Datto.
• Data: confirm in writing what the vendor retains after termination and for how long.

The residue test: a month after cut-over, search your estate for the old agent service and your firewall logs for old endpoints. Anything that answers is unfinished work.

How Datto RMM migrations usually go wrong

Where this fits with Helios

Most of this plan is discipline, not tooling: no platform will serve your notice or chase an offline laptop for you. Where Helios helps is on the receiving end. It combines RMM and PSA in one product, including patching, Microsoft 365 and Defender monitoring, backup monitoring, a helpdesk and billing into Xero or QuickBooks, so a Datto and Autotask exit can land in one place. Every feature is on every plan with no charge per technician, and you can see the details on the Helios pricing page.

Common questions about a Datto RMM migration

How long does a Datto RMM migration take?

A Datto RMM migration usually takes as long as your waves and overlap need, and it is driven more by client count and complexity than by device count. A small MSP with simple estates can often move in a few weeks once exports are done; plan backwards from your contract renewal date and leave slack for the awkward clients.

Do I need to uninstall the Datto agent before installing a new RMM?

No, the Datto RMM agent can usually stay in place during a short overlap with a new RMM agent, which helps you reconcile device lists. The important step is disabling Datto patching and reboot policies on each site before the new platform takes those jobs over, so the two tools never act on the same device.

Should I tell clients I am changing RMM?

Yes, telling clients about an RMM change is good practice, and some client contracts or data processing terms may require it. Keep the notice short: what is changing, when, what users might notice, how their monitoring data is handled and who to contact. Clients rarely object to a change they were told about in advance.

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