What security architects need to know before, during, and after migrating file policies — including prerequisites, feature compatibility, side effects, licensing, cutover, and rollback.

Introduction

Microsoft is retiring file policies in Microsoft Defender for Cloud Apps (MDCA) on January 6, 2027, moving file-based data protection toward Microsoft Purview Data Loss Prevention (DLP) and auto-labeling.

For organizations that have relied on Defender for Cloud Apps to discover sensitive files, monitor external sharing, apply sensitivity labels, and perform file governance actions, this is more than a change of management portal.

It introduces architectural and operational questions:

Can every existing file policy be migrated?
Will the same sensitive information be detected?
Are all governance actions supported in Microsoft Purview?
Will users experience new restrictions?
What happens to existing files and encrypted documents?
Are additional licenses or costs required?
Do cloud app connectors remain necessary?
Can we restore the previous configuration if something goes wrong?

The answers depend on the existing policy design, workloads, licenses, and capabilities supported in the target environment.

In this guide, we’ll walk through a practical migration methodology, explain the technical risks, and establish the validation criteria needed for a controlled production transition.

Part 1 — Before Migration

1. Understand the Retirement Timeline

Microsoft has announced several milestones that directly affect migration planning.

Date	Change	Architectural impact
October 1, 2026	Creation of new MDCA file policies ends	New protection requirements should be designed in Purview
October 9, 2026	Disabled MDCA file policies can no longer be re-enabled	Legacy-policy rollback is no longer a reliable option
January 6, 2027	MDCA file policies retire	Remaining legacy file policies stop enforcing

The October 9 restriction is particularly important.

Once an MDCA file policy has been disabled, administrators should not assume it can be restored.

This changes the migration strategy: organizations need to validate replacement controls thoroughly before disabling existing protection.

The retirement applies to MDCA file policies, not the entire Defender for Cloud Apps product.

Other MDCA capabilities, such as cloud discovery, app governance, threat detection, and supported access or session controls, remain separate from this retirement.

Sources: Microsoft Learn migration guidance and Microsoft 365 Message Center notices MC1469552 and MC1483852.

2. Understand What Is Actually Moving

An MDCA file policy can combine several functions:

Detection: Identify files based on sensitive content, classification, metadata, or sharing characteristics.

Governance: Apply supported actions such as restricting sharing, quarantining files, or applying sensitivity labels.

Monitoring: Generate alerts and provide information for security investigations.

Microsoft Purview separates these functions into different policy capabilities.

Existing MDCA capability	Potential target
Sensitive information detection	Purview DLP
Sharing restrictions	Purview DLP, where supported
Automatic sensitivity labeling	Purview auto-labeling
Classification using sensitivity labels	Purview DLP conditions, where supported
File governance actions	Supported Purview actions; mapping required
File policy alerts	Purview DLP alerting and activity monitoring

A single MDCA file policy may require multiple replacement policies.

Likewise, some existing governance actions may not have identical equivalents.

Architecture principle: Migrate security requirements and outcomes, not simply policy names.

3. Perform a Current-State Assessment

Before opening the migration wizard, inventory every existing file policy.

Capture:

Policy name, description, and business owner.
Current status and priority.
Target application or workload.
Detection conditions and custom expressions.
Sensitive information types and thresholds.
Sensitivity label conditions.
Sharing and collaborator filters.
Exceptions and exclusions.
Governance actions.
Alert settings and recipients.
Business dependencies.
Recent policy activity.

For each policy, answer:

Why does this policy exist?

What security risk does it address?

Is it still required?

Who approves its replacement?

What happens if its protection disappears?

Policies with no owner or unclear purpose should be investigated rather than automatically migrated.

Recommended assessment deliverables

MDCA File Policy Inventory.
Business and Security Requirements Matrix.
Application and Connector Inventory.
Current Detection and Alert Baseline.
Migration Readiness Assessment.

4. Validate Licensing and Permissions

Microsoft documents specific prerequisites for migration.

Depending on the capabilities involved, these include Microsoft 365 E5, Microsoft 365 E5 Compliance, or qualifying standalone Purview licenses.

For the automated migration tool, Microsoft documents administrative requirements including Security Administrator access to review MDCA policies and Compliance Administrator access to create Purview policies.

Other supported Purview administrative role groups may be appropriate for manual policy configuration.

Licensing assessment

Before implementation, determine:

Which users or workloads require Purview DLP licensing.
Whether auto-labeling requires additional entitlements.
Whether third-party application protection introduces separate licensing or consumption requirements.
Whether the organization’s existing agreement covers the planned scenarios.
Whether preview capabilities are available in the tenant.

Do not assume that an existing MDCA license automatically covers every Purview feature.

For large environments, calculate the expected commercial impact before approving the target architecture.

Permission assessment

Apply least privilege.

