RMM Migration Playbook: Switch Platforms Securely

During an RMM migration two remote administration platforms run with system-level agents on every endpoint at the same time, and the old one is usually forgotten long before it is actually gone. Remote monitoring and management tools can run scripts, deploy software and open remote sessions across an entire estate, which is why attackers prize them and why CISA, NSA and MS-ISAC warned in advisory AA23-025A that legitimate RMM software is used for persistence and command and control. A platform change, whether driven by cost, an acquisition, an MSP changing provider or a product reaching end of life, multiplies that exposure for weeks or months. This vendor-neutral playbook is for IT operations, MSP and security teams who own the move. It covers inventory, the agent swap, identities and integration credentials, application control and network rules, cutover with rollback, and full removal of the old platform. Securing an RMM platform in steady state is covered in the RMM Tool Security Guide; a first deployment is covered in the Remote monitoring and management (RMM) tool rollout playbook.

Key takeaways

Dual running is the risk window. Keep it short, planned and monitored, with a fixed end date for the old agent on every device.
Update application control and network rules first. The new tool must be the only approved RMM, and the old one must become unauthorised the moment its last device is migrated.
Scripts and policies are code with privilege. Review every script and automation before moving it, rather than importing a library nobody has read in years.
Integration credentials outlive the platform. API keys, ticketing connectors and cloud application consents for the old RMM must be revoked, not just abandoned.
Prove removal on every endpoint. Uninstall reports are not enough: check for services, binaries and outbound connections of the old agent across the estate.

What has to move, and what must not

An RMM platform holds operational knowledge built up over years, much of it with high privilege. Inventory it by object type and decide deliberately what crosses over.

Object	Security concern	Typical decision
Managed device list and groups	Devices missing from the new platform lose patching and monitoring	Reconcile against the asset inventory or CMDB before cutover
Scripts and automation	Embedded credentials, outdated commands, mass execution rights	Review, remove secrets, re-approve; drop unused scripts
Patch and software deployment policies	Gaps in patch coverage during the move	Rebuild and verify coverage per device group
Monitoring and alert rules	Security-relevant alerts silently lost	Map each alert to its new equivalent and test it
Technician accounts and roles	Over-privileged and stale accounts copied over	Recreate from current role definitions through single sign-on
Integration credentials	API keys and app consents for ticketing, documentation, backup and cloud tenants	Issue new credentials; revoke old ones at the end
Stored credentials and vault entries	Domain admin and local admin passwords held in the old tool	Move to a secrets manager and rotate, never copy in plain form
Session recordings and audit logs	Evidence for investigations and contracts	Export and retain per policy before the old tenant is closed

