Most teams don’t face a binary choice between Microsoft Purview and a new catalog. The real decision has three honest answers: coexist with Purview exactly as it runs today, extend it with a context layer that adds cross-platform catalog, lineage and business context, or replace its catalog and discovery front end while Information Protection stays exactly where it is. Microsoft Fabric, Unity Catalog and Purview all play a real role in that decision, and which path fits depends on the estate you actually run, not on whichever vendor is telling the story.
The second path, extend, is the most common pattern in mixed Microsoft estates. Most teams keep Purview for DLP and sensitivity labels, and add a context layer as the cross-platform catalog, lineage and business-context layer on top. All three paths get the same honest treatment below, including coexist, where the right answer is to change nothing at all.
| Field | Value |
|---|---|
| Category | Microsoft Purview role decision: coexist, extend or replace |
| Guide type | Decision framework, not a vendor shortlist |
| Typical decision timeline | Weeks to a quarter, a scoping decision rather than a full procurement cycle |
| Key stakeholders | Data and analytics leadership, data governance leads, enterprise architects |
| Budget consideration | Purview’s Data Governance capability is billed separately from any Microsoft 365 tier; never assume it’s free because it’s licensed |
| Core decision criteria | Estate heterogeneity, lineage depth needed, business-user adoption of Purview today, AI and Copilot grounding requirements, whether Purview’s gaps are bounded or actively failing |
Why the Purview decision isn’t actually binary
Deciding what to do with Microsoft Purview is not a yes-or-no question, and no Tier-1 source answers it as one. Microsoft has no reason to recommend a third-party context layer on top of its own governance product, and the closest analyst frameworks are gated behind paywalls. No disinterested analyst or vendor argues full replacement should be the default path; practitioners who describe replacing Purview’s catalog role are doing it for a narrow slice of their own estate, not “replace by default.” The honest starting position stays that most estates keep Purview for something.
What Purview does well deserves serious treatment first. According to a Forrester Consulting Total Economic Impact study commissioned by Microsoft (2025), a composite Purview customer realized $3.0 million in benefits against $633,000 in costs over three years, a 355% ROI, alongside a 30% drop in breach likelihood and a 75% cut in investigation time. That’s a genuine business case for staying on Purview, not a strawman to knock down later.
Atlan’s position here is coexistence and extension, not a replacement pitch. Microsoft Fabric runs the workloads, Purview enforces Microsoft-native policy, and a context layer adds the cross-platform catalog, lineage and business-context layer that survives whichever platform mix an estate runs next. A reader who lands on coexist has exactly as much reason to trust that answer as one who lands on replace.
Who this decision involves
This usually sits with data and analytics leadership, data governance leads and the enterprise architects who own the Fabric and Purview estate. How a context layer fits a data governance team’s workflow covers how those roles split once a path is chosen.
What “replace” does and doesn’t mean
Replace, used loosely, invites a false assumption: that moving off Purview’s catalog means moving off its security controls too. It doesn’t. Information Protection, meaning sensitivity labels, encryption and DLP, is a separately licensed Microsoft 365 product that no path here touches, as the replace section below covers in full.
What are the three paths for Purview: coexist, extend or replace?
Every real pattern a Purview estate runs collapses into exactly three paths, each a genuinely different answer to what happens to Purview day to day.
Coexist means Purview keeps doing what it already does, discovery, DLP, sensitivity labels and Information Protection, with at most a narrow point integration. Nobody’s job changes, and that’s the point.
Extend means Purview keeps enforcement, specifically DLP, sensitivity labels and Information Protection, while a context layer becomes the cross-platform catalog, lineage and business-context layer reaching past Purview’s own estate, the plurality case in the patterns reviewed here: Purview’s reach stops at the Microsoft boundary, and most mixed estates need a layer that doesn’t.
Replace is the narrowest, most deliberate path: the catalog, discovery and glossary front end moves to a context layer because that front end is actively failing adoption, not just imperfect. Information Protection stays on Microsoft 365 regardless, a separately licensed product nobody has a reason to touch just because the catalog changed.
| Path | What stays on Purview | What a context layer adds or changes | Best fit when |
|---|---|---|---|
| Coexist | Everything: discovery, DLP, sensitivity labels, Information Protection | Nothing changes; at most a narrow point integration | Purview-only Microsoft estate, adoption is working, no AI-grounding need yet |
| Extend | DLP, sensitivity labels, Information Protection | Cross-platform catalog, lineage and business-context layer added on top | Mixed estate (Snowflake, Databricks, Fabric), AI or Copilot grounding need, Purview’s catalog UX isn’t the problem |
| Replace | Information Protection only: DLP, sensitivity labels | Catalog, discovery and glossary front end moves to the context layer | Purview’s discovery layer is actively failing adoption, not just imperfect |
Why “replace” never means replacing Information Protection
Information Protection, the sensitivity-label, encryption and DLP layer, is licensed and billed separately from Purview’s Data Governance capability, meaning Unified Catalog and Data Map together, and it stays in place under every path here, including replace. Microsoft Purview Unified Catalog: features, pricing and limits covers the full three-way split, a distinction most public coverage of this decision skips.
The question worth asking isn’t whether to replace Purview. It’s which path matches the estate in front of you, because conflating them turns a scoping decision into a false ultimatum.
When should you coexist with Purview as-is?
Coexist is the right call more often than vendor content admits, and the real test is whether Purview is already working for the estate you run today, not whether a context layer could theoretically add something to it.
Five signals point toward staying on Purview as-is:
- The estate is Microsoft-only or Microsoft-dominant, with no material Snowflake, Databricks, AWS or GCP footprint to reach beyond Fabric and Purview.
- Business users already trust and use Purview’s catalog to find and validate data, not just the central data team.
- There’s no near-term AI or Copilot-grounding requirement that needs business context from outside the Microsoft estate.
- Purview’s known gaps, such as scanning entire workspaces file by file or lineage that doesn’t fully reach Unity Catalog, are real but bounded, not blocking an active initiative. What Microsoft Purview governs, and where its coverage stops is worth checking in detail before calling a gap bounded rather than blocking.
- The Forrester-measured business case for Purview described above is winning the internal budget conversation on its own merits, without a competing catalog in the picture.
Atlan has nothing to add in this scenario, and that’s worth saying as plainly as the opposite case gets said later: a context layer only earns its place once a real, specific gap shows up, not because every estate eventually buys one. Evaluating a governance platform for Fabric: 20 questions to ask gives a fuller checklist for testing whether Purview’s setup is actually meeting the bar.
Signals you should re-check this later, not never
Coexist is a snapshot, not a permanent state. The two signals most likely to flip it are a new cross-platform workload landing outside Fabric, and an AI or Copilot initiative needing grounding context Purview’s own estate doesn’t reach. Purview’s AI security controls versus business context for agents is worth revisiting the day either shows up, because this decision rarely changes before the trigger does.
When should you extend Purview with a context layer?
Extending Purview is the most common pattern among mixed Microsoft estates in the evidence gathered here: Purview’s enforcement layer stays untouched while a layer gets added that reaches further than Purview’s own estate does.
Five signals point toward extend:
- Real, ongoing workloads sit on Snowflake, Databricks, BigQuery, Redshift or Azure SQL alongside Fabric, not just a pilot.
- Lineage needs to cross platform boundaries Purview’s reach stops short of. Practitioners describe Purview’s lineage extraction from Unity Catalog as limited, and Fabric’s own lineage depth depends on connector and workspace role, detailed in proving Fabric and Power BI lineage in a proof of value and end-to-end column-level lineage for Power BI.
- AI or Copilot agents need business context spanning more than Fabric and Purview cover. Microsoft’s own AI surface, from Copilot Studio agents to Fabric data agents to Azure AI Foundry, raises questions like who governs agent-created Fabric items. Fabric IQ, compared against Work IQ and Foundry IQ in where Microsoft put agent grounding, names none of them Purview.
- Purview’s catalog-DLP split works fine on its own terms; the gap is breadth and cross-platform lineage, not enforcement.
- Business users trust Purview for what it covers, but non-Microsoft assets still need a front door Purview was never built to provide.
Most teams keep Purview for DLP and sensitivity labels, and add a context layer as the cross-platform catalog, lineage and business-context layer on top. That’s the pattern that shows up most once an estate grows past Microsoft-only.
Extend is real integration work, not a toggle. Atlan syncs with Purview through open APIs and metadata sync, scoped and directional rather than a native, bidirectional connector. Atlan’s Fabric and Power BI connectors are read-only and never write access changes back to source systems, keeping RBAC exactly where it lives, a boundary context-layer role-based access control is built around, not against.
In context-layer terms, what gets added is a cross-platform catalog, lineage and business-context layer that a single-stack estate doesn’t need and a multi-cloud one can’t do without.
What “extend” requires in practice, not a magic sync
Every public claim about running a catalog on top of Purview tends to skip the mechanism. Synchronizing two catalogs, keeping glossary terms and lineage consistent across both, is a recognized architectural problem, not a configuration checkbox. Teams that plan extend as weeks of integration work, not a weekend sync job, end up with one that actually works.
When should you replace Purview’s catalog front end, and what never gets replaced?
Replace is narrowly scoped, and naming that scope precisely is the point. It’s the catalog, discovery and glossary front end that moves, driven by specific, bounded pain, never an inevitability and never Information Protection.
Five signals point toward replace:
- The estate has grown mixed or multi-cloud enough that Purview is a minority player in it, not the Microsoft-dominant case extend assumes.
- Purview’s discovery and catalog layer is actively failing adoption, not just imperfect. Teams describe routing around it to Unity Catalog or another tool for day-to-day discovery.
- Purview functions mainly as an add-on business catalog, rather than an active, integrated one teams work inside daily.
- Over-scanning and workflow friction, such as scanning every file individually or access requests that don’t close the loop, block a real initiative, not just annoy.
- The team has already reached its own conclusion that Purview’s discovery and UX layer isn’t working for them, before ever reading a framework like this one.
Weighed against all five signals: Microsoft’s own consolidation of Fabric’s security-insight reporting into OneLake catalog’s Govern tab (the Purview Hub view it replaced was retired by end of January 2026) moved a reporting surface, not Purview’s DLP and sensitivity-label engine, which cuts against assuming Purview’s role shrinks on its own. That’s exactly why replace belongs here as a deliberate choice driven by specific pain, not a bet on Purview fading away.
What never moves: Information Protection, meaning DLP, sensitivity labels and encryption, is a separately licensed Microsoft 365 product that no scenario here moves. Microsoft Purview Unified Catalog: features, pricing and limits breaks down how that product sits apart from Data Map and Unified Catalog.
There is also no one-click migration. No documented bulk-export-and-map utility exists, and no public case study backs a clean, single-step swap. The realistic path is overlay first, then selectively retire: stand the context layer up alongside Purview’s catalog, prove it against real workflows, then wind down the parts that aren’t earning their place. That’s a phased project measured in a quarter or more, not a button.
What never moves to a context layer: Information Protection, DLP, sensitivity labels
Catalog, discovery and glossary can move. Information Protection, meaning sensitivity labels, encryption and DLP, stays on Microsoft 365 under every path, including this one, a distinction nearly every public take on this decision skips. Microsoft data governance tools: what are your options? covers where Purview sits relative to the rest of the Microsoft governance stack, Microsoft Purview and Atlan is the direct head-to-head for readers who want it, Microsoft Purview alternatives is the place to go for a vendor shortlist, and the best data catalogs for Microsoft Fabric specifically narrows that shortlist to the Fabric-native case. Treat replace as a narrow, deliberate swap of a daily front end, not a wholesale exit from the Microsoft governance stack, and the decision stops being an ultimatum and starts being a scoping exercise.
How do you decide which path fits your estate?
The self-diagnostic sequence below is five questions, not a five-step procurement process, because this is a scoping decision, not a multi-vendor RFP.
Step 1: Map your estate. Microsoft-only, or does it include Snowflake, Databricks, BigQuery or other platforms alongside Fabric?
Step 2: Rate Purview’s adoption among business users as working, partial, or routinely routed around. This single rating separates coexist from the other two paths better than any technical criterion here.
Step 3: Name your lineage-depth requirement. Inside Fabric, don’t conflate the two mechanisms: general report, page and visual lineage through the Fabric connector needs Scanner API access disabled and Viewer role or higher, while column- and measure-to-page lineage through the Power BI connector needs Contributor role or higher, since Viewer produces nothing there. End-to-end column-level lineage for Power BI and proving Fabric and Power BI lineage in a proof of value walk through this in full.
Step 4: Check for an AI or Copilot-grounding requirement needing business context beyond Purview’s estate. Why AI agents need an enterprise context layer covers why this criterion increasingly decides the outcome alone.
Step 5: Classify Purview’s known gaps as bounded but real, or actively failing. This criterion separates extend from replace, and answer it last since it’s the easiest to get wrong in isolation.
This sequence routes back to the sections above rather than repeating them. The goal isn’t a score. It’s finding the one step where the honest answer still feels uncertain.
Purview decision scorecard: which path fits your estate
This table turns the five criteria above into a single, reusable self-scoring reference. It’s vendor-neutral and meant to be marked up against your own estate, not read once and set aside.
| Criterion | Coexist signal | Extend signal | Replace signal |
|---|---|---|---|
| Estate heterogeneity | Microsoft-only | Mixed, Microsoft-dominant | Mixed or multi-cloud, Purview is a minority player |
| Lineage depth needed | Single-platform, shallow | Cross-platform, Purview’s reach stops short | Cross-platform and Purview’s own UX is the blocker |
| Business-user adoption of Purview | Working | Working for enforcement, not discovery | Actively routed around |
| AI or Copilot-grounding need | None near-term | Yes, beyond Purview’s estate | Yes, and discovery itself is the gap |
| Nature of Purview’s gaps | None material | Bounded but real | Actively failing |
Score each row for your own estate before treating any path as decided, and watch for three red flags regardless of score: treating replace as a reason to also move DLP or sensitivity labels, when it never is; assuming a one-click migration exists, when it doesn’t; and assuming OneLake catalog alone closes a cross-platform business-context gap, when it’s scoped to Fabric, not the full estate. Context layer evaluation criteria is the fuller framework this scorecard summarizes.
One row is deliberately missing: Information Protection. DLP and sensitivity labels never appear as a scoring criterion, because they don’t change under any path, coexist, extend or replace alike. A scorecard that includes Information Protection as something to decide on wasn’t built around this estate’s actual options.
What should you ask before committing to a path?
These are the questions worth asking before signing anything, because they surface whether extend or replace is real integration work or a vendor-glossed sync.
Questions about your own estate
Which systems hold the business context Purview can’t reach today, and how many actually matter day to day? Is the adoption problem discovery and user-experience, or enforcement? That second question is the fork between extend and replace. Metadata tooling build versus buy evaluation criteria helps if the question turns into a build-versus-buy one.
Questions for Microsoft
Will Fabric’s own OneLake catalog absorb more of Purview’s role over time, or should the estate plan around Purview remaining the system of record? The Purview Hub retirement cited earlier moved a reporting view, not Purview’s policy engine, so planning around a shrinking role that hasn’t actually started shrinking is a common, avoidable mistake.
Questions for a context-layer vendor
What exactly syncs with Purview, in which direction, and how is that scoped? A vendor who can’t answer precisely is glossing the mechanism. What does migration actually look like: a phased overlay, or a claimed one-click import? A credible vendor says phased. Context layer TCO: build versus buy versus bundle is worth reading before that conversation starts.
How does Atlan approach the coexist, extend or replace decision?
Most existing coverage of this decision leans quietly pro-Purview, because it comes from Microsoft’s own community, or reads like a competitor’s customer story dressed up as a framework. Neither gives a reader a structured, three-path way to diagnose their own estate.
Atlan is the context layer for AI: a model-agnostic, cross-platform catalog, lineage and business-context layer meant to outlast whichever platform mix an estate runs next. It natively connects Snowflake, Databricks, BigQuery, Redshift, Synapse, Azure SQL, ADLS, ADF and Power BI, reading metadata, not business data, through a self-deployed runtime that keeps credentials inside the customer’s own perimeter. What is context engineering and how to implement an enterprise context layer for AI cover what that looks like for a team that decides to extend, and how to build an AI agent harness covers the AI-grounding side.
Forrester named Atlan a Leader in The Forrester Wave: Enterprise Data Catalogs, Q3 2024, with the highest scores in Current Offering and Strategy, and a Leader and Customer Favorite in The Forrester Wave: Data Governance Solutions, Q3 2025, the highest possible score in 15 criteria. Atlan also advanced from Visionary to Leader in the 2026 Gartner Magic Quadrant for Data and Analytics Governance Platforms. None of that recognition is specific to a Purview decision. This framework stands on the criteria above, not a name-dropped logo, because the right path differs by estate, including the estates where the honest answer is coexist and Atlan has no role to play at all.
The one question that decides coexist, extend or replace
The question was never whether to replace Microsoft Purview. It’s which of three honestly-scoped paths, coexist, extend or replace, fits the estate you run today, and that answer can change the day a new platform lands or an AI initiative needs context Purview’s reach doesn’t cover. The nuance worth repeating: replace never touches Information Protection. DLP, sensitivity labels and encryption stay on Microsoft 365 under every path, because they’re a separately licensed product, not a casualty of a catalog decision. Estates that treat this as a scoping exercise, revisited as conditions change, end up with a cleaner answer than estates that treat it as a one-time, permanent commitment made under a vendor’s deadline.
FAQs about deciding Purview’s role
1. Is Microsoft Purview being replaced by Microsoft Fabric’s OneLake catalog?
No. Microsoft retired the Purview Hub view inside Fabric’s navigation by the end of January 2026, moving its sensitivity-label-coverage and DLP-status reporting into OneLake catalog’s own Govern tab. That consolidates where Purview’s insights are reported, not Purview’s underlying policy engine: DLP, sensitivity labels and compliance scanning are still a Purview capability, and OneLake catalog’s reach stays scoped to the Fabric estate while Purview’s extends enterprise-wide and across clouds.
2. Can you run a third-party catalog on top of Microsoft Purview?
Yes, through open APIs and metadata sync, scoped to what’s confirmed today rather than a universal claim. This isn’t a native Purview connector, and it isn’t bidirectional by default. Verify any specific sync claim against current product documentation rather than taking it on faith.
3. If we keep Purview for DLP and sensitivity labels, what exactly still needs a separate catalog?
Cross-platform catalog coverage, lineage and business context beyond what Purview’s estate reaches. That gap is the core of extend: Purview keeps enforcing policy, while a context layer covers the discovery and business-context work that stops at Purview’s Microsoft-native boundary.
4. Why pay for a separate catalog if Purview is already bundled into our Microsoft 365 license?
Purview’s Data Governance capability, meaning Unified Catalog and Data Map, is never bundled into any Microsoft 365 tier. It’s billed separately as Azure consumption regardless of license. “Bundled” describes Information Protection’s compliance features, not the catalog and governance layer this decision is actually about.
5. How do we migrate metadata, glossary terms and classifications off Purview without starting over?
Phased, not all at once. Stand the new catalog up alongside Purview, prove it against real workflows, then selectively retire the parts that aren’t earning their place. No one-click migration exists, and no vendor claim to the contrary should survive a reference check.
6. What are the main limitations of Microsoft Purview for data lineage?
Practitioners report Purview’s lineage extraction from Unity Catalog is limited, and that Fabric’s own page- and visual-level lineage depends on connector choice, Scanner API settings and workspace role, not a single default. Treat these as diagnostic signals for when to extend, not a takedown of Purview.
7. Should we use Purview for multi-cloud data governance across AWS, GCP and Snowflake?
Purview can scan many non-Microsoft sources, so presence isn’t the real question. Depth is: how far lineage reaches, how business context carries across platforms, and how much of that needs a dedicated cross-platform layer rather than Purview’s own scanning reach.
8. How does Unity Catalog relate to Microsoft Purview? Do we need both?
Different layers, not competitors. Unity Catalog governs Databricks-native technical metadata, while Purview governs enterprise-wide business discovery and compliance. Many teams run both at once, itself evidence for treating this as a coexist-or-extend decision rather than a single-vendor choice.
Sources
- Microsoft Purview delivered 30% reduction in data breach likelihood, Microsoft Security Blog
- The Forrester Wave: Enterprise Data Catalogs, Q3 2024, Atlan
- The Forrester Wave: Data Governance Solutions, Q3 2025, Atlan
- Atlan named a Leader in the 2026 Gartner Magic Quadrant for D&A Governance Platforms, Atlan
- Microsoft Purview overview, Microsoft Learn
- Microsoft Purview Information Protection, Microsoft Learn
- Microsoft Purview service description, Microsoft Learn
- Billing in Microsoft Purview Data Governance, Microsoft Learn
- Fabric governance and lineage, Microsoft Learn
- Explore Fabric security insights in the OneLake catalog - Govern tab, Microsoft Fabric Community
- r/databricks: “We expected Purview to be our Databricks data lineage frontend. It wasn’t.”, Reddit
- r/MicrosoftFabric: “Purview”, Reddit
- r/MicrosoftPurview: “Purview experience with Fabric”, Reddit
- r/dataengineering: “Are we missing the point of data catalogs?”, Reddit
- r/dataengineering: bi-directional sync between catalogs, Reddit