Use the appropriate security and compliance administrative roles instead of assigning Global Administrator by default.

Deliverable: Licensing and Permissions Matrix.

5. Understand Automated Migration Support

Microsoft’s documented migration tool supports eligible SharePoint and OneDrive DLP file policies.

It does not currently support automated migration of:

Auto-labeling policies for Microsoft workloads.
DLP policies for non-Microsoft applications.
Auto-labeling policies for non-Microsoft applications.

The tool categorizes existing policies by migration readiness:

Classification	Meaning	Action
Can migrate	Supported for automated migration	Review and migrate
Partial migration	Some settings need attention	Complete configuration and validate
Cannot migrate	Unsupported for automated conversion	Redesign or recreate manually

This distinction is essential:

Purview supporting a security capability does not mean Microsoft’s migration tool can automatically convert the existing MDCA policy.

The migration tool also has environment restrictions. Microsoft documents support for commercial production environments rather than government or sovereign clouds.

Confirm current support before scheduling the migration.

6. Build a Policy Mapping Matrix

A policy mapping matrix is one of the most important migration artifacts.

MDCA policy example	Target design	Validation requirement
Detect credit card data in SharePoint	Purview DLP	Sensitive Information Type, confidence, thresholds
Detect confidential files shared externally	Purview DLP	Sharing conditions, exceptions, restrictions
Apply Confidential label to matching files	Purview auto-labeling	Label selection, encryption, precedence
Monitor sensitive files in Salesforce	Purview DLP for supported connected apps	Connector, application-specific conditions and actions
Alert on sensitive file exposure	Purview DLP alerting	Severity, routing, SOC workflow

For every source policy, record:

Source condition → Target condition → Source action → Target action → Compatibility → Test result.

Where exact functional parity is unavailable, document the gap and obtain approval for the alternative design.

Part 2 — Migration Risks and Side Effects

7. Protection Gaps During Cutover

A protection gap can occur when an existing MDCA policy is disabled before its Purview replacement is actively enforcing.

For example, a policy that previously restricted external sharing might be replaced by a Purview policy still operating in simulation mode.

The organization may see detection results without equivalent enforcement.

Mitigation: Validate the replacement and coordinate activation with legacy policy retirement.

8. Duplicate Enforcement

Microsoft warns that running equivalent MDCA and Purview policies simultaneously can cause enforcement conflicts.

Possible consequences include duplicated actions, unexpected file restrictions, or inconsistent operational results.

Mitigation: Compare policies in simulation where supported, then use a controlled cutover.

Do not rely on prolonged duplicate enforcement as a migration strategy.

9. Different Detection Results

MDCA and Purview policies may use different detection conditions and processing behavior.

For example, an MDCA custom expression might be replaced with a Purview Sensitive Information Type.

Even when both detect similar information, their results may differ.

Potential side effects include:

Increased false positives.
Reduced detection coverage.
Different match thresholds.
Changes to alert volumes.
Unexpected enforcement on legitimate documents.

Mitigation: Use a representative test dataset and compare detection outcomes before enforcement.

10. Governance Action Differences

Legacy MDCA governance actions may not have direct Purview equivalents.

Consider an MDCA policy that quarantines a sensitive file or removes external sharing permissions.

The replacement Purview policy may offer a different enforcement mechanism.

The resulting protection may be appropriate, but it is not necessarily identical.

Mitigation: Validate both the security outcome and the user experience.

Do not describe two controls as equivalent until their behavior has been tested.

11. Auto-Labeling and Encryption Risks

Automatic labeling can have persistent effects on documents.

For example, a policy may apply a Confidential label that includes encryption.

If the wrong label is applied, users or external collaborators may lose access.

Disabling the auto-labeling policy afterward does not necessarily remove the label or encryption already applied.

Mitigation:

Validate classification conditions.
Review label priority and encryption configuration.
Test supported simulation capabilities.
Confirm access for authorized users.
Document remediation procedures.

Treat encryption-related changes as high impact.

12. Existing Files vs. New Files

An important migration consideration is the difference between:

Existing content: Files already stored in SharePoint, OneDrive, or connected applications.

New or modified content: Files created or changed after deployment.

Different Purview features have different scanning and processing behavior.

For example, existing SharePoint and OneDrive content may require additional planning for on-demand classification and auto-labeling.

Mitigation: Test both historical and newly created files.

Do not assume that a new policy automatically reprocesses every document already stored in the environment.

13. SOC and Alerting Changes

Moving policy management can affect how security teams investigate incidents.

Potential changes include:

Alert locations.
Alert severity and metadata.
Investigation workflows.
Reporting dashboards.
Operational responsibilities.
Automated response processes.

Mitigation: Validate alerts and update SOC runbooks before retiring the legacy controls.

Historical MDCA activity should be retained according to the organization’s retention and audit requirements.

