Migrating to Breeze

Migrating an RMM is not a data migration. It is a re-deployment of your management plane across every endpoint you manage, done without losing visibility on any of them. The endpoint data your incumbent holds — inventory, performance history, patch state — is regenerated by Breeze within hours of an agent enrolling. What actually has to move is your configuration: the customer tree, the scripts, the alert thresholds, the patch policies, and the muscle memory of your technicians.

This page is the vendor-neutral playbook. The per-vendor pages layer the specifics on top.

Datto RMM

NinjaOne

ConnectWise Automate

Kaseya VSA

N-able N-central

Atera

Syncro

Other RMMs

---

The Core Insight

Your old RMM is the best deployment tool you will ever have for the new one

Your incumbent RMM already has a SYSTEM-level, remotely-triggerable script engine on 100% of the endpoints you need to reach. Nothing else you own — not GPO, not Intune, not a technician with a USB stick — has that coverage. Use it to install the Breeze agent. Every per-vendor guide in this section is built around this single move.

The corollary is the sequencing rule that governs everything below: the incumbent is the last thing you turn off, not the first. A migration that removes the old agent before the new one is verified strands endpoints with no management at all — and those are exactly the endpoints (roaming laptops, seasonal machines, the one server behind a broken VPN) you will not get back without a site visit.

---

What Migrates, What Regenerates, What Is Lost

Set expectations with your team and your customers before you start. Nothing below is a Breeze limitation specifically — it is true of every RMM-to-RMM move.

Category	Status	Notes
Customer / site / device tree	You rebuild it	Scripted from the incumbent’s API. See Phase 2.
Hardware & software inventory	Regenerates	Full inventory lands within minutes of enrollment. No migration needed.
Patch state & compliance	Regenerates	Breeze re-scans; missing-patch state is accurate on first scan cycle.
Performance / metric history	Lost	Starts from zero at enrollment. Keep the incumbent read-only if you need historical charts.
Alert history	Lost	Open alerts should be triaged out before cutover, not migrated.
Scripts	Sometimes	Portable if the source engine is PowerShell/bash-based. Not portable from step-based engines — see below.
Monitors & alert thresholds	You rebuild them	Re-author as Breeze monitors and alert rules. Treat as an opportunity to prune.
Patch policies	You rebuild them	Map to Breeze patch policies and update rings.
Custom fields / UDFs / EDFs	Scriptable	Export from source, re-create as Breeze custom fields, backfill per device.
Documentation / passwords	Out of scope	Usually lives in IT Glue / Hudu / a PSA, not the RMM. Verify before assuming.
Tickets	Out of scope	Lives in your PSA. Re-point the PSA at Breeze via PSA integrations; the ticket history stays where it is.

The script-portability split

This is the single largest variable in migration cost, and it is determined entirely by your incumbent:

• Text-based engines port cleanly. Datto RMM components, NinjaOne scripts, Atera, Syncro, Pulseway, Action1, Automox worklets are PowerShell / bash / batch with a thin variable-injection wrapper. Rewrite the wrapper, keep the body.
• Step-based engines do not port at all. ConnectWise Automate scripts, Kaseya Agent Procedures, and N-able AMPs are proprietary XML step lists. There is no converter, and writing one is not worth it. Budget for re-authoring your top 20 scripts and deleting the rest.

Note

Most MSPs discover during this exercise that 80% of their script library is dead. Migrate what you have run in the last 12 months, and check Breeze’s system script library first — a large fraction of typical custom scripts already exist there.

---

The Seven Phases

1. Phase 0 — Inventory and decide

   Pull a full export from the incumbent: every client, every site, every device, with OS, role, last-seen, and agent version. You need this for three reasons — it is your migration checklist, your license reconciliation, and your proof of completion.

   Decide up front:

   • Which customers go first. Pick two: one small and friendly, one representative of your median customer. Do not start with your largest.
   • What you are not migrating. Devices that have not checked in for 90+ days are almost always decommissioned hardware still consuming a license. Migration is the cheapest time you will ever have to clean this up.
   • Your overlap window. Two to four weeks of running both agents is normal. Budget the double licensing.

2. Phase 1 — Stand up Breeze and set partner-wide defaults

   Get Breeze running (Quickstart) and configure everything you can once, at the partner level, before you create a single customer. Breeze is partner-wide-first: policies, script libraries, alert templates, patch policies, and maintenance windows can all be owned by the partner and applied across every organization.

   Doing this now is the difference between configuring one policy and configuring it eighty times. Set your scope selector to All orgs and define:

   • Alert rules and alert templates
   • Patch policies and update rings
   • Maintenance windows
   • Configuration policies
   • Your script library

