Skip to main content

Classify Workloads for Microsoft Fabric Migration

Each step in your Microsoft Fabric adoption involves classifying data and workloads before migration activities begin. This classification process helps clarify requirements for governance, security, operations, and cloud-scale analytics — and sets the stage for a successful transition.

This activity assumes you've already defined a tagging strategy aligned with your Fabric Landing Zone architecture.

Classification Areas​

Workload classification in Microsoft Fabric should capture the following key aspects:

Data Sensitivity​

Data classification is essential to understanding security and governance implications. Fabric workloads often include business-critical data such as customer records, financial information, or regulated datasets (e.g. healthcare or energy sector data).

Work with your security and data governance teams early to define:

  • A process for identifying sensitive workloads in your Fabric migration backlog.
  • Governance baselines and Microsoft Purview labels aligned with your security policy.
  • Potential impact on workspace segmentation, workspace roles, and capacity-level encryption.
  • Testing scope and tools to validate classification across Lakehouses, Warehouses, and KQL DBs.

Example tags:

  • data.sensitivity = public | internal | confidential | restricted
  • data.regulation = GDPR | FERPA | HIPAA | FINMA

Mission Criticality​

Understanding the operational importance of a workload helps prioritize migration waves and informs SLAs for Fabric capacities and services.

Work with business and operations teams to define:

  • Classification for mission-critical workloads (e.g., analytics driving daily operations or regulatory reports).
  • Influence on deployment automation (e.g. dedicated capacity units for tier-1 services).
  • Requirements for 24x7 monitoring, alerting, or geo-redundancy.
  • Escalation paths and release processes post-migration.

Example tags:

  • criticality = unit-critical | mission-critical | important | legacy
  • support.tier = 1 | 2 | 3

Data Sovereignty​

If your organization is subject to regulatory or national data residency constraints, classify the workload’s sovereignty scope:

  • Are you required to store data only in EU or Swiss data centers?
  • Are Fabric capacities (Direct Lake, Warehouse, KQL DB) available in required regions?
  • Will you need Private Link or BYOK with Microsoft-managed keys or HSM-backed keys?

Ensure all sovereignty-sensitive workloads are labeled clearly for enforcement during deployment.

Example tags:

  • sovereignty.required = true
  • region.allowed = CH | EU | US-GOV

Organizational Classification​

Add organizational context that supports ownership, cost allocation, and support alignment.

  • Owning department or business unit
  • Support team or DevOps responsibility
  • Environment lifecycle (dev/test/prod)

Example tags:

  • business.unit = finance
  • environment = prod
  • owner = data-platform@contoso.com

Capturing Classification​

Ensure classification is captured in your migration tracking tool (e.g. Azure DevOps, Excel backlog, or GitHub issues). Link classification to workload tags so this metadata can flow into automated deployment processes.

Continue to the next section: Evaluate workload readiness.

Contributors