14. Third-Party Application Limitations

Microsoft Purview DLP supports selected non-Microsoft connected applications in preview, including:

Box.
Dropbox.
Google Workspace.
Salesforce.

Availability can vary by tenant.

These applications use MDCA connectors for supported Purview integration.

Microsoft documents important limitations for non-Microsoft connected app DLP policies:

Capability	Documented consideration
Simulation mode	Not supported
Policy tips	Not supported
User overrides	Not supported
Content Explorer	Not supported
Encrypted-file classification	Not currently supported
PDF classification	Not currently supported
Administrative units	Not supported for these policy locations
Policy locations	Cannot be combined with Microsoft 365 locations in one policy

These limitations materially affect migration planning.

For example, an organization relying on encrypted PDF inspection in a third-party application cannot assume equivalent protection will exist in the target preview capability.

Mitigation: Perform application-specific compatibility testing and document residual risks.

Source: Microsoft Purview DLP for non-Microsoft connected applications.

Part 3 — Migration Planning and Execution

15. Recommended Migration Phases

The following is an illustrative consulting plan. Durations depend on policy complexity, workload coverage, and organizational approvals.

Phase	Estimated duration	Main deliverable
1. Discovery and assessment	1–2 weeks	Current-state assessment
2. Architecture and mapping	1–2 weeks	Target architecture and policy mapping
3. Configuration and simulation	1–2 weeks	Configured policies and test evidence
4. Pilot and UAT	1–2 weeks	UAT report and sign-off
5. Production cutover	Several days–1 week	Cutover validation
6. Hypercare and optimization	1–2 weeks	Post-migration report

These phases can overlap where appropriate.

A simple SharePoint and OneDrive deployment may take less time. A multinational organization with numerous applications, complex policy conditions, and multiple business owners may require considerably longer.

16. Migration Wave Strategy

Avoid migrating every policy simultaneously.

A practical approach is:

Wave 1 — Monitoring-only policies

Start with lower-impact detection and alerting scenarios.

Wave 2 — Standard DLP enforcement

Validate restrictions, exceptions, and user notifications.

Wave 3 — Auto-labeling

Test classification, label behavior, and encryption.

Wave 4 — Complex policies

Address custom expressions, unsupported actions, and business-specific requirements.

Wave 5 — Third-party applications

Validate connectors, preview limitations, licensing, and application-specific enforcement.

Prioritize according to risk and the retirement deadline rather than assuming this order fits every organization.

17. Build a Migration Test Plan

A policy appearing in Purview does not prove that migration succeeded.

Test the expected behavior.

Test scenario	Expected validation
Sensitive information in SharePoint	Correct detection
Sensitive information in OneDrive	Correct detection
Confidential file shared externally	Expected enforcement
Approved external collaboration	Exceptions work
Unauthorized external sharing	Protection is applied
Encrypted document	Supported inspection and access behavior
Previously stored document	Expected data-at-rest coverage
Newly uploaded document	Expected policy processing
External-tenant sensitivity label	Supported recognition and conditions
False-positive sample	No unintended enforcement
Third-party connected application	Supported conditions and actions

For each test, document:

Test ID.
Application and workload.
Test data.
Expected result.
Actual result.
Evidence.
Pass/fail status.
Remediation owner.

For third-party applications without simulation support, use a tightly controlled test scope and documented test procedures.

18. Production Cutover Planning

Before cutover, confirm:

Required replacement policies exist.
Simulation or controlled testing is complete.
Business owners have approved the change.
SOC monitoring is ready.
Known feature gaps have been accepted.
The implementation team understands policy deployment behavior.
Alternative remediation controls are available.

During cutover, coordinate activation of Purview enforcement and retirement of corresponding MDCA policies.

Immediately afterward, validate high-risk scenarios such as sensitive external sharing and unauthorized access.

Because disabled MDCA file policies cannot be re-enabled under the announced restriction, treat the disablement decision as a controlled, potentially irreversible change.

19. Rollback and Remediation Planning

Rollback must be designed before migration.

A traditional rollback might involve disabling the new policy and restoring the previous policy.

That approach is no longer reliable for MDCA file policies because disabled policies cannot be re-enabled after the October 2026 restriction.

Instead, prepare a recovery plan covering:

Policy configuration: Preserve documented copies of the original conditions, actions, and exceptions.

Alternative controls: Identify supported Purview policies or other approved controls that can maintain essential protection.

Business disruption: Establish emergency procedures for unexpected restrictions.

Data remediation: Document how to address incorrect labels, encryption, permissions, and sharing changes.

Decision authority: Identify who can approve rollback or emergency remediation.

Validation: Confirm protection remains effective after corrective actions.

Importantly, disabling a Purview policy may stop future enforcement but does not necessarily undo changes already applied to files.

