Microsoft Dynamics 365 Blog Posts & Articles by DynaTech Systems

Upgrading to Microsoft Fabric: Migration From Synapse & BYOD

Written by DynaTech Systems | Dec 26, 2025 3:38:19 PM

Synapse and BYOD were built for yesterday’s analytics demands. As data volumes, refresh cycles, and reporting dependencies scale, these environments become harder to govern, costlier to run, and slower to adapt. Microsoft Fabric eliminates that fragmentation by centralizing storage, compute, pipelines, modeling, and BI into one unified platform.

For organizations that depend on consistent, high-performance analytics, the shift to Fabric is now a structural necessity. DynaTech guides this transition with a migration approach that maps your current pipelines, warehouses, security model, and reporting layers into a streamlined Fabric architecture built for speed, control, and predictable cost.

1. Assessment & Planning: Establishing the Real Baseline

Before any migration begins, the organization must map its current data estate with precision. Synapse and BYOD deployments can be highly customized, so a thorough technical assessment prevents surprises downstream. 

Key assessment checkpoints include:

Inventory of the Current Data Landscape

  • All data storage locations — data lakes, SQL pools, warehouses, BYOD exports, external tables
  • ETL/ELT pipelines, Data Factory jobs, Synapse pipelines, or custom orchestration scripts
  • Data marts and reporting models used by BI teams
  • Security layers — RBAC, service principals, managed identities, data-level restrictions
  • Governance setups, retention policies, lineage tools, and auditing systems

This inventory helps map which assets move directly, which require re-engineering, and which need to be retired.

Workload Classification

Fabric supports a wide spectrum of workloads, so each category must be clearly identified: 

  • Batch ETL and scheduled pipelines
  • Streaming or near real-time data ingestion
  • BI reporting, dashboards, semantic models
  • Machine learning or Spark-based transformations
  • Ad-hoc querying and data exploration
  • High-concurrency workloads with many user sessions

This classification determines which Fabric components (Lakehouse, Warehouse, Data Engineering, Data Factory, Real-Time Analytics) should be used.

Target Architecture Definition

For each current asset, define its destination within Fabric: 

  • BYOD exports → OneLake shortcuts, Lakehouses, Fabric Data Warehouses 
  • Synapse notebooks → Fabric Data Engineering notebooks 
  • Data flows → Fabric Data Factory pipelines 
  • BI datasets → Fabric semantic models 
  • Governance → Fabric roles, domains, and item-level security

This architectural blueprint prevents inconsistent environments and sets expectations for data teams.

This unified OneLake-centric design aligns closely with modern lakehouse patterns such as the Medallion Architecture in Microsoft Fabric, which helps enterprises standardize ingestion, transformation, and analytics layers.

Migration and Cutover Strategy

A major decision:

Do you run the old and new systems in parallel, or switch at once?

Most organizations adopt a phased cutover:

  • Stand up Fabric components
  • Conduct pilot workloads
  • Migrate reports
  • Redirect pipelines
  • Decommission Synapse or BYOD after stabilization

This minimizes risk and business disruptions.

2. Setting Up the Fabric Environment

Once the plan is established, the next step is provisioning and preparing Fabric for incoming workloads.

Selecting the Right Fabric Capacity SKU

Fabric pricing is based on capacity units (CUs) under SKUs like F2, F4, F8, F16, F32, and beyond. 

Selection depends on:

  • Number of daily pipelines
  • Size of datasets
  • BI model refresh frequency
  • Type of workloads (ETL-heavy, BI-heavy, or warehouse-centric)
  • Expected concurrency
  • Real-time or streaming requirements

Most mid-sized organizations begin with F4–F8, while larger data teams or heavy engineering workloads may need F16 or higher.

Configuring OneLake and Governance

Fabric centralizes all storage inside OneLake, so the primary setup involves:

  • Defining domains and workspaces
  • Configuring permissions, roles, and lineage settings
  • Creating shortcuts for external ADLS locations if needed
  • Setting up secure networking and compliance rules

Replacing multiple storage layers with OneLake drastically reduces fragmentation.

Rebuilding or Migrating Pipelines

Fabric offers multiple paths:

  • Spark-based transformations through Data Engineering
  • Low-code dataflows through Data Factory
  • Traditional ETL pipelines using mapping or Power Query
  • Orchestration with Fabric pipelines

