Migrate Defender for Cloud Apps file policies to Purview DLP before 2027

Microsoft Defender for Cloud Apps file policies retire on 6 January 2027, and any file policy that you haven't recreated in Microsoft Purview by then stops being enforced. Move detection-and-response policies to Purview data loss prevention (DLP) policies and labeling policies to Purview auto-labeling policies: use the built-in DLP to Purview migration tool for SharePoint and OneDrive DLP policies, rebuild everything else by hand, validate in simulation mode, then enable the Purview policies and disable the originals.

Who this is for and what you will have at the end

This guide is for security and compliance administrators who use Defender for Cloud Apps file policies to find sensitive files in SharePoint, OneDrive or connected SaaS apps and act on them: alerts, removing sharing, quarantine or applying sensitivity labels.

At the end you will have:

• An inventory of every file policy, classified by what replaces it.
• A mapping of each condition and governance action to its Purview equivalent, with the gaps called out.
• SharePoint and OneDrive policies migrated with the tool, and the rest rebuilt manually.
• A staged cutover with simulation, pilot and decommissioning steps.

What is retiring and what stays

Auditing and reporting for these policies also move from the Defender portal to the Purview portal. If you already built Purview DLP policies on the Instances location, rebuild them in the matching app location too.

Prerequisites

• Licensing: Microsoft 365 E5 or Microsoft 365 E5 Compliance, or an equivalent standalone Purview DLP licence. The migration tool requires E5 or Information Protection and Governance licensing. According to MC1417993, customers without the required Purview licences can contact their Microsoft account team about a no-cost offer of Purview E5 Information Protection & Governance, limited to the functionality they used in Defender for Cloud Apps.
• Purview roles: membership of Compliance Administrator or Compliance Data Administrator.
• Defender roles: Cloud App Security Administrator to review file policies; Security Administrator to view them in the migration tool.
• Environment: the migration tool is available to commercial cloud customers in production environments, not government or sovereign clouds.
• App connectors: for Box, Dropbox, Google Workspace or Salesforce, the existing Defender for Cloud Apps app connector must stay connected.

Step 1: Inventory your file policies

1. In the Microsoft Defender portal, go to Cloud apps > Policies > Policy management.
2. Set the Type filter to File policy.
3. For each policy, record the name, target apps, content inspection method (Data Classification Service, regular expression or other), sensitive information types or labels, context filters (sharing level, file type, user groups, folders) and governance actions.
4. Classify it:
   • DLP detection and response: detects sensitive content and takes protective action. Becomes a Purview DLP policy.
   • Auto-labeling: applies or removes sensitivity labels. Becomes a Purview auto-labeling policy.
   • Both: becomes two Purview policies.

Keep screenshots or exports of each configuration; you'll need them for validation and for the audit trail when you delete the originals.

Step 2: Map conditions and actions

Purview policies are structured differently: one policy contains several rules, each with its own conditions and actions, and labeling is a separate policy type. Purview also offers simulation mode, which file policies never had.

Conditions

Governance actions

Flag every policy that uses File ID, folder scoping, trash, link expiry or ownership transfer. Those need a design decision, not just a migration.

Capacity isn't a constraint in the other direction: Defender for Cloud Apps allows 50 file policies per tenant, while Purview allows 10,000 information protection and governance policies and 600 DLP rules per tenant.

Step 3: Migrate SharePoint and OneDrive DLP policies with the tool

1. In the Microsoft Defender portal, go to Cloud apps > Policies > Policy management and select the All policies tab.
2. Select Migrate on the retirement banner. The DLP to Purview migration wizard opens.
3. Select policies. Policies are grouped under Can migrate, Partial migration and Cannot migrate. Expand Notes to see why, select the policies to move, and select Next.
4. Review payload. Check each policy's Verdict, open Show payload, copy it for your records, read any warnings about fields that need manual attention, and select Migrate.
5. Migration in progress. Keep the window open until it finishes. Closing it early can create incomplete policies in Purview.
6. Migration complete. Check that each row shows Created in Purview and note the source policy and rule GUIDs.

In Purview, under Data loss prevention > Policies, each migrated policy is named [Migrated] <original policy name> (1P DLP). A source policy that covered both SharePoint and OneDrive becomes two policies, one per location. New policies are created in Test with notifications mode and show Sync in progress until deployment finishes. Migration doesn't delete or disable the original file policy.

To list the migrated policies and their mode from Security & Compliance PowerShell:

Import-Module ExchangeOnlineManagement
Connect-IPPSSession -UserPrincipalName admin@contoso.com
 
Get-DlpCompliancePolicy |
    Where-Object { $_.Name.StartsWith('[Migrated]') } |
    Format-Table Name, Mode

Step 4: Rebuild the policies the tool can't move

DLP policies

1. In the Microsoft Purview portal, select Data loss prevention > Policies > Create policy.
2. Choose a matching template or Custom policy.
3. Scope it to the same locations: SharePoint sites and OneDrive accounts for Microsoft 365 content.
4. Add conditions from the Step 2 table. Recreate regular expressions as custom sensitive information types first.
5. Add actions and user notifications from the action table, and enable incident reports with the right recipients.
6. Save it in simulation mode.

