Microsoft has confirmed that Data Loss Prevention file policy capabilities in Microsoft Defender for Cloud Apps are deprecated effective January 6, 2027. The capabilities move to Microsoft Purview, and Microsoft has indicated an automated migration tool will follow.
Five months is a comfortable runway for a migration that is genuinely mechanical. This one is not, and the gap between "a tool exists" and "the policies work" is where organizations lose control of their data protection posture.
Why the tool will not be enough
A DLP file policy is not configuration. It is a business rule expressed in configuration — a statement about which data matters, who may hold it, where it may travel and what happens when it does not. Those rules were written at a particular moment, usually by someone responding to a particular incident or audit finding, and in most organizations they have never been reviewed since.
A migration tool will translate the mechanics. It will not tell you that the policy scoped to a SharePoint site collection is now scoped to a site that no longer exists, that the file type list predates the organization's move to a different document format, that the notification address belongs to a person who left in 2023, or that three overlapping policies produce contradictory outcomes on the same file. Migration is the moment those problems surface, and it is far better to surface them deliberately than to discover them when a policy fails silently in production.
The migration sequence that works
Inventory first. Export every DLP file policy from Defender for Cloud Apps with its scope, conditions, actions, notification targets and — critically — its firing history over the last ninety days. That last column is the most informative one in the whole exercise. Policies that have never fired are either perfectly preventive or entirely miscalibrated, and the difference matters.
Classify by intent. Group the policies by the business rule they encode rather than by their technical configuration. Several policies frequently express the same underlying rule through different mechanisms, accumulated as different people addressed the same concern. Consolidating at this stage produces a smaller, more maintainable estate in Purview than a one-to-one translation would.
Validate against current reality. For each rule, confirm the scope still exists, the data classification still reflects how the organization handles that data, the action is still proportionate, and the notification reaches someone. This is the step that requires business input rather than platform work, which means it is the step that determines the timeline. Start it early.
Build in Purview and run parallel. Purview's DLP model is more capable and differently structured — it has a stronger relationship to sensitivity labels, broader coverage across endpoints and services, and a different policy evaluation order. Build the policies in Purview in audit mode, run them alongside the existing Defender for Cloud Apps policies, and compare outcomes for at least a full business cycle before enforcing. Discrepancies are informative in both directions.
Cut over, then decommission. Enforce in Purview, monitor, and only then retire the Defender for Cloud Apps policies. Do not decommission on the strength of a successful build.
The opportunity inside the deprecation
Purview's DLP is the better platform, and the migration is a forced opportunity to move to it properly rather than to replicate an older configuration inside it. The integration with sensitivity labels in particular allows policy to key off a label applied at creation rather than off content inspection at every evaluation, which is both more accurate and less expensive. Organizations that have deployed labels but never connected them to DLP enforcement can close that gap as part of this work.
There is also a licensing dimension worth checking. The 2026 packaging update moves additional Purview capability into the suites and introduces a Purview Suite bundle at 12.00 USD per user per month. Confirm what your current entitlement covers before scoping the target state, because organizations frequently discover during this exercise that they already own more of Purview than they are using.
How Lorexus engages
We run the policy inventory and firing analysis, facilitate the business validation of each rule, build and run the parallel Purview configuration, and manage the cutover. Where sensitivity labelling is incomplete, we treat that as part of the same programme rather than a prerequisite project. Book a free 15-minute call with our senior engineers.