Introduction

A security tooling migration can bring the new console online while endpoint agents still report telemetry to the old tenant or management server. Alerts appear missing, detections fire in the retired platform, or one device group shows up in the new console while another stays invisible because endpoint agents usually keep their own enrollment token, relay target, or management profile long after the backend changes.

Treat this as an agent-enrollment problem instead of assuming endpoint protection is broken. Start by checking where an affected host actually sends events and management traffic, because migrations often validate the new security console first while installed agents continue following the previous tenant or relay path.

Symptoms

  • Endpoint security events still appear in the old console after migration
  • The new security platform shows fewer devices or detections than expected
  • One device group reports correctly while another still uses the previous tenant
  • Policy changes in the new console have no effect on affected endpoints
  • Event forwarding works until the old relay or tenant is disabled
  • The issue started after moving EDR, endpoint protection, SIEM agent, or security management infrastructure

Common Causes

  • The endpoint agent still uses the old tenant ID, management URL, or relay server
  • Enrollment tokens, bootstrap packages, or agent policies still point to the previous console
  • Golden images or endpoint management tooling keep reinstalling the old security profile
  • One sensor relay or update channel was migrated while another still serves the retired environment
  • DNS aliases, certificates, or outbound allowlists still route agent traffic to the old platform
  • Validation confirmed the new console was online but did not verify where installed agents actually checked in

Step-by-Step Fix

  1. Capture one affected endpoint and record the exact console URL, tenant, or relay server the agent is using, because the live management path matters more than the intended migration target.
  2. Compare that active destination with the intended post-migration security platform, because one stale enrollment profile can keep an entire endpoint set tied to the retired console.
  3. Review agent policies, deployment packages, relay settings, endpoint-management baselines, and golden images for references to the old tenant or server, because security tooling often persists through several management layers.
  4. Check whether event telemetry, policy sync, and content updates use different endpoints, because migrations often move one path while another still points to the previous platform.
  5. Update the authoritative enrollment and management settings and re-register affected agents if required, because console-side changes alone do not retarget already installed endpoints.
  6. Trigger a controlled check-in or test detection and confirm the intended console receives it, because a running local agent does not prove telemetry reaches the right platform.
  7. Verify the old console no longer receives events or check-ins from migrated endpoints, because split security visibility can leave monitoring and response incomplete.
  8. Review certificates, egress rules, and tamper protection if agents fail to switch, because the target can be correct while transport or local controls still block migration.
  9. Document which team owns agent packaging, endpoint policy, and migration validation so future security platform changes confirm real check-in paths before retiring the previous console.