Data platform modernization
Modernize selected Snowflake data and analytics workloads on Microsoft Fabric with a migration plan built around your estate—not a one-size-fits-all conversion.
Assess tables, Iceberg, SQL, Snowpark, Snowpipe, Streams, Tasks, security, and BI dependencies. Then determine what to mirror, copy, refactor, retain, or retire as data moves toward OneLake, Fabric Warehouse, and Lakehouse.
Object support, compatibility, cost, and timing depend on the source estate and current Microsoft Fabric capabilities.
Migration patterns
A Snowflake estate rarely has one migration mechanism that fits every object. Combine supported replication, explicit copy, refactoring, and coexistence where appropriate.
Replicate supported Snowflake managed and Iceberg tables into OneLake for analytics and coexistence. Mirroring is not a full warehouse or code conversion.
Views and materialized views synchronize every 12 hours. External, transient, temporary, and Dynamic Tables are not supported by the current documented mirroring feature. Validate current Microsoft limitations before design.
Use explicit pipeline-based extraction for selected tables or queries, scheduled full or incremental loads, and supported change-data-capture scenarios.
Snowflake CDC in Copy job is documented as Preview in the source draft. It requires table change tracking, appropriate privileges, and retention longer than the job interval. Confirm current status and destination support.
Unload snapshots or query results to supported cloud storage, then ingest files into OneLake and create Fabric-native Delta tables.
Validate file format, partitioning, compression, null handling, timestamps, semi-structured data, encryption, and storage access as part of the proof of concept.
Move workloads in waves. Keep specialized workloads in Snowflake where appropriate while Fabric takes on approved data, engineering, and analytics responsibilities.
Define ownership, freshness expectations, security boundaries, consumer routing, cost monitoring, and criteria for long-term coexistence or retirement.
Workload mapping
These are assessment starting points, not guaranteed one-to-one conversions. Confirm current feature support and test target behavior for your workload.
| Snowflake component | Potential Fabric destination or approach | Migration consideration |
|---|---|---|
| Snowflake managed tables | Mirrored database, Lakehouse Delta tables, or Warehouse tables | Choose mirroring or copy/rebuild based on freshness, transformation, and serving needs. |
| Iceberg tables | Mirrored database with the required storage connection, or an ingestion pattern | Validate underlying storage access and Iceberg compatibility. |
| Views and materialized views | Mirrored views or rebuilt Fabric SQL / curated tables | Mirrored objects synchronize every 12 hours; verify whether that meets freshness requirements. |
| Dynamic Tables | Fabric pipelines, notebooks, and managed Lakehouse or Warehouse tables | Not supported by current Snowflake Mirroring; rebuild dependency and refresh behavior. |
| Virtual warehouses | Fabric capacity and workload allocation | Compute and billing models differ; benchmark representative workloads. |
| Snowpipe, Streams, and Tasks | Data Factory pipelines, Copy jobs, notebooks, or retained services | Recreate triggers, change capture, schedules, retries, dependencies, and idempotency. |
| Snowpark Python / Java / Scala | Fabric notebooks and Spark, or another supported runtime | Review APIs, packages, runtime, authentication, and execution semantics; refactor and test. |
| Roles, grants, masking, and row access policies | Microsoft Entra groups, Fabric roles, SQL permissions, and model security | Rebuild and test effective access; source security does not transfer automatically. |
| Power BI consumers | Fabric Warehouse, Lakehouse, or mirrored endpoint | Reassess semantic models, Direct Lake eligibility, DirectQuery, refresh, and security. |
Target architecture
The target may combine Fabric experiences. Select them based on data products, query patterns, transformation needs, engineering skills, governance, and measured operating costs.
Consider for SQL-centric relational marts, curated enterprise data, and governed SQL serving. Validate Snowflake SQL and procedural behavior against Fabric's supported T-SQL surface.
Consider for Spark engineering, Delta Lake tables, semi-structured data, and multi-stage transformations. Review runtime, libraries, data types, and downstream consumers.
Consider for supported Snowflake data replication into OneLake and coexistence. Its SQL analytics endpoint is read-only for replicated data, and mirroring does not convert the warehouse logic.
Delivery approach
Inventory accounts, databases, schemas, managed and Iceberg tables, views, SQL, procedures, UDFs, warehouses, ingestion, orchestration, security, BI consumers, and dependencies.
Decide which objects should be mirrored, copied, unloaded, re-platformed, redesigned, retained, or retired. Record compatibility questions and business priorities.
Select Lakehouse, Warehouse, mirrored database, or a combination. Configure connections, identity, security, OneLake, deployment, monitoring, and a pilot that tests real data types and dependencies.
Migrate approved data in waves. Refactor Snowflake SQL, stored procedures, UDFs, Snowpark, Dynamic Tables, Streams, Tasks, and Snowpipe behaviors into suitable Fabric patterns.
Compare schemas, row counts, aggregates, business measures, incremental behavior, SQL results, reports, security, and performance against agreed acceptance criteria.
Plan the final load, consumer redirection, rollback conditions, support handoff, and stabilization. Review measured Fabric capacity and Snowflake costs before retiring source workloads.
Assessment
An inventory helps establish scope, sequencing, and the proof of concept. Gather what is available; sensitive credentials or production data should never be sent through a website form.
Common questions
No. Mirroring replicates supported Snowflake data objects into OneLake; it does not automatically convert all warehouse logic, SQL, orchestration, security policies, Snowpark code, or downstream reports. Assess each workload and choose mirroring, copy, refactoring, coexistence, or another pattern as appropriate.
The source draft describes managed tables and Iceberg tables as supported, with views and materialized views synchronizing every 12 hours. External, transient, temporary, and Dynamic Tables are listed as unsupported. Verify the current Microsoft documentation because support and limitations can change.
No. Mirroring is a data replication capability, not a general SQL or code conversion engine. Snowflake SQL, stored procedures, UDFs, Snowpark code, Tasks, and Dynamic Tables need separate assessment and modernization.
Mirroring continuously replicates supported objects into OneLake and exposes a read-only SQL analytics endpoint. Copy activity is an explicit pipeline data movement step that can select tables or queries and write to a chosen destination. Select based on support, freshness, transformation, scheduling, and control requirements.
The source draft notes that Microsoft documents Snowflake CDC in Copy job as Preview. It requires Snowflake table change tracking and appropriate privileges; source retention must exceed the scheduled interval. Confirm current preview status and destination support before production use.
Streams and Tasks are Snowflake-specific objects. Recreate change processing and orchestration with supported CDC Copy job patterns, Fabric pipelines, notebooks, or retained services. Preserve dependencies, schedules, retry behavior, and idempotency, then validate the results.
Warehouse can fit SQL-centric relational serving and curated marts. Lakehouse can fit Spark engineering, Delta data, semi-structured data, and multi-stage transformations. A solution may use both as well as a mirrored database.
No. Rebuild roles, grants, masking, row access rules, and effective permissions in the target security model, then test access paths. Microsoft documents that granular source security must be reconfigured for mirrored data.
Savings are not guaranteed. Compare Snowflake compute and storage, replication, Fabric capacity, OneLake storage, networking, licenses, implementation, parallel operation, and support using representative workloads and current pricing.
Timing depends on object and workload counts, data volumes, code complexity, dependencies, compatibility, security, testing, and cutover constraints. An estate inventory and representative pilot provide a more reliable estimate than a generic timeline.
Office Solution AI Labs
The Microsoft Marketplace offer describes assessment and architecture, data and schema migration, pipeline refactoring, governance, reconciliation, cutover, and team enablement. Confirm current offer terms, availability, supported objects, and engagement scope before making commitments.
We are an authorized implementation partner of Snowflake, Databricks, Amazon, Automation Anywhere, Denodo, DataDog, New Relic, and Elastic.
