Migrate an RMM Platform Without Losing Devices, History, or Visibility

An RMM platform is a privileged control plane, not merely an asset list. It can run code, patch systems, open remote sessions and expose secrets across many customers.

A migration must preserve operational visibility while deliberately transferring that authority.

Define acceptance before exporting

For every customer/service, state:

• devices/sites in scope and accountable owner;
• required monitoring and alert response;
• patch policy/maintenance/reboot outcomes;
• remote access and MFA/RBAC model;
• scripts, jobs and automation that remain needed;
• custom attributes, documentation and integrations;
• audit/history retention and privacy obligations;
• acceptable visibility gap and outage;
• emergency/break-glass access; and
• source retirement date/conditions.

Do not promise that every old dashboard widget will migrate. Preserve the business/security outcome and any history that remains genuinely required.

Inventory three different things

Managed population

Customer, site, endpoint identity, serial/unique IDs, OS, role, criticality, network/location, owner and last-seen freshness.

Control configuration

Monitoring checks, alert thresholds/routes, patch/update/reboot policies, scripts/jobs/schedules, remote tools, exclusions, custom fields, credentials/secrets references and integrations.

Evidence/history

Audit events, remote-session logs, alerts/incidents, patch history, asset history, script results, tickets and reporting/contract records.

Export availability does not equal full fidelity. Record source class, target representation, retention decision and verification evidence.

Secure the target before deploying agents

Complete:

• separate named administrators and MFA;
• least-privilege roles/customer/site boundaries;
• conditional/network access where supported;
• controlled service/API accounts and secret rotation;
• audit/event export to a destination the RMM cannot erase;
• alerting for admin, policy, script and remote-session activity;
• signed/verified agent packages and allowed deployment paths;
• customer/provider incident contacts; and
• break-glass governance.

CISA warns that remote-management platforms are attractive to attackers precisely because they offer privileged reach. Migrating first and hardening later creates a second powerful attack path.

Create a crosswalk, not a copy

For each old control record:

Do not bulk-enable converted scripts because names match. Examine inputs, privileges, exit handling, dependencies, schedules, customer scope and secret access.

Match devices with more than hostname

Hostnames change and duplicates exist. Build a controlled source-to-target map using multiple stable properties where lawful:

• hardware/firmware serial or asset ID;
• OS installation/device identity;
• customer/site membership;
• network identity as supporting evidence;
• source and target agent IDs; and
• owner-confirmed exceptional mapping.

Track states: source-only, both, target-only, expected retired/excluded, duplicate/conflict and unknown. Never auto-merge across customers from a hostname or serial alone without tenancy checks.

Plan coexistence narrowly

Two agents may both run patching, reboot, scripts, monitoring, remote sessions, software inventory and security exclusions. Define for each wave:

• which platform is authoritative for each function;
• which source automations/patch/reboot jobs are disabled;
• resource and security-tool compatibility;
• maximum coexistence duration;
• detection of missing/duplicate agents; and
• rollback if the target loses contact.

Keep independent endpoint access for recovery. Do not use the new RMM as the only way to repair its own broken deployment.

Pilot representative endpoints

Include servers/workstations, remote/office devices, varied OS/builds, line-of-business apps, low-bandwidth/offline endpoints and relevant security controls.

For each, verify:

• exact customer/site/device mapping;
• agent identity, service and check-in freshness;
• inventory completeness;
• monitoring and alert creation/routing/closure;
• patch detection/approval/install/reboot semantics;
• bounded script execution and failure reporting;
• remote access consent/audit/control;
• integrations/tickets/reports; and
• source-agent suppression/uninstall/reinstall path.

A green target agent proves only one telemetry path. Trigger controlled outcomes and verify the people/process response.

Deploy in reconciled waves

Before each wave, freeze the target list, preview counts by customer/site/OS/role and define failure/stop thresholds. After deployment:

1. confirm target-agent installation and current check-in;
2. reconcile source and target identities;
3. validate controls for sampled/critical devices;
4. resolve unknown/duplicate/no-contact devices;
5. obtain wave acceptance; and
6. only then retire the source control for accepted endpoints.

Do not treat offline endpoints as completed because the installer command was queued.

Preserve audit and history intentionally

Export required history to controlled, searchable evidence with documented schema/time zone and retention. Preserve source IDs and context. If the target cannot import it faithfully, maintain a read-only archive rather than flattening it into misleading target events.

Protect customer separation and personal data in exports. Remove temporary copies after acceptance according to the approved retention decision.

Uninstall the old agent safely

Confirm:

• target control is accepted;
• source agent/tamper/uninstall credential is available through an approved channel;
• removing it will not remove shared dependencies or customer data;
• security tooling permits the signed uninstaller;
• endpoint remains reachable if uninstall fails; and
• no source automation can reinstall it.

Use the source vendor’s exact current uninstall path. Avoid generic service/registry/file deletion, which can leave privileged components, corrupt inventory and prevent supported cleanup.

Final reconciliation and retirement

The closeout should show:

• every in-scope endpoint in one explicit state;
• no unauthorised or unexplained RMM software;
• monitoring/alert/patch/automation coverage accepted;
• admin/service accounts reviewed and source access revoked;
• source agents/tokens/API keys removed or exceptions owned;
• independent logs and incident contacts working;
• required history archived and recoverable;
• licensing/billing/customer records reconciled; and
• old tenant/platform disposition confirmed.

The migration ends when privileged authority, operational visibility and historical accountability have moved—or been deliberately retained—not when the target dashboard has roughly the right device count.