Data platform modernization
Plan a Redshift-to-Fabric transition around the data, SQL, external storage, security and analytics consumers your organization actually uses.
Assess provisioned clusters or Serverless workgroups, Spectrum and S3 data, COPY/UNLOAD workflows, procedures, orchestration and BI dependencies. Then determine what to move, refactor, retain or retire in Fabric Warehouse, Lakehouse or a hybrid architecture.
Scope, compatibility, cost and timing depend on the source estate and current Fabric capabilities.
Migration scope
Amazon Redshift-to-Microsoft Fabric migration is the process of moving and modernizing warehouse data, SQL logic, pipelines, security and analytics consumers. A source estate may include Redshift provisioned clusters or Serverless workgroups, tables and views, PL/pgSQL procedures, Spectrum external data, Amazon S3, AWS Glue and downstream applications.
Fabric Warehouse, Lakehouse or a hybrid destination may fit different workloads. The migration plan should preserve business definitions and operational controls while validating data types, performance, security and consumer behavior.
Migration patterns
No single mechanism handles every source object. Combine supported extraction, file-based transfer, S3 references and workload refactoring where each is appropriate.
Use Data Factory Copy activity for table or custom-query extraction, and assess Lookup or Dataflow Gen2 where appropriate.
Validate network reachability, authentication, source impact, throughput, retries, incremental behavior and type mappings before scaling.
Export a controlled snapshot to S3 using an appropriate format, then ingest approved files into OneLake.
Record run IDs, watermarks and file inventories. Validate encryption, permissions, partitioning and replay procedures.
Assess whether supported S3 data should be referenced through a OneLake shortcut or copied and converted into managed Delta tables.
Shortcuts reference data; they do not automatically migrate Spectrum definitions, Glue metadata or Lake Formation permissions.
Move workloads in waves while Redshift remains available for workloads not yet migrated or validated.
Set a source-of-truth boundary, reconcile aligned snapshots, monitor parallel-run cost and define rollback and retirement criteria.
Target architecture
Select a target by workload and data-product needs instead of translating every Redshift object into the same Fabric item.
Consider for structured relational analytics, SQL-centric development, governed data marts and T-SQL workloads.
Consider for Delta data, Spark-based engineering, file-oriented or semi-structured processing and notebook workflows.
Combine Lakehouse engineering with curated Warehouse data or eligible Lakehouse SQL and Power BI consumption where useful.
Workload mapping
These are assessment starting points, not guaranteed one-to-one conversions. Validate current feature support and test target behavior for each workload.
| Redshift / AWS component | Potential Fabric target | Migration consideration |
|---|---|---|
| Redshift database, schema and table | Fabric Warehouse or Lakehouse | Select by workload; validate names, types, nullability, defaults and business meaning. |
| Views and materialized views | T-SQL views, supported materialized views, or curated pipeline tables | Translate dependencies and rebuild refresh behavior; validate result sets. |
| PL/pgSQL procedures and UDFs | T-SQL, Spark SQL/Python, notebooks or pipelines | Rewrite dialect and control flow; test transaction, error and side-effect behavior. |
| Distribution and sort keys | Fabric engine-managed table layout and workload tuning | Do not copy Redshift physical settings directly; benchmark target workloads. |
| Spectrum tables and S3 data | Supported OneLake shortcut or copied Delta data | Recreate external metadata and security; assess format, catalog and consumer needs. |
| AWS Glue jobs and Step Functions | Fabric Data Factory pipelines, Dataflow Gen2, notebooks or retained services | Rebuild dependencies, schedules, retries, branching and operational alerts. |
| IAM roles, grants and row-level controls | Microsoft Entra identities, Fabric permissions and supported model or SQL security | Redesign least-privilege access and test effective permissions, including denied access. |
| QuickSight, Power BI and application consumers | Power BI models and reports, Fabric SQL endpoints or another approved target | Update connections and separately migrate report logic, refresh and security. |
Delivery approach
Inventory clusters or Serverless workgroups, databases, schemas, tables, SQL, Spectrum/S3 assets, orchestration, security and downstream consumers.
Choose Warehouse, Lakehouse, hybrid, shortcut, copy, refactor, retain or retire patterns for each workload and document compatibility risks.
Test realistic table sizes, high-precision decimals, SUPER/JSON, Spectrum, procedures and incremental ingestion—not just a simple table copy.
Configure workspaces, identity, network, connections and monitoring, then move approved data with explicit type mappings and lineage.
Rewrite SQL and procedures, rebuild orchestration, map security and update semantic models, reports and application connections.
Run source and target in parallel as needed, obtain business acceptance, follow rollback gates and hand over operational ownership.
Data validation
A successful copy job is not proof of a successful warehouse migration. Define technical and business checks before data movement, and compare source and target at the same logical point in time.
Common questions
Microsoft documents an Amazon Redshift connector in Data Factory for Fabric. Copy activity can read from a table or custom query, and other connector activities may be available. Confirm current connector, authentication and feature requirements for your workload.
No. Data extraction is one workstream. SQL, procedures, UDFs, Spectrum metadata, IAM policies, orchestration, workload management and BI assets need separate assessment and migration.
Warehouse can suit relational, SQL-centric analytics. Lakehouse can suit Delta storage and Spark engineering. A hybrid design may use both; choose based on each workload and its consumers.
The supplied technical reference notes that the documented Fabric Copy interim mapping converts DECIMAL precision greater than 28 to String. Review current connector documentation and test precision and scale end to end before production.
Inventory S3 data, Spectrum definitions, Glue metadata and associated permissions separately. Decide whether supported S3 data should be referenced or copied, and recreate the target catalog and security model.
Do not assume one-to-one conversion. Redshift SQL and PL/pgSQL behavior differs from T-SQL and Spark. Inventory and translate critical code, then regression-test semantics and side effects.
Savings are not automatic. Compare Redshift, S3, Glue, network and data-transfer costs with Fabric capacity, OneLake, pipeline, Power BI and parallel-run costs using representative workload measurements.
Timing depends on data volume, code complexity, Spectrum/S3 scope, orchestration, security, BI dependencies, transfer throughput and cutover constraints. An estate assessment and representative proof of concept support a more reliable estimate.
Office Solution AI Labs
Discuss source inventory, target architecture, extraction and transfer, SQL modernization, Spectrum and S3 dependencies, security mapping, reconciliation and cutover. Confirm the engagement scope, automation availability, supported objects, staffing, schedule and commercial terms directly with the company.
We are an authorized implementation partner of Snowflake, Databricks, Amazon, Automation Anywhere, Denodo, DataDog, New Relic, and Elastic.
