Skip to main content

Architect workloads for Microsoft Fabric migration

Designing the target architecture of your data workloads in Microsoft Fabric is a critical step to ensure long-term performance, security, governance, and cost-efficiency. This article expands on the original Azure migration guidance and applies it to the context of Microsoft Fabric.

[!TIP]
Review previous phases: Classify workloads, Evaluate readiness, and Assess architecture to identify constraints, dependencies, and workload criticality.

Key Architecture Assumptions​

Fabric migrations differ from IaaS-based lift-and-shift efforts. However, some principles still apply:

  • Minimize disruption: Keep changes to data flow and structure minimal unless modernization is justified.
  • Right-size Fabric capacities: Use usage-based Fabric Capacity Unit planning (see Capacity units overview).
  • Plan for cutover events: Ensure data sync and model refreshes are designed with low-downtime switches.
  • Respect RPO/RTO expectations: Build recovery mechanisms via Fabric Pipelines and document failover needs.

Target Architecture in Fabric​

Core Principles​

PrincipleDescription
Medallion ArchitectureUse bronze-silver-gold layering in Lakehouses. See Lakehouse medallion design.
Domain-oriented designAlign Lakehouses and Warehouses to business domains. See Data mesh in Fabric.
DirectLake for Power BIUse DirectLake wherever latency and performance matter. See Power BI DirectLake overview.
Unified OneLakeConsolidate all data into a governed, single logical lake: OneLake architecture.
CI/CD & GitOpsIntegrate deployment pipelines with Azure DevOps: Fabric pipelines.

Architecture Checklist​

AreaFabric-specific Best Practices
LakehousesUse medallion pattern, separate domains.
WarehousesPrefer for SQL-first teams or ACID workloads.
EventstreamsUse for near real-time ingestion.
PipelinesCentral to orchestration, backups, transformations.
KQL databasesUse for telemetry, diagnostics, and large append-only workloads.
NotebooksLeverage for ingestion, enrichment, or ML prep.
Power BIUse DirectLake or DirectQuery for datasets.
GovernanceRegister all assets in Microsoft Purview. Apply labels and access controls.
SecurityApply RBAC, managed identities, row-level and object-level security.
ResilienceUse Fabric pipelines to implement backups, exports, and triggers. Document RPO/RTO.

Cost Management and FinOps​

Fabric's consumption-based pricing model requires deliberate cost planning:

SQL Workload Planning in Fabric​

When migrating SQL-based solutions into Fabric Lakehouses or Warehouses:

Advanced Design Considerations​

  • Confidential computing: Use Customer-managed keys and enable Purview integrations.
  • Sovereignty compliance: For regulated environments, implement sovereign landing zones
  • AI integration: Use Fabric Notebooks or Copilot integration for intelligent workloads
  • Cross-domain communication: Design eventstreams and shared semantic models carefully to maintain separation of concerns

Rearchitect When…​

Reevaluate architecture pre-migration if:

  • Current workloads suffer from technical debt
  • Performance or resilience SLAs are unmet
  • Domain refactoring is needed for long-term agility
  • Cost modeling in Fabric is unfavorable in current design

Use the Well-Architected Framework to validate designs.

Final Recommendations​

  • Validate all workloads against the Fabric governance model
  • Create a workload map aligned to capacity units and domains
  • Set up Fabric monitoring from day one
  • Register all assets in Purview and apply data classifications
  • Define FinOps chargeback logic and capacity boundaries

[!NOTE] Use the Fabric Adoption Accelerator for templates, training, and landing zone automation.

Contributors