Example: a file policy that finds externally shared files with credit card numbers, notifies the owner, removes external users and alerts becomes one DLP policy with Content contains > Sensitive info types > Credit Card Number and Content is shared from Microsoft 365 > with people outside my organization, the action Restrict access > Block only people outside your organization, a notification to the user who last modified the content, and an incident report to the compliance team.

Auto-labeling policies

1. In the Microsoft Purview portal, select Information protection > Auto-labeling > Create auto-labeling policy.
2. Choose the same sensitive information types or conditions, and the same sensitivity label.
3. Scope it to SharePoint sites and OneDrive accounts, adding specific sites where the file policy was narrower.
4. Run it in simulation, review the matched items, then turn it on.

Auto-labeling labels new and changed files. To label sensitive files already at rest, run an on-demand classification scan for the same sensitive information types.

Non-Microsoft apps

Purview DLP for Box, Dropbox, Google Workspace and Salesforce is in preview and rolls out in phases, so check availability in your tenant first. These policies:

• Need the app connected to Defender for Cloud Apps with an app connector.
• Must use the Custom policy template; the Financial, Medical and health and Privacy templates don't support these locations.
• Can include several non-Microsoft apps, but not together with SharePoint, OneDrive, Exchange, Fabric or Devices in the same policy.
• Use advanced DLP rules only, with conditions and actions that vary by app.
• Don't support policy tips or user overrides.

Step 5: Set up file quarantine if you used quarantine actions

File quarantine for SharePoint and OneDrive is in preview. Configure the quarantine location in DLP settings before you use the action. When a rule matches, Purview removes permissions and sharing links, moves the file to the admin-controlled quarantine site, and leaves a .txt tombstone file with your message at the original location.

Know its behavior before you rely on it:

• It applies only to files created or modified after the policy is turned on, unlike block actions, which apply to all files in scope.
• Restore is manual: move the file back, delete the tombstone, and reconfigure sharing. Only the latest version comes back.
• A restored file isn't quarantined again by the same rule.
• Up to 200,000 items per tenant are processed in 24 hours, and files with paths longer than 350 characters may not be quarantined.

Step 6: Validate and cut over

1. Run each Purview policy in simulation while the file policy is still active, and compare matches. Check the sensitive information types, confidence levels and scope.
2. Enable enforcement for a pilot group of users or sites.
3. Turn the Purview policy on for everyone:

Set-DlpCompliancePolicy -Identity '[Migrated] Externally shared PCI (1P DLP)' -Mode Enable

4. In the Defender portal, set the original file policy to Disabled. Don't delete it yet. Equivalent enforcing policies in both products conflict, so do this as soon as the Purview policy is on.
5. Monitor, then delete the disabled file policy after validation.

-Mode accepts Enable, Disable, TestWithNotifications and TestWithoutNotifications.

Verify

Also confirm that the number and scope of Purview policies match your inventory, that every sensitive information type and label is covered, and that each file policy is either disabled or documented as having no equivalent.

Troubleshooting

The DLP policy doesn't match the files the file policy found. The sensitive information type confidence level is too high or a site is out of scope. Lower the confidence level and check the locations.

Too many false positives. Raise the confidence level and add keyword lists to custom sensitive information types.

Matches appear but nothing is enforced. The policy is still in test or simulation mode. Turn it on after validation.

No alerts. Incident reports aren't enabled on the rule, or recipients are missing.

Auto-labeling doesn't apply labels. The label isn't published to users, or the simulation is still running.

A policy sits under Cannot migrate. It uses configuration the tool doesn't support yet. Rebuild it manually in Step 4.

Some rows in the completion table aren't Created in Purview. Note the affected source policies, check the Status column, and rerun the wizard for just those policies.

The Migrate banner is missing. Refresh the portal; it may have been dismissed. Confirm you're in a commercial production environment.

A quarantined file has no tombstone. Its path was longer than 350 characters, so the quarantine action wasn't applied.

Checklist

• File policies inventoried and classified as DLP, auto-labeling or both.
• Gaps (File ID, folder scope, trash, link expiry, ownership transfer) documented with a replacement design.
• SharePoint and OneDrive DLP policies migrated with the tool and reviewed.
• Auto-labeling and non-Microsoft app policies rebuilt manually; Instances location policies moved to app locations.
• File quarantine location configured where quarantine actions were used.
• Each Purview policy validated in simulation, piloted, then enabled.
• File policies disabled after the Purview policy is on, and deleted after validation.
• Everything finished well before 6 January 2027.

References

• Migrate file policies to Microsoft Purview
• Learn about DLP file quarantine for SharePoint and OneDrive
• MC1417993: File policies in Microsoft Defender for Cloud Apps are retiring
• MC1429010: Retirement of the Instances policy location in Microsoft Purview DLP
• Get-DlpCompliancePolicy
• Set-DlpCompliancePolicy
• Connect to Security & Compliance PowerShell