During migration, teams often streamline redundant pipelines, improving performance and governance.

Reconstructing Warehouses and Semantic Models

Fabric Warehouses support T-SQL, scalable compute, and seamless Data i with Power BI.

Data models and semantic layers are recreated to ensure:

  • Consistent measures
  • Business logic alignment
  • Better performance during refresh
  • Simplified security and access control

Workload Testing

Before data flows are redirected:

  • Validate ingestion consistency
  • Stress-test SQL query performance
  • Test concurrency with multiple BI users
  • Confirm that dashboards and reports render accurately
  • Ensure streaming workloads run without latency issues

This step prevents go-live bottlenecks.

3. Data Migration & Validation

Historical and incremental data migration must be handled systematically.

Full Data Load into OneLake

Data is typically migrated through: 

  • Bulk copy operations
  • Multithreaded Spark ingestion
  • External table imports
  • Shortcuts for existing ADLS folders

Teams must ensure schema alignment, partition consistency, and metadata correctness.

Redirecting ETL and Dataflows

Once historical data lands: 

  • All new ingestion runs through Fabric pipelines
  • Old pipelines remain in read-only or standby mode
  • BI models begin sourcing from Fabric, not Synapse or BYOD

Comprehensive Validation

Validation checks include:

  • Row counts and aggregation checks
  • Schema and datatype consistency
  • Performance benchmarking
  • Security and permission accuracy
  • Lineage visibility

Only after this verification is the system ready for cutover.

4. Cutover & Go-Live

The transition to Fabric requires careful coordination.

Freezing Legacy Pipelines

Synapse pipelines or BYOD exports are paused or run in parallel temporarily.

Migrating Reports and BI Models

Power BI datasets, dashboards, paginated reports, and metrics shift to Fabric semantic models.

User Training and Enablement

Teams must learn: 

  • Fabric workspace navigation
  • Using Lakehouses and Warehouses
  • Working with pipelines and notebooks
  • Governance, retention, and best practices

Decommissioning Legacy Systems

Once Fabric is stable: 

  • Synapse SQL pools can be removed 
  • BYOD exports can be discontinued 
  • Data lake storage accounts can be simplified or retired 
  • Compute costs immediately drop 

This is where organizations begin seeing the financial advantage.

Many organizations adopt Fabric at this stage because it is already outpacing Synapse in the modern data landscape, especially for unified governance, real-time analytics, and BI consolidation.

5. Monitoring & Optimization

Ongoing Optimization Areas

  • Right-sizing Fabric SKU based on real usage
  • Scheduling pipeline runs more efficiently
  • Archiving cold data to cheaper storage tiers
  • Continuous governance reviews
  • Improving semantic models for BI performance

Reserved capacity discounts help long-term cost management if workloads are stable.

6. Hybrid or Co-Existence Strategy

Some organizations cannot migrate fully in one step.

Hybrid Approach Options

  • Keep certain high-volume workloads in Synapse temporarily
  • Use shortcuts to reference existing ADLS data
  • Migrate BI models first, heavy data pipelines later
  • Run parallel systems during peak operational periods

This gives teams flexibility while maintaining data integrity.

Microsoft Fabric Pricing Overview (2025)

Microsoft Fabric uses a capacity-based pricing model built on Fabric Capacity Units (CUs). Instead of paying separately for compute engines (Spark, SQL, Data Factory, Real-Time Analytics, Fabric Power Bi), Fabric consolidates everything under one capacity. Storage is billed separately through OneLake.

Below is a clear breakdown of how pricing works in 2025, what components you actually pay for, and what organizations should account for during budgeting.

1. Fabric Compute Pricing (Capacity Units – CUs)

Fabric offers multiple SKUs—F2, F4, F8, F16, F32, F64, and higher—each representing increasing compute throughput for pipelines, SQL workloads, notebooks, machine learning, BI refreshes, and real-time processing. 

Approximate Pay-As-You-Go (PAYG) monthly pricing looks like this:

Key points:
  • Capacity runs everything in Fabric—warehouses, pipelines, Spark, notebooks, KQL… all compute draws from the same pool.
  • Capacity can be scaled up or down, making cost management predictable.
  • When workloads are light, Fabric allows pausing/resuming capacity on PAYG to optimize spend.