3. Phase 2 — Rebuild the tenancy tree

   Map the incumbent’s hierarchy onto Breeze’s Partner → Organization → Site → Device Group → Device. The mapping is usually clean:

   Incumbent	Breeze
   NinjaOne Organization → Location	Organization → Site
   Datto RMM Site	Organization (one site each)
   ConnectWise Automate Client → Location	Organization → Site
   Kaseya VSA Organization → Machine Group	Organization → Site
   N-central Customer → Site	Organization → Site
   Atera Customer	Organization
   Pulseway Organization → Site → Group	Organization → Site → Device Group

   Breeze has no bulk import UI today, so this is scripted against the API — POST /orgs/organizations and POST /orgs/sites. The Migration Toolkit has a ready-to-run script that reads a two-column CSV and builds the whole tree, and each per-vendor page has the export query that produces that CSV.

4. Phase 3 — Deploy the Breeze agent from the incumbent

   For each organization, create an enrollment key sized to that customer’s device count, then push the install through the incumbent’s script engine.

   Key settings that matter for a bulk migration — the defaults are tuned for single installs, not fleets:

   Setting	Default	Migration value
   maxUsage	1	Device count + 20% headroom
   expiresAt	60 minutes	Long enough to cover your rollout wave
   siteId	—	Pin it, so devices land in the right site without per-device logic

   Add mutual antivirus and EDR exclusions for both agents before you push. Two RMM agents on one box, each with a watchdog restarting the other’s processes, is a reliable way to trip behavioural AV. See Antivirus Exceptions.

   Then roll in waves — pilot customer, then 10%, then the rest. Do not push to the whole fleet on day one.

5. Phase 4 — Verify enrollment device-by-device

   This is the phase people skip, and it is the one that determines whether the migration succeeds. Reconcile your Phase 0 export against Breeze’s device list per organization and drive the gap to zero.

   The stragglers always fall into the same buckets:

   • Offline at push time — laptops, seasonal machines. Re-run the job on a schedule for two weeks.
   • Old agent broken — the incumbent’s own agent was already dead, so the push never ran. These need manual attention and were invisible to you before now.
   • Blocked by AV/EDR — check exclusions.
   • Unsupported OS — verify against the Breeze agent platform matrix.

   Do not proceed to Phase 6 for any customer until their gap is zero or every remaining device is explicitly accounted for.

6. Phase 5 — Re-point integrations and rebuild content

   Run in parallel here. With agents reporting into Breeze:

   • Re-point your PSA so tickets are created by Breeze, not the incumbent. Connect via PSA integrations and map organizations. Run both alert sources briefly, then disable alerting in the incumbent so you are not double-ticketing.
   • Migrate scripts (see the portability split above).
   • Re-create monitors, thresholds, and custom fields.
   • Re-point EDR, DNS filtering, backup, and documentation integrations.
   • Re-create technician accounts, roles, and MFA. Do this properly rather than mirroring the incumbent’s grown-over-time permission sprawl.

7. Phase 6 — Cut over and decommission

   Only after a customer’s verification gap is zero:

   1. Disable alerting in the incumbent for that customer. Keep the agent installed and reporting.
   2. Wait one full patch cycle — typically one month. This is the window where you discover what you forgot.
   3. Uninstall the incumbent agent via its own script engine, per customer. Each vendor page documents the correct uninstall command.
   4. Verify the uninstall through Breeze’s software inventory: search for the incumbent’s agent across the fleet and confirm the count reaches zero.
   5. Downgrade or cancel the incumbent licence and export any historical data you are contractually required to retain — before the tenant is deleted, not after.

---

Sequencing Rules

These are the rules that prevent the failure modes worth caring about.

Rule	Why
Never uninstall before enrollment is verified for that specific device	Fleet-level “we’re at 98%” is not device-level verification. The 2% is where the site visits live.
Add AV/EDR exclusions before the push, not after	Two watchdogged agents look like malware to behavioural detection.
Keep the incumbent alerting until Breeze alerting is proven	Otherwise you have a window with no monitoring on production servers.
Configure partner-wide before creating orgs	Retrofitting per-org config into partner-wide config later is manual and error-prone.
Do not migrate a script you have not run in 12 months	You are migrating maintenance burden, not capability.
Export the incumbent’s historical data before cancelling	Tenant deletion is irreversible and the data is often contractually required.

---

Rough Timeline

For a typical 1,500-endpoint, 60-customer MSP. Scale the middle phases with customer count, not device count — per-customer overhead dominates.

Phase	Elapsed	Effort
0 — Inventory & decide	Week 1	1–2 days
1 — Stand up Breeze, partner-wide config	Weeks 1–2	3–5 days
2 — Rebuild tenancy tree	Week 2	Hours (scripted)
3 — Agent deployment waves	Weeks 3–6	1 day per wave
4 — Verification	Weeks 3–8	Ongoing, ~2h/customer
5 — Integrations & content rebuild	Weeks 3–8	The long pole — 1–3 weeks
6 — Cutover & decommission	Weeks 8–12	~1h/customer

The long pole is almost never the agent rollout. It is re-authoring monitors and scripts, and re-establishing technician workflow.

---

Next

Migration ToolkitReady-to-run API scripts for tree bootstrap, key generation, and enrollment reconciliation.

Enrollment KeysScoping, TTL, and usage limits for bulk enrollment.

Advanced Install MethodsSilent install flags for pushing the agent from another RMM.

API ReferenceThe endpoints the migration scripts call.