Microsoft Purview Data Map

Microsoft Purview Data Map (formerly Azure Purview) is the data governance side of the Purview brand. While Microsoft Purview compliance covers Microsoft 365 content (sensitivity labels, retention, eDiscovery), Data Map covers the broader data estate — Azure SQL, Synapse, AWS S3, Snowflake, on-premises SQL Server, file shares, Oracle, SAP, Power BI semantic models, and many more sources.

What Data Map does

The Data Map is a central catalogue that:

• Discovers data sources via scheduled scans.
• Classifies content using Microsoft's sensitive information types (SSN, credit card, custom) and custom classifications.
• Maps lineage — how data flows between systems (which Power BI report consumes which Synapse table that comes from which Data Factory pipeline).
• Catalogues business glossary terms and ties them to physical assets.
• Surfaces ownership — who's the steward of each data asset.
• Enables search across the data estate.

A data analyst searching for "customer revenue" finds the relevant Power BI report, plus the underlying tables, plus the lineage upstream to source systems — all with proper sensitivity classification and ownership.

How it relates to Purview compliance

The two are complementary but distinct:

• Purview compliance = "what's in my Microsoft 365 content, and how do I govern it?"
• Purview Data Map = "what data assets exist across my whole enterprise, and how are they classified and connected?"

A unified Purview portal at purview.microsoft.com surfaces both. Some signals cross over — sensitivity classifications discovered by Data Map can inform DLP and labelling decisions in Microsoft 365.

Connectors

Data Map ships connectors for most major data sources:

• Azure — Data Lake, Blob, SQL, Synapse, Cosmos DB, Data Factory, Databricks.
• Other clouds — AWS S3, AWS Redshift, GCP BigQuery, GCP Cloud Storage.
• Databases — SQL Server, Oracle, MySQL, PostgreSQL, Teradata, SAP HANA, SAP S/4HANA.
• SaaS / BI — Salesforce, ServiceNow, Power BI, Tableau.
• File systems — Azure Files, on-prem file shares (via self-hosted integration runtime).

Each scan inventories, classifies, and links lineage where possible.

When Data Map is the right tool

Data Map is most valuable for organisations with:

• A serious data estate — multiple databases, BI tools, lakes, warehouses.
• Data governance ambitions — knowing what data exists is the precondition for governing it.
• Compliance requirements — regulators wanting to see classification of sensitive data across the enterprise.
• Data democratisation goals — letting analysts find and reuse data without rebuilding things from scratch.

For smaller organisations whose data lives mostly in Microsoft 365 (SharePoint and OneDrive), Microsoft 365-side Purview compliance is usually enough; Data Map is overkill.

Pricing model

Data Map is licensed by scanned capacity units — pay for the volume of data being scanned and the frequency of scans. Costs scale with the size and breadth of the data estate.

For organisations with mature data engineering / data platforms teams, Data Map is increasingly the catalogue of choice. For Microsoft 365-only customers, it's a "future state" rather than a today problem.

Rollout that actually works

The catalogues that get used tend to be built in this order:

1. Stand up the account and connect one small, well-owned data source — a single Azure SQL database or one Data Lake container. Prove scanning, classification, and lineage end-to-end before adding breadth.
2. Pilot the business glossary. Pick 20 real terms the business already argues about (Active Customer, Net Revenue, Churn) and tie each to physical assets. This is what makes Data Map useful; without it, the catalogue is a searchable file system.
3. Onboard stewards, not scanners. Each domain (Finance, Sales, HR) needs a named steward accountable for the glossary and asset ownership within it. Broadening scans without stewards produces an unowned catalogue nobody trusts.
4. Add sources by domain. Bring in Power BI, then the domain's databases, then the Data Factory pipelines feeding them. Lineage becomes visible in a shape a user can reason about.
5. Cross-cloud last. AWS S3, GCP BigQuery, Snowflake are supported, but they need self-hosted integration runtimes and cross-cloud IAM. Delay these until the internal Azure estate is landed.

Skipping step 2 is the single most common cause of a Data Map deployment that quietly rots. Assets without terms are technical metadata; terms without assets are a wiki.

What Data Map does not do

• It is not a data lake or a data warehouse. It scans and catalogues; the actual data stays where it lives.
• It does not enforce access. Fine-grained access control still lives in the source system (Azure SQL, Snowflake, Fabric). Data Map surfaces who can grant access; it does not grant it.
• It does not replace DLP for Microsoft 365 content. Sensitive content in email and chat is Purview compliance territory.
• It is not free tier-friendly. The pricing model rewards a considered scope; broad scans of large lakes get expensive quickly.

Common wrong turns

• Turning on every connector at once. Scanning volume drives billing and creates a review backlog nobody works through. Add domains deliberately.
• Automatic classification without curation. Microsoft's out-of-the-box classifiers are good but not perfect. Every scan should route new suggested classifications to a steward, not auto-apply them.
• Skipping the collections hierarchy. Collections are how you scope permissions, ownership, and search. A flat catalogue with 10,000 assets and no collections is unnavigable.
• Treating Data Map as an IT project. The catalogue's users are analysts, data scientists, and business stewards. If the initial rollout involves no business stakeholders, adoption will be near zero.

Signals worth watching

• Cost analysis for the Data Map account — capacity units, scan durations, storage growth. Set an alert; the meter can run higher than expected once cross-cloud scans start.
• Uncatalogued asset count by domain — proxy for stewardship gap.
• Glossary terms with zero linked assets — either the term is real and needs mapping, or it should be retired.
• Search-to-request funnel — data requests originating from a catalogue search are the leading indicator that Data Map is doing its job.