2. Reserved Capacity (40–45 percent cost reduction)

For predictable workloads (24x7 ETL, BI, SQL analytics), reserved commitment is significantly cheaper.

Approximate examples:

  • F2 Reserved: ~ $156 / month (vs $263 PAYG)
  • F4 Reserved: ~ $315 / month
  • F8 Reserved: ~ $630 / month
  • F16 Reserved: ~ $1,260 / month

Reserved capacity suits medium and large teams planning long-term adoption.

3. OneLake Storage Pricing

Storage is billed separately across regions, typically:

  • ~$0.023 per GB per month
  • ≈ $23 per TB per month

OneLake’s advantage is a single storage layer, meaning:

No duplicate copies for engineering, warehousing, real-time analytics, or Power BI. One data copy → multiple workloads.

Heavy users (IoT, telemetry, large historical data) must consider long-term storage growth.

4. User Licensing Requirements

User licensing differs based on the Fabric SKU you run:

Impact:

Smaller setups require both Fabric capacity + user-based licensing. 

Large enterprises (F64+) consolidate BI licensing under Fabric.

5. Estimated Total Cost for Medium Workloads

A mid-size analytics team using Fabric for: 

  • ETL
  • SQL Warehousing
  • BI / dashboards
  • Data science notebooks

might typically run on F8 or F16.

Estimated monthly cost:

  • $500 to $1,500 per month for compute (PAYG or Reserved)
  • $23 per TB per month for storage

This is significantly simpler—and often cheaper—than maintaining separate Synapse, ADLS, Data Factory, and Power BI Premium setups.

6. Autoscale Billing for Spark Workloads

Microsoft Fabric supports autoscale for Spark-based workloads, allowing compute to scale automatically during peak processing windows. When enabled, Spark jobs can temporarily consume additional capacity beyond the base SKU to complete heavy transformations or large batch loads faster.

Key considerations:

  • Autoscale is billed separately based on actual burst usage
  • It prevents pipeline failures during unexpected spikes
  • Ideal for seasonal loads, backfills, and large historical migrations
  • Can be disabled or capped to control spend

Autoscale helps balance performance and cost by avoiding permanent overprovisioning while still meeting processing deadlines.

7. Key Pricing Factors to Consider Before Migrating

  1. Workload Density
    Continuous ETL + heavy Power BI refresh + SQL queries → choose F16+.
    Intermittent/low workloads → F2/F4/F8 with pause/resume to save cost.
  2. Storage Growth
    Large data lakes or retention-heavy industries (pharma, manufacturing, BFSI) must model long-term storage projections.
  3. BI Consumption Pattern

    If most users only consume reports: 

    • F64+ reduces BI licensing cost significantly.
  4. Streaming & Real-Time Loads
    Real-time engines consume capacity differently. Teams should benchmark ingestion bursts before finalizing SKUs.
  5. Existing Synapse/BYOD Cost Footprint
    Fabric often reduces cost because:

    • No separate compute clusters
    • No siloed storage
    • No separate SQL pools
    • No dedicated Power BI capacity (unless large scale)

But large historical data migrations may temporarily increase storage and pipeline cost during transition.

Where DynaTech Fits Into Your Migration?

A Fabric migration is not just a lift-and-shift. It requires:

  • Data architecture redesign
  • Pipeline re-engineering
  • Governance modeling
  • BI restructuring
  • Storage and SKU optimization 
  • Phased cutover planning

DynaTech brings deep expertise in Dynamics 365, Synapse, BYOD, and Microsoft Fabric, along with migration accelerators that shorten timelines and reduce rework. Our teams help organizations restructure their analytics landscape, improve data reliability, and optimize cost using Fabric’s unified platform capabilities.

Final Takeaway

Moving from Synapse or BYOD to Microsoft Fabric is a chance to simplify your data environment, consolidate tools, reduce long-term cost, and build a single, well-governed analytics platform. With the right migration plan, Fabric becomes a stable foundation for analytics, engineering, and reporting at scale.

If your organization is planning this transition, DynaTech, as a Microsoft Solutions Partner, can help you execute it with accuracy and speed.

Visit our website to learn how we support end-to-end Fabric migrations.

Planning a structured migration from Synapse or BYOD to Microsoft Fabric? Explore DynaTech’s Microsoft Fabric migration services for enterprise-ready analytics.