Microsoft Fabric vs a Legacy BI Stack (SSIS + SSAS + Power BI): The Migration Case

A stack that produces correct numbers on a predictable cost line, on skills you already have in the building, is a genuine asset. Replacing it costs money, attention and risk. The case has to be made on operational symptoms with dates attached, not on architecture diagrams.

This is the component-level version of that case: what maps to what, which migration approach completes, what breaks, and when not to move at all.

It survives because it is predictable. Four properties keep it alive, and each is real: cost predictability (an owned server and a SQL Server licence produce a flat, forecastable line — no capacity units, no throttling), a known performance envelope (the batch runs at 02:00, reports are ready at 06:30), skills already in the building (T-SQL and SSIS are widely held; Spark notebooks are not), and it is good at what it does (an SSAS tabular model over a well-built star schema answers financial queries fast).

What changes the answer is not the technology. It is a set of operational symptoms the stack cannot resolve without disproportionate effort.

Migration is forced by operational symptoms, not technology age. Six, in the order I usually meet them:

• The person left. Sixty packages, no documentation, and one person understood the control flow. Every change request is now a discovery project
• The batch window closed. Volumes grew several times over; the window with four hours of slack now has twenty minutes, and one late source file means yesterday's numbers at the morning meeting
• The data you now need is not relational. Machine data over OPC-UA or MQTT, SCADA extracts, telematics JSON, scanned delivery notes. SSIS can be made to do some of this, but the result is fragile
• Refresh has crossed the usefulness line. A report landing at 07:20 for a 07:30 meeting has failed even if it is correct — the most persuasive trigger in a board paper
• A capital decision has arrived. The server is out of warranty, or SQL Server 2016 extended support ended in July 2026; money is being spent either way
• The cube cannot answer the new question. A new dimension means a model change, a reprocess and a regression test, so the answer becomes "no" and the business builds a spreadsheet

If none of these six is true, you probably do not have a migration case yet. Say so, and spend the budget where it earns more.

Most of a legacy Microsoft BI stack has a Fabric equivalent, but the mapping is not one-to-one:

That last row is the one people miss. Migrating to Fabric does not remove the gateway; it changes what the gateway is for. And if your target model is Direct Lake on OneLake, the data has to already be in OneLake — the gateway cannot serve it.

The strangler pattern wins for a plain reason: it keeps the legacy stack authoritative until each workload is proven. Finance keeps closing on numbers it trusts. The programme earns permission to continue every six weeks rather than asking for it once, for eight months, up front. The cost is parallel running — price it, and put a decommission date with an evidence test against every workload.

Four things break reliably. SSIS script tasks and custom components — a .NET script doing a bespoke parse is a rewrite in Python, and the preview Invoke SSIS Package activity does not support custom components either. MDX that has no tabular equivalent — scoped assignments, custom rollups, named sets, writeback and ragged hierarchies are multidimensional-only; some translate to DAX, some encode a business rule that has to be re-agreed with finance before it can be rewritten at all. Budget the conversation, not just the code.

Stored-procedure logic nobody wrote down — the 900-line procedure computing net sales contains exclusions added by four people over eight years; the Migration Assistant converts schema and procedures, but it cannot tell you why an exclusion exists — only the credit controller can. And Direct Lake versus Import-mode habits — Direct Lake supports no calculated columns, calculated tables, hierarchies or aggregations, and binary and GUID types must become strings; every mature SSAS tabular model I have opened carries at least three of those. Import mode remains a legitimate answer — it is not a failed migration.

Migration converts a capital cost with a known depreciation profile into an operating cost that varies with usage. The CFO is not resisting the cloud; they are resisting a line item that cannot be forecast. Three points make the conversation work. Name what leaves the P&L and when — a migration with no decommission date is a cost increase, while one where the ESU renewal, the hardware refresh and the third-party ETL licence all disappear on a stated date is a substitution. Separate baseline from variable — reserve steady state, not the migration peak.

And do not hide the licence line — below F64, every Power BI viewer still needs a Pro or PPU licence, and on a 300-user rollout that can exceed the capacity line.

Four situations where I have advised against it:

• The stack works and no symptom has a date on it. No batch pressure, no leaver, no capital decision, no unanswerable question. Wait — the migration will be cheaper and better understood in eighteen months
• Your data volumes are small and your questions are stable. A 200 GB warehouse serving 40 users with a fixed report set gets little from Fabric and gains a consumption meter it did not have
• You are mid-ERP-replacement. Migrating the BI stack off a source system you are about to replace means doing the work twice. Sequence it
• Nobody owns the definitions. If "active customer" is disputed between sales and finance and no one can settle it, that disagreement surfaces as a reconciliation failure in month three and stops the programme

Five questions to answer this week:

• How many SSIS packages contain script tasks or third-party components? That number is your rewrite estimate
• Is your SSAS model multidimensional or tabular? Tabular is a migration; multidimensional is a rebuild — different programmes, different budgets
• What is the actual batch finish time over the last 30 days, and what time is the meeting that consumes it? The gap is your business case in one line
• What capital or licence decision is due in the next 12 months — hardware, SQL Server ESU, ETL renewal? That date is your natural programme start
• Which three report definitions are currently disputed between departments, and who can settle each?

We run these as a strangler migration on fixed scope after a short paid discovery, one subject area at a time, with a decommission date against each. First value in six weeks.