The CISA-led Guide to Securing Remote Access Software (June 2023, co-authored with NSA, FBI, MS-ISAC and Israel's INCD) recommends a script approval process and a safeguard when one account pushes commands to many devices, giving the example of triggering MFA or other checks when an account sends commands to 10 or more devices within an hour. Apply that rule on the new platform from day one, before the imported script library is used at scale.

The agent swap and dual running

Most RMM migrations follow the same mechanics: the old platform pushes the new agent, the new agent checks in, and the old agent is uninstalled. That is efficient, but it uses the old tool's mass execution capability, which is exactly what ATT&CK technique T1072 Software Deployment Tools describes adversaries abusing. Treat the deployment job as a privileged change.

Sign and verify the installer: obtain the new agent package from the vendor's documented source, check its signature or hash, and store it where only the migration team can change it.
Use per-site or per-group enrolment tokens: enrolment keys are credentials. Scope them to a site or group, give them an expiry, and revoke them once enrolment completes, so a leaked installer cannot enrol rogue devices.
Set a dual-running limit: for example, no device runs both agents for more than 14 days. This figure is an NHI Mgmt Group recommendation, not a published standard; pick a limit and enforce it.
Uninstall from the new side as a backstop: after the old platform has done its uninstall pass, use the new platform to detect and remove any remaining old agent.
Handle offline devices: laptops that are off the network during the campaign keep the old agent. Track them and block the old platform's network destinations so stale agents cannot phone home.

Application control and network rules

Advisory AA23-025A recommends auditing remote access tools to identify authorised RMM software, allowlisting approved RMM programs through application control, blocking inbound and outbound connections on common RMM ports and protocols at the perimeter, and reviewing logs for RMM executed as a portable executable. A migration changes the answer to "which RMM is approved", so these rules must change in a planned sequence.

Phase	Application control	Network and proxy rules
Before pilot	Add the new agent by publisher certificate or hash to the allowlist; keep the old one allowed	Allow the new platform's documented destinations from managed devices only
Dual running	Both allowed; alert on either running on a device outside the migration plan	Both allowed; alert on RMM traffic from unmanaged hosts
Old platform retired	Remove the old agent from the allowlist; block its binaries; alert on execution	Block the old platform's destinations; alert on attempts
Steady state	Only the new RMM is approved; all other remote access tools blocked or alerted	RMM traffic only from managed endpoints, ideally only via approved paths

The same guide recommends allowing RMM use only through approved channels such as VPNs or VDIs where practical, and running RMM from local instances rather than over HTTPS port 443 where possible. Many cloud RMM products cannot work that way, so record the decision and compensate with tight egress rules and detection. The blocked old agent then becomes a detection opportunity: any execution after retirement is either a missed device or an attacker using a tool that is no longer approved. See Unauthorised Remote Monitoring and Management Tool Playbook for the response side.

Where identity fits: technicians, agents and integrations

An RMM platform is an identity hub. Technician accounts hold estate-wide rights, each agent is a machine identity that trusts the server, and the platform itself holds credentials for other systems.

Technician accounts: recreate them through single sign-on with phishing-resistant MFA rather than importing local accounts. The CISA guide recommends reduced-privilege roles for common tasks such as read-only monitoring, just-in-time access or two-factor authentication based on risk, and, for MSPs, treating accounts with access to customer environments as privileged and never reusing admin credentials across customers. See the Privileged Access Management Guide.
Stored credentials: many RMM tools hold domain or local administrator passwords for scripts. Move them to a secrets manager and rotate them as part of the migration; anything the old tool knew should be assumed exposed to it. The Local Administrator Password Solution (LAPS) Guide covers local administrator passwords.
Integration credentials: ticketing, documentation, backup and cloud management integrations use API keys or OAuth application consents. Issue new ones for the new platform and revoke the old ones in each connected system. The ConnectWise Cloud Backup breach shows how a single stolen application secret in MSP tooling can open many Microsoft 365 tenants, which is why old application registrations and consents should not be left behind.
The migration identity: the account that runs the cross-platform deployment job should be dedicated, time-limited and logged, and disabled when the campaign ends.

The phased playbook

Baseline. Export device lists, scripts, policies, technician accounts, integrations and the last 90 days of activity from the old platform. Reconcile devices against the asset inventory.
Build the new tenant securely. Single sign-on, MFA, role design, script approval workflow, mass-execution safeguards and logging to your SIEM, before any agent is enrolled.
Prepare controls. Add the new agent to application control allowlists and its destinations to egress rules. Create detections for both agents.
Pilot ring. Enrol IT's own devices and a small group of representative servers. Verify patching, monitoring, remote session logging and alert forwarding.
Expand in rings. For example, 10 percent of workstations, then non-critical servers, then the remainder, then critical servers in maintenance windows. Hold each ring until coverage and alerts are verified.
Rollback. Until a ring is complete, the old agent remains installed on that ring's devices, so rollback is re-enabling old policies and pausing the new agent. Once old agents are removed, rollback means redeploying them, so do not remove the old agent from a ring until the new one is proven.
Retire the old agent. Run the uninstall pass, then the backstop from the new platform, then switch application control and network rules to block the old tool.
Close the old platform. Revoke integrations, export and retain logs and recordings, disable technician accounts, delete stored credentials and confirm tenant data deletion with the provider. NIST CSF 2.0 outcome GV.SC-10 expects plans to cover what happens after a supplier relationship ends.

Decision guidance

Choice	Option A	Option B	Choose A when
Agent deployment route	Push via old RMM	Push via endpoint management or software distribution	The old RMM is healthy and trusted; choose B if the old platform is suspected compromised or near end of support
Script library	Migrate reviewed scripts	Rebuild from scratch	Scripts are documented and owned; choose B when nobody can explain half of them
Cutover style	Ring-based over weeks	Single weekend	Estate is large or spread over many customers; small single-site estates often finish faster with B
Hosting	Cloud-hosted RMM	Self-hosted RMM	You lack capacity to patch and harden an internet-facing server; B gives more network control but you own the patching

Small organisations: fewer devices make a fast, complete swap realistic; the main risk is forgetting integrations and stored passwords. MSPs and large estates: migrate customer by customer, keep separate enrolment tokens and technician roles per customer, and agree the timeline with each customer in writing, as the CISA guide recommends defining responsibilities in contracts.

Detection and measurement

Forward both platforms' audit logs to the SIEM throughout the migration. The CISA guide recommends logs of remote access execution that include binary, request type, IP address and timestamp, establishing a baseline of normal remote access activity, and keeping log servers out of the RMM tool's reach. Alert on: the old agent running after its ring has been retired; any third RMM tool appearing; scripts pushed to many devices outside change windows; new technician accounts or role changes; and enrolment of devices not in the asset inventory. ATT&CK T1219 Remote Access Tools gives a useful frame for these detections.

Coverage: percentage of inventoried devices reporting to the new platform (target 100 percent).
Dual-agent devices: count of devices running both agents, and the oldest one in days.
Residual old agents: devices where the old agent's service, binary or traffic is still seen after retirement (target zero).
Patch continuity: patch compliance per ring before and after the move, with no drop.
Credential hygiene: percentage of integrations and stored credentials re-issued or rotated, and old ones revoked.
Script review: percentage of migrated scripts reviewed and approved.

Common failure patterns

The ghost agent: offline or rebuilt devices keep the old agent, which keeps working because the old tenant was never closed.
Allowlists never updated: the old RMM stays approved in application control, so its use by an attacker looks normal.
Secrets imported with scripts: hard-coded admin passwords move into the new platform and nobody rotates them.
Integrations left live: the old platform's API keys and cloud application consents still work months later.
Accounts copied wholesale: former staff and over-privileged technicians are recreated on the new platform.
Logs lost: the old tenant is closed before audit logs and session recordings are exported, leaving gaps for investigations.

Framework mapping

Migration activity	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ATT&CK
Device and software inventory	CM-8 System Component Inventory	ID.AM-01, ID.AM-02
Approved RMM allowlist and blocking	CM-7 Least Functionality	PR.PS-01, PR.PS-02	T1219 Remote Access Tools
Agent deployment and script control	CM-3 Configuration Change Control, MA-4 Nonlocal Maintenance	PR.PS-01	T1072 Software Deployment Tools
Technician and integration identities	AC-2 Account Management, AC-6 Least Privilege, IA-5 Authenticator Management	PR.AA-01, PR.AA-05	T1199 Trusted Relationship
Patch continuity	SI-2 Flaw Remediation	PR.PS-02
Logging and detection	AU-2 Event Logging, AU-11 Audit Record Retention	PR.PS-04, DE.CM-09
Supplier exit	SA-9 External System Services, SR-12 Component Disposal	GV.SC-10

Practitioner checklist

Export devices, scripts, policies, accounts, integrations and logs from the old platform before starting.
Build the new tenant with single sign-on, MFA, least-privilege roles, script approval and mass-execution safeguards.
Add the new agent to allowlists and egress rules before the pilot; plan the date the old one becomes blocked.
Use scoped, expiring enrolment tokens and a verified installer.
Set and enforce a maximum dual-running period per device.
Review every script; remove embedded secrets and rotate them.
Re-issue integration credentials and revoke the old ones in each connected system.
Verify removal of the old agent by service, binary and network traffic, not uninstall reports.
Retain old audit logs and session recordings before closing the old tenant.
Confirm tenant data deletion with the old provider and record the exit.

Remote monitoring and management (RMM) tool migration playbook: moving platforms without losing control