Migrate Defender for Cloud Apps File Policies to Microsoft Purview
File policies in Defender for Cloud Apps retire January 6, 2027. This guide covers inventory, condition mapping, capability gaps, and a staged rollout to Purview DLP and auto-labeling — with portal mockups at every step.
📁 Migrate File Policies from Defender for Cloud Apps to Microsoft Purview
File policies in Defender for Cloud Apps are retiring January 6, 2027. This guide walks you through inventorying your existing policies, mapping capabilities to Purview DLP and auto-labeling, handling the gaps, and rolling out in stages without a protection gap.
⏰ What's Being Retired and Why It Matters
Microsoft is retiring file policies in Defender for Cloud Apps on January 6, 2027. File-based data protection is consolidating into Microsoft Purview — which has a broader enforcement surface, simulation mode, and a 10,000-policy limit vs. Defender's 50.
Defender for Cloud Apps continues to provide SaaS app discovery, posture management, and threat detection — only the file-based DLP enforcement moves to Purview. The migration affects two types of policies:
Policies that detect sensitive content and take protective action — restrict access, quarantine, notify, alert. Recreate these as Purview DLP policies under Data Loss Prevention.
Policies that apply sensitivity labels based on content inspection. Recreate these as Purview auto-labeling policies under Information Protection.
✅ Prerequisites
Licensing
You need Microsoft 365 E5 or Microsoft 365 E5 Compliance, or an equivalent standalone Microsoft Purview DLP license. Without this, Purview DLP for SharePoint/OneDrive (the primary migration target) is not available.
Role Requirements
| Task | Required Role | Where to assign |
|---|---|---|
| Review existing file policies in Defender | Cloud App Security Administrator | Microsoft Defender portal → Settings → Roles |
| Create/manage Purview DLP policies | Compliance Administrator or Compliance Data Administrator | Microsoft Purview → Roles & scopes → Role groups |
| Create auto-labeling policies | Compliance Administrator or Information Protection Administrator | Microsoft Purview → Roles & scopes → Role groups |
📋 Step 1 — Inventory Your Existing File Policies
Before you create a single Purview policy, document every file policy you have. The migration is a mapping exercise — you need to know exactly what each policy does before you can recreate it.
| Policy name | Type | Apps | Severity | Status |
|---|---|---|---|---|
| Externally shared PII | File policy | SharePoint, OneDrive | High | Active |
| Credit card — quarantine | File policy | OneDrive | High | Active |
| Apply Confidential label | File policy | SharePoint, OneDrive | Medium | Active |
| Public sharing — internal docs | File policy | SharePoint | Medium | Active |
Export your file policy inventory
Go to security.microsoft.com → Cloud Apps → Policies → Policy management. Set Type filter to File policy. Open each policy and document: name, description, target apps, content inspection method, SITs or labels, sharing level filters, user group filters, and governance actions.
Categorize each policy
Label each policy as either DLP detection/response (detects content and takes protective action) or Auto-labeling (applies a sensitivity label based on content). Policies that both detect and label need to become two separate Purview policies.
Flag gap policies
Any policy using user quarantine, file ID filtering, folder-level scoping, remove specific collaborator, or expire shared link has no direct Purview equivalent. Note these separately — they need a workaround via Power Automate or SharePoint admin.
⚠️ Capability Gaps You Need to Plan Around
Most file policy capabilities map cleanly to Purview. A handful do not. Know these before you start rebuilding policies, or you will discover the gaps after you disable Defender and have no enforcement.
🔍 Condition Mapping Reference
Use this table when recreating policy conditions in Purview DLP. The detection engine underneath (Data Classification Service) is the same — the condition syntax is what changes.
| Defender for Cloud Apps Condition | Purview DLP Equivalent | Parity |
|---|---|---|
| Access level: External or Public | Content is shared with people outside my organization | ✅ Equivalent |
| Access level: Internal | Content is shared only with people inside my organization | ✅ Equivalent |
| Content inspection: SIT / DCS preset | Content contains → Sensitive info types (same SIT list) | ✅ Equivalent |
| Content inspection: custom regex | Custom sensitive information type (create first, then add as SIT condition) | ✅ Equivalent |
| Sensitivity label condition | Content contains → Sensitivity labels | ✅ Equivalent |
| Select user groups | User groups condition in DLP rule | ✅ Equivalent |
| File name / file extension | Document name contains / File extension is | ✅ Equivalent |
| Minimum violation count | Instance count (min and max) per SIT | ✅ Equivalent |
| Collaborators (entire organization) | Collaborators (domain) — use org domain name | ⚠️ Partial |
| Parent folder filter | SharePoint site-level scoping only | ⚠️ Partial |
| Created / last modified date | Document created / modified date — SharePoint/OneDrive only | ⚠️ Partial |
| File ID | No equivalent | 🚫 No equivalent |
🛡 Step 2 — Migrate DLP Detection & Response Policies
For each file policy categorized as DLP detection/response, create a Purview DLP policy. Walk through the wizard once for your highest-priority policy — it's the same pattern for all of them.
Open the Purview DLP policy wizard
purview.microsoft.com → Data loss prevention → Policies → Create policy. Choose Custom policy to define conditions manually (most migrated policies won't match a built-in template exactly).
Set locations — SharePoint and OneDrive
Select SharePoint sites and OneDrive accounts to match the original file policy scope. If your policy targeted specific site collections or user groups, scope accordingly. You cannot scope to subfolder — use the SharePoint site as the closest equivalent.
Define content conditions
Add the same SITs, sensitivity labels, and sharing conditions as your original policy. If the original policy used a minimum violation count, set the instance count range to match. If it used a custom regex, create the custom SIT first, then add it here.
Configure protective actions
Map each governance action from your Defender policy to its Purview equivalent. Restrict access replaces remove public/external access. Admin quarantine is available natively. User quarantine and file deletion require Power Automate flows.
Enable simulation mode — do not enforce yet
Set the policy to Simulation mode before turning it on. Run it for at least 7 days alongside your active Defender file policy. Compare the DLP matches in Activity Explorer against the alerts in Defender to confirm equivalent detection.
🏷 Step 3 — Migrate Auto-labeling Policies
File policies that applied sensitivity labels become Purview auto-labeling policies under Information Protection — not DLP. The configuration path is different, but the detection engine is the same.
Create an auto-labeling policy
purview.microsoft.com → Information protection → Auto-labeling → Create auto-labeling policy. Choose the SITs or conditions matching your file policy's content inspection rules.
Select the same sensitivity label
Choose the exact label your Defender file policy applied. If your policy applied "Confidential - PII," select that same label here. The label must already be published to users in an Information Protection label policy.
Set scope — SharePoint sites and OneDrive
Select the same SharePoint sites and OneDrive accounts as your original file policy. Add specific sites if the policy was scoped to particular groups. Remember: folder-level scoping is not available — scope to the parent site.
Run simulation first — review matches before enabling
Purview auto-labeling simulation shows you exactly which files would be labeled, with a sample to review. Confirm the matches are correct before turning on automatic labeling. A false-positive label applied at scale is very hard to roll back.
| Policy name | Label applied | Status | Simulation matches |
|---|---|---|---|
| Apply Confidential-PII (migrated from MDCA) | 🏷 Confidential - PII | Simulation | 1,840 files |
| Apply Confidential-Financial | 🏷 Confidential - Financial | On | — |
🚀 Step 4 — Staged Rollout
Run Purview policies in simulation alongside active Defender policies. Never disable Defender until Purview has proven equivalent detection over at least one week of real traffic.
| Stage | Action | Validation | Duration |
|---|---|---|---|
| 1 — Simulate | Create Purview DLP + auto-labeling in simulation mode. Keep Defender policies active. | Compare simulation match counts to Defender alert counts for the same content types. | 7–14 days |
| 2 — Pilot | Turn on Purview enforcement for a small pilot group (20–50 users). Defender still active for everyone else. | Confirm actions are correct (restrict access, notifications, quarantine), no false positives, user experience as expected. | 7–14 days |
| 3 — Full enforcement | Expand Purview policies to all users. Disable (not delete) Defender file policies. | Monitor Purview alerts for 30 days. Confirm no protection gaps. Compare to historical Defender alert baseline. | 30 days |
| 4 — Decommission | Delete disabled Defender file policies after 30-day validation period. | Final audit: all policies migrated, Purview providing equivalent or better coverage. | After Stage 3 |
🔎 Step 5 — Verify and Decommission
Compare policy inventory
Count your Purview DLP policies + auto-labeling policies against your original Defender file policy inventory. Every Defender policy must have at least one Purview policy covering the same content and scope.
Cross-check SITs and labels
Every sensitive information type and sensitivity label used in your Defender policies must appear in at least one Purview policy condition. A missing SIT means a class of sensitive content is now unprotected.
Disable Defender policies — do not delete yet
In the Defender portal, edit each migrated file policy and set state to Disabled. Keep the disabled policies for 30 days as a reference in case you need to compare configurations or roll back.
Delete after 30-day validation
Once you've confirmed Purview policies are providing equivalent protection for 30 days, export screenshots of each Defender policy configuration for your records, then delete them from the Defender portal.
📊 Post-Migration Monitoring
After migration, alerts and activity data move to Purview. Know where to find each data type — your security team's workflow will need updating.
| What you need | Where to find it after migration |
|---|---|
| DLP policy matches and alerts | purview.microsoft.com → Data loss prevention → Alerts |
| File activity history | Purview → Data loss prevention → Activity explorer |
| Auto-labeling matches | Purview → Information protection → Auto-labeling → [policy] → Items to review |
| Security incidents | Microsoft Defender portal → Incidents & alerts (still here) |
| Activity | Policy | User | File | Action taken |
|---|---|---|---|---|
| DLP rule match | Externally shared PII | a.cohen@contoso.com | HR-Contract-2026.docx | Blocked |
| DLP rule match | Externally shared PII | m.levi@contoso.com | Customer-data-export.xlsx | User override |
| Auto-label applied | Apply Confidential-PII | System | Employee-list-2026.xlsx | Labeled |
🔧 Troubleshooting
| Issue | Cause | Resolution |
|---|---|---|
| DLP policy not matching expected files | SIT confidence level too high, or location scope is missing sites | Lower the confidence level in the SIT condition. Confirm all SharePoint sites are in scope — site collection URLs must match exactly. |
| Too many false positives | SIT is too broad or missing supporting context | Add keyword proximity lists to the SIT. Increase confidence level. Use corroborative evidence groups in the rule condition. |
| Auto-labeling not applying labels | Label not published to users, or simulation still running | Confirm the label is published in a label policy. Check simulation status — policy must be set to On, not simulation, for automatic labeling to happen. |
| Alerts not generating | Incident reports not enabled in the DLP rule, or alert recipients not configured | Open the DLP rule → Incident reports section → Enable "Send an alert to admins" → Add recipients. Check the Alerts tab for suppressed alerts. |
| Policy matches but action not enforced | Policy still in simulation/test mode | Turn the policy on. Simulation mode generates reports but does not enforce any action. |
| New Purview policy not enforcing after 24h | Policy propagation delay to SharePoint/OneDrive | Policy propagation to SharePoint takes up to 24 hours. Check policy status shows "On" and wait the full propagation window before escalating. |
✅ Migration Checklist
Phase 1 — Inventory- Export all file policies from Defender (Cloud Apps → Policy management → filter Type: File policy)
- Document: name, apps, content inspection method, SITs/labels, sharing filters, user groups, governance actions for each policy
- Categorize each policy as DLP detection/response or Auto-labeling
- Flag gap policies: user quarantine, file ID filter, folder scoping, remove specific collaborator, expire shared link
- Verify Purview role assignments (Compliance Administrator or Compliance Data Administrator)
- Confirm M365 E5 or E5 Compliance licensing
- Create custom sensitive information types for any custom regex patterns from Defender file policies
- Create Purview DLP policies for each DLP detection/response file policy — in simulation mode
- Create Purview auto-labeling policies for each labeling file policy — in simulation mode
- Build Power Automate flows for any gap actions (user quarantine, remove collaborator, expire link)
- Run simulation for minimum 7 days — compare match counts against Defender alert baseline
- Pilot enforcement for 20–50 users — confirm actions, notifications, user experience
- Expand enforcement to all users
- Disable (not delete) Defender file policies — note date
- Monitor Purview Activity Explorer for 30 days post-cutover
- Export/screenshot each disabled Defender file policy configuration for archive
- Delete Defender file policies after 30-day validation period
- Update security operations runbooks and alert routing to reflect new Purview alert locations
- Run on-demand classification scan to backfill labels on existing content at rest
Migration reference: learn.microsoft.com/en-us/defender-cloud-apps/migrate-file-policies-to-purview