AWS to Databricks, AWS to Fabric, Snowflake to Fabric: What Actually Changes Under the Hood?

The Need for Data Estate or Data Warehouse Migration

Agentic AI workloads will trigger hundreds of actions from a single prompt, creating massive demands on data, compute, and storage. Agents will continuously query, reason over, and act on it, putting new demands on compute, storage, integration, governance, and data accessibility.

What this means is, legacy data architectures are struggling to handle this scale efficiently, driving higher infrastructure costs and operational complexity. So, modernizing and migrating the data estate is essential to support scalable, cost-efficient AI workloads, which 83% believe in. If not, the legacy structures bring latency, duplication, integration overhead, and rising infrastructure costs.

The answer to this problem starts with cloud migration or data estate migration. But moving data from one platform to another is not simply a matter of copying tables and rebuilding pipelines. The architecture underneath changes. Storage layers, compute engines, data formats, orchestration, security, governance, semantic models, and workloads may all need to be rethought.

So, what we're trying to bring with this is to dive deep into the data platform migrations of AWS to Databricks, AWS to Microsoft Fabric, or Snowflake to Fabric — to understand what gets re-platformed, what gets redesigned, and what can be carried forward.

How the Three Cloud Data Migrations Look From the Outside

At a high level:

A mature AWS ecosystem or a data estate might involve S3, Glue, EMR, Redshift, Lambda, Kinesis, Step Functions, and external orchestration. Snowflake is a highly integrated analytical platform, so its migration to Fabric involves less service consolidation and more reconsideration of where storage, compute, engineering, BI, and governance should sit. Databricks and Fabric both aim to reduce architectural fragmentation, but they do it differently.

So, understanding application dependencies and assessing technical feasibility are two of the most important areas and also the top two migration challenges in general.

Let's dive deeper into each of them.

What Does AWS to Databricks Migration Entail?

An AWS-to-Databricks migration replaces service orchestration with platform orchestration. S3, Glue, EMR, and Redshift each carry their own configuration, permissions, and failure modes. So, Databricks consolidates that surface into Delta Lake as the transactional table layer, Spark/SQL as the shared compute engine, and Unity Catalog as the governance layer, so the same capability that used to require four services now lives in one platform.

What it means is that, you should start by understanding:

• Glue jobs and crawlers
• Redshift schemas and procedures
• EMR workloads
• Step Functions
• Lambda functions
• S3 paths and dependencies
• Streaming pipelines
• External schedulers
• Downstream consumers

Most common questions on AWS to Databricks migration:

1. What happens to AWS Glue ETL jobs?

Glue jobs can be migrated to Databricks, but they often need architectural redesign rather than a simple code rewrite. Glue workloads using DynamicFrames, crawlers, and triggers can be reworked around Spark, Delta Lake, and Databricks-native orchestration.

Instead of: Glue → S3 → Redshift → Lambda

the architecture can become: Ingestion → Delta Lake → Spark/SQL → Workflows → BI/ML

The key benefit is fewer handoffs between services and a more unified data platform.

2. How does streaming change in Databricks?

Streaming becomes part of the same lakehouse architecture rather than a separate pipeline layer. An AWS pipeline using Kinesis, Lambda, S3, and Redshift can move toward:

Auto Loader → Delta Lake → Lakeflow Declarative Pipelines

This allows batch and streaming to share common patterns, embeds data quality into pipelines, and lets BI, analytics, and ML consume the same governed data layer.

AWS to Microsoft Fabric Migration: Considerations and Questions

An AWS-to-Fabric migration replaces a fragmented service stack with OneLake as the shared foundation, and unlike Databricks, you don't have to move the data first. Fabric supports shortcuts to external sources including S3-compatible storage, so teams can connect and validate before they physically move a single byte.

The central shift is toward OneLake. Fabric is designed around a shared data foundation where its different workloads can operate over the same underlying data rather than requiring every engine to maintain its own copy.

Most common questions on AWS to Fabric migration:

