ChatGPT
Perplexity
For years, moving off Azure Synapse or Power BI Premium sat on the data team’s roadmap as a someday project, scheduled whenever capacity freed up.
That framing no longer matches what Microsoft has built. Synapse still runs and receives bug fixes and security patches, so there’s no need to rush a migration.
What changed is where new capability lands. Everything Microsoft now builds for analytics and AI ships in Fabric first, which turns a quiet engineering task into a timing decision that finance and operations have a direct stake in.
The question stopped being whether you move. It became when, and what sets the clock.
Which capabilities ship in Fabric but not in Synapse?
The migration conversation usually fixates on effort, pipelines, and downtime. That accounting captures the cost of moving and overlooks the larger number on the other side of the ledger: the cost of staying.
Microsoft has been explicit about the split. Synapse remains in maintenance while new investment goes into Fabric, which the Fabric team frames as the platform on which it is building the future.
That future already exists in capabilities Synapse was never going to receive, including Direct Lake, Real-Time Intelligence, Fabric Databases, and Copilot with Fabric data agents.
None of these are roadmap promises. They are shipping features available today on Fabric and unavailable on Synapse at any price.
The way to price a delayed migration is to list what your analysts and your roadmap cannot touch for each quarter you wait, then decide whether that gap is one you can keep affording in capability rather than in labor.
Fabric’s AI tier now runs on every paid SKU from F2 up
The agent tier is where the capability gap bites hardest at mid-market scale, and until recently, it was also where the gap was easiest to ignore.
A year ago, Copilot and Fabric data agents sat behind the F64 capacity tier, a commitment most mid-market budgets skipped without a second look. That gate is gone.
Microsoft removed the F64 requirement in April 2025 and made those AI capabilities available on every paid SKU from F2 up.
The practical effect is that a fifty-person finance group can now point a Fabric data agent at its OneLake data and get governed answers in plain language. This workflow, twelve months ago, was priced out of reach for an organization of that size.
The capability you would be waiting on is no longer hypothetical or enterprise-gated. It is within your reach at your current scale, which means the cost of staying on Synapse is paid in the current quarter, not later.
Microsoft has already closed Power BI Premium sales and retired Synapse Data Explorer
The timing feels open-ended, which is why most teams defer it indefinitely. The past year argues against that reading, because the clock is already running in public.
Microsoft closed new Power BI Premium per-capacity sales, ended non-Enterprise Agreement renewals, and retired Synapse Data Explorer. Those dates have already passed, which is the entire point.
The precedent is set, and Microsoft has shown how it sequences these transitions across the product line. What that history tells you is not that a deadline is coming for everyone on the same day.
It tells you the mechanism is live, and the only open question is where your own trigger sits inside it. For most teams, that trigger is still ahead, which is exactly the window in which the schedule is still yours to decide.
What sets your own Synapse-to-Fabric migration date
A date you do not set tends to be set for you, and on Fabric, the triggers are already written into the contracts and lifecycles you signed up for.
A company on Power BI Premium P1 converts to an F64 when its Enterprise Agreement ends, and the Premium model goes with it, whether or not anyone planned the change.
The Spark runtime in your pipelines has a published end-of-support date that does not shift to suit your roadmap. Your next net-new project has no reason to land on Synapse, so every quarter of delay quietly widens the estate you will eventually have to move.
Mapping your estate against the next Premium renewal and the end-of-support dates of the components you depend on turns an open-ended someday into a specific earliest date. Let that date set your schedule, rather than scrambling to react when the notice arrives.
Stay updated with Simform’s weekly insights.
How to sequence the migration so it never touches reporting
The fear that stalls these migrations is the all-at-once switch that disrupts reporting mid-quarter. Microsoft’s own guidance is built to remove that risk.
The recommended approach is phased and ordered by business value and dependency risk, keeping Synapse as the writer while Fabric reads the same data through OneLake shortcuts until each workload is validated.
Microsoft calls this the safest option for most migrations, because it lets old and new run side by side with no forced cutover until the new path has proven itself against the source.
Sequencing the move by value and risk, reconciling each workload against its source for a full reporting cycle before cutover, and timing the switch away from financial close keeps the migration invisible to the business consuming the reports.
That continuity call belongs to operations as much as it does to engineering, because operations is the one who feels it if a number moves mid-close.
Where validation time piles up in a Fabric migration
A phased migration scales in both directions, but the risk inside it is not evenly distributed.
When OBOS BBL moved from Synapse to Fabric, it transitioned more than 600 notebooks and pipelines. It consolidated over 4,500 data objects into 87 Fabric lakehouses, running the old and new environments in parallel and validating row counts against live business KPIs before retiring anything.
That is a large program at an organization with more than a thousand employees, and the same workload-level validation method scales down to a mid-market estate.
What does not scale away is where the risk concentrates. The exposure lives in the warehouse code, where Fabric is not fully T-SQL-compatible with Synapse dedicated SQL pools, and that incompatibility is where validation hours accumulate.
Budgeting your migration by notebook count will understate the work, because notebooks port comparatively well. Budgeting it against your warehouse code and accounting for the dialect differences hidden within it gives you a timeline that survives contact with the actual cutover.
Should you reserve Fabric capacity or stay pay-as-you-go?
Moving to Fabric collapses your separate Synapse, Data Factory, and Power BI bills into a single capacity meter, which reads as simplification until the commitment question lands.
Fabric capacity bills per second and pauses when idle, so a pilot costs very little and carries almost no financial risk. The decision that carries real money is the reservation.
A one-year or three-year commitment saves roughly 41% compared to pay-as-you-go, and the catch is equally real: reservations are non-refundable, and unused capacity is forfeited hour by hour rather than carried forward.
Reserve an F64 for a month-end peak, then run at a fraction of it for the other three weeks, and you pay the committed rate for idle capacity for every one of those hours.
Staying on pay-as-you-go through the pilot and into early production protects you from that trap. Reserve only once consumption has stayed consistently high for most of the day, and size the reservation against a month or two of real usage data rather than a forecast you have not yet tested.
The real advantage is knowing your trigger date early
The teams that move well will not be the ones with the cleanest architecture going in. They will be the ones who knew their trigger date early enough to choose their own sequence, pick cutover windows that miss their close, and reserve capacity only after the usage data justified it.
Every one of those advantages depends on knowing the date before it arrives, and the date is knowable today from contracts and lifecycle pages you already have access to.
The question worth carrying forward is narrow and answerable. Which of your workloads is closest to a date you do not control, and have you looked up what that date is yet?
As a Microsoft Fabric Featured Partner, Simform maps mid-market data estates against their migration triggers and sequences the move by business value and dependency risk before the first workspace is touched. If your Fabric or Azure data program is approaching one of these dates, our data platform modernization practice starts there.
