The risk in a Fabric migration is not the new platform. It is the reports people rely on breaking while you move. Here is the order that keeps the lights on.
Most Fabric migrations do not fail on the technology. They fail on timing. Somewhere in the move, a report the business runs on stops matching last month, or breaks entirely, and trust in the whole programme goes with it. After that, every number the new platform produces is met with a raised eyebrow, no matter how right it is. The technical migration succeeded and the migration failed.
The way you avoid that is sequence. Not a big-bang cutover where everything moves one weekend and you hope, but an order that keeps the existing reporting standing until the new version has earned the switch.
The order that keeps the business running
- Run the old and the new side by side, and reconcile. Before anything is switched off, the Fabric version of a report should produce the same numbers as the one it replaces, and you should be able to prove it. Not “looks about right”, but reconciled to the penny against the source people already trust. If the two disagree, you find out in a controlled comparison, not in a board meeting.
- Move by business area, not by technical layer. The temptation is to migrate all the pipelines, then all the models, then all the reports, because that suits the engineering. It leaves the business with nothing usable until the very end and no way to build confidence along the way. Moving one business area end to end, proving it, then the next, means value and trust accrue in steps. Finance first, or whichever area feels the pain most, then outward.
- Take the debt, do not carry it across. A migration is the one moment you are looking at every report anyway. It is the chance to leave behind the duplicated logic, the undocumented workaround, the report nobody has opened in a year. Lift-and-shift every bad habit into Fabric and you have paid migration prices to preserve your problems. Some pruning is the point, not a distraction from it.
- Keep the rollback real until the switch. For every report that moves, the old one stays available and correct until the new one has run clean through at least one full cycle, a full month end included. Rollback that only exists on a plan is not rollback. It has to be a thing you could actually do on the morning it goes wrong.
Done this way, a Fabric migration is a series of small, provable wins rather than one large act of faith. The business keeps working throughout, each area switches only when its numbers are proven, and the day the old platform finally goes dark is an anticlimax, which is exactly what you want.
If you are moving to Fabric and would rather sequence it around keeping the business running than around what is convenient to build, that is how we scope these. Talk to us at hello@hoptonanalytics.com.
Our Microsoft Fabric page sets out how we plan and sequence a move, and our free audit is a quick way to see what your current estate would involve.
Related reading
Sizing Microsoft Fabric capacity without overpaying or throttling
Microsoft Fabric vs Azure Synapse: what UK mid-market teams need to know
Simon Devine
Managing Director
Part of the Hopton Analytics team, delivering governed analytics programmes for UK mid-market organisations.
