Migrating from Microsoft Defender for Endpoint to CrowdStrike Falcon: A 90-Day Playbook

You’ve made the decision. Whether it was driven by a specific capability gap, a cyber insurance requirement, a post-incident review, or a broader platform consolidation strategy, you’re moving from Microsoft Defender for Endpoint to CrowdStrike Falcon. This playbook is for the person who now has to actually do it.

Before we get into the execution detail, one honest framing: EDR migrations go badly when they’re treated as product swaps. They go well when they’re treated as operational transitions. The agent is the easy part. The hard parts are policy translation, exclusion re-engineering, ticket and alert flow adjustment, analyst retraining, and — critically — managing the 60–90 days where your environment is in a mixed state and neither EDR is fully trusted.

If you haven’t finalised the decision yet, or you’re second-guessing it, our three-way EDR comparison for mid-market goes through the trade-offs honestly. Assuming you’re committed, read on.

What you gain, and what you lose

Any migration guide that doesn’t name what you’re giving up is selling you something. Let’s be clear about the trade-offs.

What you gain moving to Falcon: Stronger threat intelligence integration via Falcon Intelligence, a more mature managed service option (Falcon Complete, if you’re adding it), cleaner console UX, more mature non-Windows coverage (particularly on Linux server), and a platform that extends natively into identity, cloud, and log management without additional agents.

What you lose leaving Defender: Integrated telemetry correlation across the full Microsoft security stack — Defender for Identity, Defender for Office 365, Defender for Cloud Apps, Entra ID sign-in logs, Intune device compliance. This correlation has genuinely improved over the past two years and is Defender’s strongest feature. You also lose pricing simplicity (Defender’s per-user E5 bundling vs Falcon’s per-endpoint modular pricing) and the ability to run the full security stack through one vendor relationship.

You don’t have to lose all of this. Many organisations moving to Falcon keep Defender for Identity, Defender for Office 365, and Defender for Cloud Apps running as non-endpoint security tools — they’re not tied to Defender for Endpoint and they remain valuable independently. The Microsoft 365 licensing you’re already paying for doesn’t become redundant just because you’ve changed your endpoint EDR. We’ll cover this in the licensing optimisation section.

The 90-day structure at a glance

The 90-day timeline isn’t arbitrary. It reflects three realities: agent rollout takes longer than vendors pretend; policy tuning requires observation of real-world traffic before you can cut over confidently; and the human side (retraining analysts, rebuilding runbooks, integrating alerting) takes time you can’t compress without creating gaps.

Days 1–14: Planning, licensing, and architecture. No deployment yet. This is where most migrations go wrong — they skip this phase.
Days 15–35: Falcon deployment in coexistence mode. Defender stays active in full mode; Falcon is installed and running in parallel on a pilot ring.
Days 36–60: Expansion, tuning, and Defender transition to passive mode. Falcon becomes primary; Defender moves to passive mode as a backup detection layer.
Days 61–85: Production cutover and Defender shutdown. Defender for Endpoint EDR is fully disabled or uninstalled. Falcon is authoritative.
Days 86–90: Post-migration review, insurance notification, and operational handoff.

Days 1–14: Planning

The skipped phase. If you do this phase well, the rest is execution. If you skip it, you’ll spend the whole migration fighting problems that should have been solved on a whiteboard.

Licensing optimisation

Before touching a single endpoint, run the licensing calculation. Mid-market companies frequently over-pay during EDR migrations by either keeping Defender licensing they no longer need, or dropping Microsoft licensing whose non-endpoint components they still value.

If you’re on Microsoft 365 E5: Defender for Endpoint Plan 2 is included. You cannot “stop paying for it” without dropping E5 entirely, which would also lose Defender for Identity, Defender for Office 365 Plan 2, Defender for Cloud Apps, Purview, and Intune Plan 2. Almost no mid-market migration makes sense as “drop E5” — the non-endpoint components retain value. Plan to keep E5, disable Defender for Endpoint onboarding for migrated endpoints, and accept that you’re paying for Defender licensing you’re no longer using at the endpoint layer. This is a cost reality of running Falcon on top of E5.

If you’re on E3 plus Defender for Endpoint Plan 2 as an add-on: you can genuinely stop paying for the Plan 2 add-on once migration is complete. Note the timing carefully — your Microsoft enterprise agreement renewal date controls when you can drop it. Talk to procurement early.

If you’re on Microsoft 365 Business Premium: Defender for Endpoint Plan 1 is included. You’re not paying extra for it; there’s no cost to “drop.” Focus on migration execution.