A rollback plan must therefore address both the policy configuration and the state of affected data.

Part 4 — After Migration

20. Do You Still Need MDCA Integration Settings?

After migrating file policies, administrators should review the Microsoft Information Protection settings in Defender for Cloud Apps.

Automatically scan new files for sensitivity labels

This is an MDCA-specific scanning setting.

It is not a general prerequisite for Microsoft Purview DLP.

Retain it only when supported MDCA scanning scenarios still require it.

Only scan labels from this tenant

This setting controls whether MDCA sensitivity-label scanning considers supported labels originating from external tenants.

It does not provide a global setting for Purview DLP.

If MDCA label scanning remains necessary, determine whether visibility into external classifications is required.

Inspect protected files

Protected-file inspection requires additional permissions.

Review the business justification and whether any remaining MDCA capabilities depend on those permissions.

Avoid removing permissions without assessing dependencies, but do not retain unnecessary privileged access.

Cloud application connectors

For supported non-Microsoft application integrations, Purview may continue using connectors configured in Defender for Cloud Apps.

Therefore, moving policies to Purview does not automatically eliminate MDCA connector dependencies.

21. Validate the Target Architecture

After migration, the intended management responsibilities should be clear.

Microsoft Purview Information Protection

Sensitivity labels.
Label publishing.
Supported auto-labeling.
Encryption configuration.

Microsoft Purview DLP

DLP policy definitions.
Sensitive information detection.
Supported enforcement.
Alerts and monitoring.

Microsoft Defender for Cloud Apps

Supported third-party application connectors.
Cloud discovery.
SaaS security and governance capabilities.
Remaining MDCA-specific integrations.

The objective is to avoid unnecessary duplication while preserving required protection coverage.

22. Post-Migration Validation Checklist

Before formally closing the migration project, verify:

Every source policy has a documented migration outcome.
Required protection controls have been recreated or migrated.
Unsupported conditions and actions have been addressed.
Policy scope and exceptions are correct.
Detection and enforcement tests have passed.
Encryption and auto-labeling behavior is validated.
Existing-file and new-file scenarios are covered.
Required cloud app connectors remain operational.
SOC alerting and investigation workflows are updated.
Legacy MDCA file policies have been retired appropriately.
Unnecessary permissions have been reviewed.
Business owners have approved the final implementation.
Operational documentation and support procedures are complete.

23. What Microsoft Security Professionals Are Concerned About

Public practitioner discussions and independent analysis have highlighted several recurring concerns.

Licensing and cost

Administrators have questioned whether protecting large volumes of data in third-party applications could introduce significant additional costs.

This should trigger a formal licensing and consumption assessment rather than reliance on anecdotal pricing examples.

Feature parity

Independent analysts have raised concerns that Purview replacements may not reproduce every MDCA condition or governance action.

This reinforces the need for detailed capability mapping.

Migration complexity

Organizations may have numerous inherited policies without clear owners or documented security requirements.

The migration provides an opportunity to rationalize those policies instead of recreating unnecessary complexity.

Operational disruption

Security teams may need to adapt to new investigation workflows, alerts, and reporting experiences.

These concerns should be addressed through pilot testing and operational handover.

Community feedback provides useful planning signals, but Microsoft documentation and tenant-specific testing must determine the final technical design.

24. Recommended Enterprise Migration Deliverables

A professional migration engagement should produce evidence across the entire project lifecycle.

Workstream	Deliverables
Assessment	Current state, policy inventory, dependencies
Architecture	Target design, policy mapping, licensing matrix
Risk management	Risk register, compatibility gaps, remediation plan
Implementation	Configured policies, migration evidence
Testing	Simulation, UAT, detection comparison
Transition	Cutover plan, operational procedures, remediation strategy
Closure	Validation report, runbooks, final sign-off

These deliverables support governance, auditability, operational continuity, and future optimization.

Conclusion

Migrating Microsoft Defender for Cloud Apps file policies to Microsoft Purview is not simply a technical configuration exercise.

It is a transition between data protection architectures, with implications for detection accuracy, enforcement behavior, licensing, cloud application integrations, user experience, and security operations.

The retirement timeline makes preparation urgent, particularly because disabled MDCA file policies can no longer be re-enabled.

Organizations should begin with a comprehensive assessment, map every required security control, identify unsupported capabilities, test replacement policies, and coordinate a controlled production cutover.

The most important questions are:

What protection do we have today?

What will change after migration?

Which capabilities are not equivalent?

What happens if the new policies behave unexpectedly?

How will we demonstrate that security coverage has been maintained?

By answering these questions before implementation, security teams can reduce migration risk and build a more sustainable Microsoft Purview data security architecture.

A successful migration is not measured by how many policies are moved. It is measured by the security outcomes preserved, the risks controlled, and the confidence established through validation.