1. Why are pipelines often harder to migrate than the data?

Because moving data does not move the logic built around it. AWS workloads may include Glue jobs, Step Functions, Lambda functions, IAM policies, data-quality rules, schedules, and downstream dependencies — all of which need to be assessed separately.

Some workloads may become Fabric Data Factory pipelines, others may be replaced or eliminated, and some may remain outside Fabric.

The goal is not to recreate AWS inside Fabric. It is to redesign the workload architecture around what Fabric can do best.

2. How do AWS Kinesis and Lambda workloads map to Fabric?

Kinesis streams can be mapped to Fabric Eventstreams and Real-Time Intelligence for event ingestion, processing, and monitoring, while Lambda functions may be replaced by Fabric pipelines, notebooks, or other event-driven processing patterns, depending on the workload.

AWS: Kinesis → Lambda → S3/Redshift → downstream applications

Fabric: Eventstreams → Real-Time Intelligence / OneLake → analytics & downstream workloads

This can reduce the number of services involved while bringing real-time ingestion, transformation, storage, and analytics onto a more unified platform.

Snowflake to Fabric Migration: Things to Consider

This migration starts from a much more consolidated architecture than the two AWS scenarios above, which makes it tempting to treat as a pure SQL compatibility exercise. That's too narrow. The deeper question is whether the warehouse should remain the center of gravity.

The advantage with this data warehouse migration is that there's Microsoft's Mirroring for Snowflake, now generally available (confirmed by Microsoft's GA announcement), which replicates supported Snowflake data into OneLake continuously. This creates a coexistence model in which existing workloads can continue operating while new workloads are progressively built on Fabric. Why this is more valuable than a big-bang migration is because it separates data migration from workload modernization.

Common FAQs for Snowflake to Microsoft Fabric Migration:

1. How does Snowflake's separation of storage and compute change in Microsoft Fabric?

The underlying architecture changes significantly. Snowflake separates storage and compute through its virtual warehouse model, while Fabric brings data into OneLake and provides workload-specific compute across its services.

This means migration requires reviewing compute sizing, workload concurrency, data movement, caching, and performance patterns rather than simply moving tables and keeping the same architecture.

2. What happens to Snowflake Streams, Tasks, and scheduled workloads?

They need to be mapped to Fabric's orchestration and data-processing capabilities. Snowflake Tasks and Streams may translate into Fabric Data Factory pipelines, notebooks, or other incremental processing patterns, depending on the workload.

The migration is therefore an opportunity to simplify orchestration and reduce duplicated data movement — not just reproduce every Snowflake task in Fabric.

The Biggest Migration Mistake: One-to-One Mapping

A common data warehouse migration approach looks like this:

That table is useful, but it isn't an architecture, because it assumes every old component deserves a new component. A better approach asks a different question of each one:

The target architecture should be designed from business capabilities, not reconstructed from technical artifacts.

How We Do It at Polestar Analytics With MigrationStudio

MigrationStudio moves data estates from one platform to another: AWS to Databricks, AWS to Fabric, Snowflake to Fabric, GCP to Fabric, GCP to Databricks, any-to-any in principle. It productizes the repeatable 70% of that work: an agent-driven workflow that scans the source system, works out which jobs are actually running versus orphaned, models the target architecture, converts the jobs, optimizes them, and promotes the result through Git.

The most important differentiator is semantic re-platforming instead of transliteration. Most migration tooling maps old syntax to new syntax and ships code that still thinks like the source system, the one-to-one mapping mistake this piece keeps warning about. MigrationStudio works out what a job is actually meant to do, then writes idiomatic code for the target platform and cleans up the debt along the way instead of copying it forward.

The claim is any-to-any, spanning AWS to Databricks, AWS to Fabric, Snowflake to Fabric, GCP to Fabric, and GCP to Databricks. Where it applies, that's a 35% or better cut in migration time and cost versus a manual rebuild.

In Summary: AWS to Databricks vs. AWS to Fabric vs. Snowflake to Fabric