Architecture decisions

Make these decisions now, document them, and get sign-off. Changing course mid-migration is expensive.

Which Falcon tier? Falcon Pro, Enterprise, or Complete. If you’re adding Falcon Complete (managed), the CrowdStrike team becomes a named partner in this migration — involve them in planning from day one. If you’re self-operating, you own the runbook rebuild.

Which additional modules at launch? Many migrations attempt to deploy Falcon Insight, Falcon OverWatch, Falcon Identity Protection, and Falcon Cloud Security simultaneously. Don’t. Deploy the core EDR agent first, stabilise, then add modules over the subsequent quarter. Adding modules mid-rollout creates tuning noise that masks real detections.

Coexistence architecture. Falcon and Defender for Endpoint can run simultaneously, but only when Defender is in passive mode. During the pilot phase (days 15–35), you want Defender still in full active mode on non-pilot endpoints. During the expansion phase (days 36–60), Defender moves to passive mode on migrated endpoints while Falcon becomes primary. Document the exact state each endpoint ring will be in at each phase.

Deployment rings. Define three to five rings. A typical mid-market structure: Ring 1 (IT and security team endpoints, 20–50 machines), Ring 2 (IT-adjacent power users, 50–150 machines), Ring 3 (general corporate endpoints, bulk of workforce), Ring 4 (executive and high-risk users, last to move because the risk of disruption is highest), and a separate server ring (Windows servers, Linux servers, and Mac if applicable, phased independently because tuning differs).

Policy translation inventory

Defender for Endpoint policies don’t map one-to-one to Falcon. You’ll need to translate:

Attack Surface Reduction (ASR) rules in Defender → Falcon policy groups and exclusions
Controlled Folder Access → Falcon host-based firewall policies or equivalent controls
Defender Antivirus exclusions → Falcon Prevent exclusions (format is different, logic is different)
Custom indicators (IOCs) maintained in Defender → Falcon custom IOCs
Network protection rules → Falcon’s equivalent or, if you’re using Falcon with separate network security, into your firewall/proxy

Inventory every custom Defender rule and exclusion you’ve built up over the years. Expect to find 50–200 exclusions in a mature Defender environment. Many of these accumulated without documentation. Now is when you audit them: which are still needed? Which were tactical workarounds for issues that have since been resolved? Don’t just port them — review them.

Integration points

Enumerate every system currently receiving Defender data or sending data to Defender:

Microsoft Sentinel (or whichever SIEM)
Your ticketing system (ServiceNow, Jira, etc.)
Vulnerability management (Defender for Endpoint’s threat and vulnerability management module)
Asset inventory
Compliance evidence collection (if you’re using Defender reports for SOC 2 or ISO 27001 evidence, you’ll need to re-establish those flows with Falcon)

Each of these is a project within the project. None of them can be left until week 10 to figure out.

Days 15–35: Pilot deployment in coexistence

Ring 1 only. IT and security team endpoints. Falcon is installed alongside active Defender for Endpoint. Both are watching. Neither is authoritative yet.

Deployment mechanics

Deploy the Falcon sensor via your endpoint management platform (Intune if you’re Microsoft-centric, SCCM/MECM for legacy Windows fleets, Jamf for Mac, your preferred Linux config management for Linux). CrowdStrike’s deployment guides are genuinely good — follow them.

Verify for each endpoint:

Sensor appears in the Falcon console within an hour of deployment
Sensor is reporting with no errors
Prevention policies are applied as intended (don’t accept defaults without review)
Defender for Endpoint is still active and reporting to the Microsoft 365 Defender portal

This is the most common failure point: deploying Falcon without verifying every sensor is actually checked in and communicating. A Falcon sensor that failed silently is worse than no coverage at all, because you think you have coverage.

Coexistence gotchas

Running two EDRs simultaneously surfaces issues you won’t see in a single-agent deployment:

CPU and memory overhead. Both agents scanning the same files, reading the same process trees, hooking the same system calls. Performance impact is real, particularly on older hardware. Monitor CPU and memory on Ring 1 endpoints carefully.
False positive cross-triggers. Defender may flag Falcon’s own scanning activity, and vice versa. Expect a cluster of false positives in the first 48 hours as each EDR observes the other. Don’t tune these out reflexively — understand what’s being flagged before suppressing.
Conflicting exclusions. An exclusion that was necessary for Defender may not be needed for Falcon, and vice versa. Don’t copy exclusions across without testing.

Tuning the pilot

Expect to spend the majority of days 15–35 tuning, not deploying. The deployment itself takes days. The tuning takes weeks. You’re looking for:

Alert volume calibration — is Falcon generating 10× the alerts Defender was, or 0.1×?
Exclusion gap identification — what legitimate software is triggering prevention that needs to be whitelisted?
Policy strictness calibration — is Falcon Prevent set too loose (missing things) or too tight (blocking legitimate activity)?
Integration verification — are alerts flowing into your SIEM, ticketing, and notification channels as expected?

Document every tuning decision. You’ll need to apply these decisions consistently when you expand to Ring 2 and beyond.

Days 36–60: Expansion and Defender transition to passive mode

Rings 2 and 3 come online. Falcon is now authoritative on all migrated endpoints. Defender for Endpoint moves to passive mode on those endpoints.

Moving Defender to passive mode

This is a specific Microsoft-documented configuration. On Windows endpoints, set the ForceDefenderPassiveMode registry value (or use Intune configuration profiles) to transition Defender for Endpoint from its default active mode to passive mode. In passive mode, Defender still runs but doesn’t take primary responsibility for real-time protection — Falcon does.

Passive mode keeps a useful capability: Defender continues to generate some telemetry, which can act as a second-source verification during the transition period. If Falcon and passive-mode Defender disagree significantly about an endpoint’s state, that’s a signal worth investigating.

Do not uninstall Defender yet. Keeping it in passive mode is a safety net during the period where you’re still building confidence in Falcon’s coverage.

Expanding policy tuning

The tuning decisions made in Ring 1 now need to be validated at scale. Ring 3 in particular — general corporate endpoints — is where you’ll discover edge cases that pilot rings never hit:

Line-of-business applications that weren’t on any IT or security team endpoint
Legacy internal tools with unusual install patterns
Vendor-specific remote access tools that have their own behaviour signatures
Developer toolchains (if you haven’t put developers in their own ring yet, consider doing so — they’re always a special case)

Expect a second wave of exclusion engineering in days 36–50. This is normal. The goal is to emerge from day 60 with a tuning configuration you trust to handle the remainder of the fleet.

Analyst retraining

Your security analysts have built mental models around Defender’s alert patterns, false positive distribution, and investigation workflow. Falcon is different. Don’t assume the transition is intuitive.

Concrete steps:

Run tabletop exercises using real historical incidents, replayed against Falcon’s console. Can the team navigate to the same evidence in the same time?
Rewrite your detection and response runbooks for Falcon’s specific workflow. Don’t leave Defender-specific steps in runbooks and expect analysts to translate on the fly.
If you’re going to Falcon Complete, define explicitly which incidents the managed service owns vs which your internal team owns. Unclear boundaries here are the number one cause of friction in the first six months.

Days 61–85: Production cutover and Defender shutdown

All rings are now on Falcon in production. Time to turn Defender for Endpoint off.

The disable or uninstall question

You have two options for ending Defender for Endpoint:

Disable onboarding without uninstalling. Stop reporting Defender for Endpoint data to the Microsoft 365 Defender portal by offboarding the endpoints. Microsoft Defender Antivirus continues to run (in passive mode if configured), providing a baseline AV capability. This is the safer option for most organisations — keeping a baseline Microsoft AV in passive mode costs nothing extra and provides a minor resilience benefit.

Fully uninstall and disable Defender Antivirus. Remove Defender for Endpoint via offboarding scripts and disable Defender Antivirus via group policy. More thorough, but removes a backup detection layer you might find useful. We’d generally recommend against this for mid-market — the operational simplification isn’t worth the loss of defence in depth.

Verification checklist before declaring migration complete

Before you sign off migration as done, verify:

Every endpoint in scope is onboarded to Falcon and reporting actively
Every endpoint in scope has been offboarded from Defender for Endpoint reporting
Every integration (SIEM, ticketing, vulnerability management, compliance reporting) is working against Falcon data
Your incident response runbook is updated and has been exercised at least once since cutover
Your analysts can independently navigate a Falcon investigation without reference to documentation for common incident types
Your Falcon Complete or managed service partnership, if applicable, is fully operational and tested
Your cyber insurance broker has been notified of the EDR change (important — some policies reference specific vendors)

Do not declare migration complete just because agents are deployed. Declare it complete when the operational model around the agents is working.

Days 86–90: Handoff and post-migration review

Post-migration review

Hold a genuine retrospective. What took longer than expected? What policies were harder to translate than anticipated? What gaps did the migration expose that were masked under Defender? These learnings should feed into runbook updates, documentation, and future platform decisions.

Common findings mid-market teams report after Defender-to-Falcon migrations:

Falcon’s alert volume was higher than expected, requiring further tuning in months four and five
Falcon Complete (where engaged) handled more routine work than anticipated, freeing the internal team for other priorities
Some custom reports used for compliance evidence took longer to rebuild against Falcon data than planned
Linux server coverage improved meaningfully compared to Defender — a common reason for the migration in the first place

Cost control watch-outs

CrowdStrike’s renewal pricing is known to increase meaningfully in years two and three. The negotiation you did at the initial purchase is the foundation for everything that follows — make sure it’s documented. Set a calendar reminder 120 days before renewal to begin the renegotiation conversation rather than letting it auto-renew.

Also watch for quiet module creep. Your CrowdStrike account team will pitch Falcon Identity Protection, Falcon Cloud Security, LogScale, and Falcon Exposure Management over the course of year one. Each of these may be genuinely valuable, but they’re not free, and the pricing stacking can surprise you. Budget for them deliberately rather than adding them reactively.

When a migration should be paused or aborted

Rare but worth naming. Pause or abort a Defender-to-Falcon migration if:

Ring 1 pilot exposes major performance impact you can’t tune away, and the affected user population includes critical business roles
Your cyber insurance carrier’s underwriting team flags an issue with the timing of the transition (mid-policy changes to named security controls sometimes create coverage questions)
A major security incident occurs during the migration period — do not try to execute a platform transition in the middle of active incident response
Licensing negotiations reveal the migration doesn’t achieve the cost outcome that justified it (run the three-year TCO before commitment, not during migration)

None of these are common. Most Defender-to-Falcon migrations, properly planned, execute cleanly on roughly this 90-day timeline.

Frequently asked questions

Can we do this faster than 90 days?

Physically yes, operationally no. The technical deployment can compress to 3–4 weeks. What can’t compress meaningfully is policy tuning, analyst retraining, and the observation period needed to trust the new platform. Organisations that compress the timeline usually spend months afterwards fixing what was missed. The 90-day structure isn’t conservative — it’s realistic for a migration that lands cleanly.

Do we need CrowdStrike Professional Services?

For most mid-market migrations, yes. The cost is meaningful (typically $20–60K depending on scope) but the value is high: deployment scripts, policy templates, migration best-practice reviews, and a named CrowdStrike contact for issues. Doing this migration entirely without professional services is possible but materially harder. Budget for it.

What about the July 2024 CrowdStrike incident — does it change how we deploy?

Yes. Staggered deployment rings are now table stakes. The rings structure in this playbook is designed around this — deploy Ring 1 for a minimum of a week before expanding to Ring 2, even if things look fine. The operational cost is small; the protection against a similar issue is significant. CrowdStrike itself has changed its sensor release process to support staggered adoption; use those controls.

Our Sentinel instance is ingesting Defender data. How do we keep Sentinel as our SIEM after migrating?

You don’t have to stop using Sentinel. Falcon has native Sentinel integration (via the Falcon Data Replicator connector). Alerts, detections, and raw telemetry from Falcon flow into Sentinel alongside your other data sources. Many mid-market teams using Falcon keep Sentinel as the SIEM rather than switching to LogScale — the Microsoft licensing economics for Sentinel often remain attractive even when endpoint EDR has moved elsewhere.

How do we handle endpoints that are offline during migration?

Remote workers, field devices, and rarely-connected laptops are genuinely tricky. Plan for a catch-up window: after the main migration, reserve 2–3 weeks specifically for chasing down endpoints that weren’t connected during the main deployment. Tools like Intune can deploy the Falcon sensor on first check-in; set this up early. Expect a small percentage (2–5% typically) of endpoints to require manual intervention.

What about BYOD or contractor devices?

Out of scope for most EDR deployments unless your policy already covers them. If you were covering BYOD with Defender, you probably weren’t — Defender’s BYOD story is limited in most mid-market configurations. Falcon’s is similarly limited. If BYOD coverage is a priority, it’s a separate initiative from this migration.

Should we notify our cyber insurance broker?

Yes. Some policies reference specific vendors or vendor categories in the application. A material change to your endpoint security control is the kind of thing that should be disclosed at renewal, and in some cases during the policy period. Your broker will know the right process. Don’t skip this — a claim denied because of undisclosed control changes is a bad way to discover you should have told them.

This playbook is a companion to our CrowdStrike Falcon vs SentinelOne Singularity vs Microsoft Defender for Endpoint comparison for mid-market. If you’re still evaluating whether the migration is the right call, start there. If you’re committed and need to execute, the 90-day structure above is the minimum viable plan.