RMM migration · 13 minute read
RMM migration checklist for MSPs
Switching tools is not an installer swap. A safe migration preserves device coverage, limits privileged access, avoids conflicting management, proves removal, and keeps a recovery path until the new system is verified.
Ten phases from inventory to clean removal
Tailor the sequence to the client and both vendors. Test all actions on authorized, noncritical systems before touching a production wave.
1. Define the migration boundary
Write down exactly which tenants, sites, devices, operating systems, server roles, technician groups, and integrations are moving. Name an owner for the overall change and one accountable contact for every client.
- Use a stable device identifier so duplicate names do not create duplicate or missing endpoints.
- Separate the pilot, production waves, exceptions, and explicitly out-of-scope systems.
- Record the maintenance windows, blackout periods, and approval path for each client.
2. Export the old system before changing it
Preserve the evidence needed to operate and to prove what existed before the cutover. Do not rely on continued access to the departing platform after cancellation or offboarding begins.
- Export device inventory, custom fields, site mappings, policies, scripts, monitors, patch rules, alert routes, reports, and audit logs.
- Capture installer and uninstall methods, service names, scheduled tasks, certificates, exclusions, and network requirements.
- Store the exports under access control with an owner and retention date.
3. Rebuild identity and access first
Configure the destination platform's tenant boundaries, technician roles, multifactor authentication, emergency access, approval controls, and audit retention before enrolling client devices.
- Grant least privilege by role and client scope instead of copying broad legacy access.
- Test onboarding, role changes, account suspension, and emergency access with named owners.
- Confirm remote-control sessions and sensitive actions create usable audit evidence.
4. Inventory every management authority
An endpoint can be governed by RMM, MDM, Group Policy, security tooling, local tasks, vendor utilities, or another MSP. Identify which system owns each setting before two authorities issue conflicting instructions.
- Map patching, reboot, antivirus, firewall, local administrator, encryption, and update-ring authority.
- Identify scripts or policies that reinstall the departing agent automatically.
- Treat MDM unenrollment separately: Microsoft documents cases where disconnection can remove apps, certificates, policy, or data.
5. Build the destination configuration
Recreate only the controls that are still intentional. A migration is a chance to retire stale monitors, overlapping scripts, unsafe exclusions, and inherited defaults rather than copying years of configuration debt.
- Document the purpose, owner, scope, trigger, timeout, success condition, and rollback for each automation.
- Create deployment rings for monitoring, patching, scripts, and policy changes.
- Keep high-risk actions disabled until their approvals and recovery steps are tested.
6. Prove the pilot on representative devices
Use authorized lab or noncritical endpoints that represent common hardware, remote workers, servers, line-of-business applications, intermittent devices, and constrained networks.
- Verify installer authenticity, enrollment identity, check-in, inventory, monitoring, patch status, remote support, and audit history.
- Exercise an offline endpoint, failed action, pending restart, rejected approval, and incomplete removal.
- Define objective promotion criteria and a written go or no-go decision.
7. Run controlled coexistence
A short overlap can preserve visibility, but two active tools can also duplicate scripts, alerts, patch approvals, restarts, remote access, and security exclusions. Decide exactly which capabilities remain active in each system.
- Put one system in observe-only mode wherever ownership would otherwise overlap.
- Suppress duplicate alerts only after confirming the destination alert reaches the right person.
- Set a maximum overlap period so temporary dual management does not become permanent.
8. Migrate in recoverable waves
Move small cohorts with a pause between them. Reconcile the original scope after every wave and stop when the measured result falls outside the agreed threshold.
- Keep critical servers, executive systems, kiosks, and fragile applications in deliberate late waves.
- Track enrolled, healthy, offline, failed, duplicated, excluded, and unknown devices separately.
- Maintain an out-of-band contact and recovery path if both management agents fail.
9. Remove the old tool cleanly
Confirm destination control before uninstalling the old agent. Then remove obsolete services, tasks, users, certificates, firewall rules, exclusions, scripts, API connections, webhooks, and delegated access.
- Use the vendor-supported uninstall path and record success or failure for every device.
- Revoke old technician accounts, service accounts, tokens, API keys, and unattended-access permissions.
- Scan for unauthorized or unexpected remote-access software after the change.
10. Close with evidence, not assumptions
Reconcile the final device list, test key workflows, review access, document every exception, and obtain client acceptance. Keep a time-bound remediation owner for anything unresolved.
- Verify monitoring, alert delivery, patch authority, remote support, automation, reporting, backup visibility, and security-tool health.
- Compare the destination count with the original inventory and explain every difference.
- Retain the migration log, approvals, exports, exceptions, and rollback decisions for the agreed period.
Test Nizlo before you migrate
Run a controlled 14-day pilot on your own checklist.
Qualified MSP and IT operators can evaluate Nizlo without a credit card on authorized lab or noncritical Windows systems. Founding Tester discounts are awarded by successful paid upgrade order: the first five receive 75% off for life, the next five 50%, and the next ten 25%. Applying or starting a trial does not reserve a position.
Apply for the Founding Tester pilot