EDR and XDR platform migration playbook: swap endpoint agents without coverage gaps

Replacing an endpoint detection and response platform means removing one kernel-level security agent and installing another on every endpoint and server, and every device where the old agent is gone before the new one is protecting is a device with no detection at all. Organisations change EDR or XDR platforms at contract renewal, after a merger, when consolidating onto a wider security suite, after a damaging outage or poor detection performance, or when a managed detection provider brings its own platform. This playbook covers the migration itself: what has to move, coexistence of two agents, translating exclusions, detection content and response actions, the identities and credentials involved, deployment rings, and removing the old agent safely. It is vendor-neutral and draws on NIST SP 800-83 Rev. 1, NIST SP 800-61 Rev. 3, OMB memorandum M-22-01 and MITRE ATT&CK. How EDR works and where it goes blind is covered in the EDR Evasion and Defence Guide, and choosing a platform in the EDR and XDR Buyer's Guide.

Key takeaways

• Install before you remove. The new agent must be installed, reporting and in a protecting mode before the old agent is uninstalled from that device.
• Two active agents fight. Running both in full blocking mode risks crashes, performance problems and each agent quarantining the other; put one into a monitor or passive state for the overlap.
• Exclusions are a risk register, not a config file. Re-justify every exclusion rather than copying the old list; years of broad exclusions are where attackers hide.
• Uninstalling the old agent looks like an attack. Tamper protection has to be lifted to remove it, so do it with per-device tokens, in a change window, with the new agent watching.
• The coverage gap is the main metric. Track, every day, the number of devices with no healthy protecting agent, and drive it to zero.

What an EDR or XDR migration actually moves

OMB memorandum M-22-01 describes EDR as combining real-time, continuous monitoring and collection of endpoint data with rules-based automated response and analysis. A migration has to preserve all three: coverage, telemetry and response. The supporting tools are covered in the EDR and XDR platform integration security guide.

Coexistence of two agents

Whatever the model, check both suppliers' documented compatibility for running alongside another security agent, test on each operating system build and server role, and plan the overlap per ring to last days, not months. Kernel-level conflicts and faulty updates can take whole fleets down; keep the recovery steps from the Security Tool Faulty Update Outage Playbook to hand during the rollout.

Exclusions, detections and response actions

• Exclusions: export the old list with any recorded owner and reason. Re-create only exclusions with a current owner, a named process or path rather than a folder or drive, and a review date. Prefer exclusions by signed publisher or hash over path. Many old exclusions existed only to stop the old agent's performance problems and are not needed at all. See the EDR Tuning and Exclusions Management Guide.
• Detection content: list custom detections and hunting queries, map each to the ATT&CK technique it covers, rewrite it in the new platform and prove it fires against safe test activity before the old platform goes. A technique coverage comparison before and after is the honest measure of whether you gained or lost detection.
• Tamper and defence impairment detection: make sure the new platform alerts on attempts to stop or modify security tools and logging, which ATT&CK v20 tracks under the Defense Impairment tactic (TA0112), including T1685 Disable or Modify Tools, T1685.001 Disable or Modify Windows Event Log and T1685.005 Clear Windows Event Logs, and T1489 Service Stop. These techniques look like migration activity, so define in advance what an approved uninstall looks like.
• Response actions: re-create host isolation, process termination, file quarantine and remote script actions with role-based approval, and test isolation on a pilot device including how to release it. Update SOAR playbooks and SIEM rules that call the old platform.
• Telemetry history: decide how long the old platform stays readable for investigations. M-22-01 asks federal agencies to consolidate, retain and archive endpoint data in a way that supports analysis; the same principle applies when the source system is being switched off.

Device classes that need their own plan

• VDI and golden images: install the new agent in the image with the supplier's documented preparation for cloned machines, so clones do not share an agent identity; remove the old agent from the image in the same version.
• Domain controllers and identity servers: migrate one at a time with rollback ready; an agent fault here affects authentication for everyone.
• Legacy and unsupported operating systems: if the new platform does not support them, isolate them on restricted network segments and record the exception with an end date rather than keeping the old platform alive for them alone.
• Cloud workloads and containers: short-lived instances are migrated by changing the image or deployment template, not by installing on running hosts.
• Remote and rarely connected laptops: deliver the new agent through the device management service over the internet and remove the old one only after the new agent reports in.

Where identity fits

EDR and XDR platforms are privileged non-human identities on every endpoint. The migration creates and retires several powerful credentials at once.

