Dataracity
Microsoft Fabric · Migration

Move the warehouse to Fabric without breaking a single report.

On-prem SQL, aging warehouses, file shares full of extracts — we migrate them into Microsoft Fabric in stages, with the old and new estate running side by side until the numbers reconcile.

Where data lives today
On-prem SQL Server & legacy warehouse
File shares, extracts, Access databases
Spreadmarts (spreadsheet-based data analysis)
Staged
Where it lands
OneLake — one copy, open Delta format
Lakehouse with governed, modelled layers
Existing reports repointed, not rebuilt
The approach

Four phases, and the cutover is the boring part

Migrations fail at the end — when reports point at the new platform and the numbers don't match. So we make reconciliation a phase of its own, not an afterthought.

Phase01

Assess & sequence

Inventory what exists, what's actually used, and what can be retired instead of moved. The migration order follows business dependency, not table size.

  • Source inventory with usage evidence
  • Retire list — data that doesn't make the trip
  • Wave plan by business area
Phase02

Land in OneLake

Data flows into OneLake via mirroring, shortcuts, or pipelines — whichever fits each source. Where Fabric can mirror a database, we avoid building pipelines at all.

  • Mirroring / shortcuts before custom pipelines
  • Incremental loads, not big-bang copies
  • Source systems untouched throughout
Phase03

Model & reconcile

Landed data is shaped into governed lakehouse layers, and every migrated number is reconciled against the legacy system while both still run.

  • Medallion-style layered model
  • Row-count and value reconciliation reports
  • Both estates live until sign-off
Phase04

Cut over & retire

Reports repoint to Fabric one wave at a time. The legacy estate is decommissioned only after its consumers are gone — which is also when the old licence and hardware costs stop.

  • Wave-by-wave repointing
  • Rollback path per wave
  • Decommission checklist, signed off
Worth knowing

Three things that shape a Fabric migration

One copy, many engines

OneLake stores data once in open Delta format; SQL, Spark, and Power BI all read the same copy. Migrating well means you stop maintaining duplicates — that's where the cost falls out.

Shortcuts before movement

Data in ADLS, S3, or Dataverse can be shortcut into OneLake without copying. We move data only when there's a reason to — less pipeline, less to go wrong.

Governance from day one

Workspaces, domains, and Purview policies are set before data lands, not retrofitted after. A migration is the one chance to start governed — we don't waste it.

Next step

Start with the inventory.

A short assessment of your current estate: what moves, what retires, and what order makes the migration safe.