• Deployment credentials: the software distribution tool, device management service or script that installs the new agent runs with local administrator or root rights everywhere. Scope it to the migration, log it and remove extra rights afterwards (NIST SP 800-53 AC-6).
• Installation and uninstall tokens: enrolment tokens should be per tenant and rotated after the rollout; old-agent uninstall or maintenance tokens should be per device where the platform supports it, never one shared fleet token in a script.
• Console administrators and API clients: create new roles from least privilege, with phishing-resistant authentication for administrators, and new API clients for SIEM, SOAR and MDR integrations. Revoke all old platform accounts and API keys at contract end (IA-5).
• Managed provider access: if an MDR provider operates the new platform, record exactly which response actions it may take without approval.
• Local admin and service accounts: use the migration to find local administrator and service accounts on endpoints that the new platform reports. See the Service Account Security Guide.

Hardening the new console and its access is covered in Securing the EDR and XDR platform itself.

The phased playbook

1. Inventory and baseline: reconcile the old console's device list with the asset inventory, directory and device management records to find unmanaged devices. Record current coverage, detection metrics and ATT&CK coverage for comparison.
2. Design policies and roles: device groups, prevention policies in detect-only mode, reviewed exclusions, response roles and integrations.
3. Lab and pilot ring: test install, coexistence, performance, removal of the old agent and rollback on every operating system build and key server role, then deploy to IT and security staff devices.
4. Tune in passive mode: run the new agent alongside the old one on early rings, review detections and false positives, and adjust policies before enabling prevention.
5. Roll out in rings: general workstations, then specialist and high-value users, then servers by tier, with domain controllers and other critical servers last and in their own change windows. Pause criteria (crash rate, performance complaints, failed installs) are agreed before each ring.
6. Switch prevention per ring: set the new agent to protecting mode, confirm health, then remove the old agent with per-device tokens in the same change window.
7. Chase the long tail: offline laptops, remote workers, appliances and legacy systems. Track each one by name until it is migrated, isolated or formally excepted with compensating controls.
8. Decommission: confirm zero devices report to the old console, export retained telemetry, revoke accounts, API keys and tokens, and remove its integrations.

Rollback: until the old agent is removed from a ring, rollback means setting the new agent back to passive or uninstalling it while the old agent keeps protecting. After removal, rollback means reinstalling the old agent, so keep its installer, tokens and console available until the final ring has run cleanly (our recommendation: at least 30 days). Small organisations with a single device management tool can often migrate in two or three rings over a few weeks; large estates with many server roles and operating systems should plan in months, with servers as a separate project.

Detection and measurement

Send both platforms' agent health and tamper alerts to the SIEM during the overlap, and alert on uninstall events that do not match a change record. NIST SP 800-83 Rev. 1 treats malware incident prevention and handling as an ongoing capability; the migration should not interrupt it for any device group.

Common failure patterns

• Remove first, install later: the old agent is uninstalled by a script and the new install fails silently on some devices, leaving them with nothing.
• Exclusions copied wholesale: broad folder and process exclusions carried over, giving attackers the same blind spots on the new platform. The EDR Evasion and Defence Guide covers how those gaps are abused.
• Shared uninstall token in a script: one fleet-wide token used to remove the old agent ends up in a file share or ticket, where an attacker could use it to remove protection too.
• Servers last and forgotten: workstations migrate quickly; servers, domain controllers and legacy systems stay on the old platform after the contract ends.
• Broken integrations: SIEM rules and SOAR playbooks still expect the old platform's alert format and stop firing.
• Prevention enabled without tuning: the new agent blocks line-of-business software on day one, and the response is a broad new exclusion.

Framework mapping

Practitioner checklist

• Reconcile the old console's devices with the asset inventory before deploying.
• Choose a coexistence model per device class and test it on every build.
• Install and verify the new agent before removing the old one, device by device.
• Re-justify every exclusion; carry over none by default.
• Rewrite and test custom detections; compare ATT&CK coverage before and after.
• Use per-device uninstall tokens and alert on uninstalls outside change windows.
• Update SIEM rules, SOAR playbooks and MDR procedures to the new platform.
• Migrate servers and domain controllers as their own tracked rings.
• Track the coverage gap daily until it reaches zero.
• Revoke all old console accounts, API keys and tokens at decommissioning.

Standards and references

• NIST: SP 800-83 Rev. 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• OMB: M-22-01, Improving Detection of Cybersecurity Vulnerabilities and Incidents on Federal Government Systems through Endpoint Detection and Response
• MITRE ATT&CK: Disable or Modify Tools (T1685)
• MITRE ATT&CK: Service Stop (T1489)
• NIST: SP 800-53 Rev 5, Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: EDR Evasion and Defence Guide · EDR Guide · EDR and XDR platform day-2 operations runbook · EDR Tampering and BYOVD Response Playbook