ChatGPT
Perplexity
Every Fabric migration plan is a list of what moves: pipelines, semantic models, reports, workspaces, each with an owner and a target date. What rarely gets scoped is what stays behind, because migrating an object is a task somebody can be assigned and deleting one is a judgment somebody has to defend.
Deferring that judgment used to be the correct call. Under per-resource Azure billing, an idle pipeline stays visible as its own line item so that you could move first, hit the date, and rationalize later from better instrumentation.
Fabric removes the line item. Every workspace assigned to a capacity draws from one shared pool of Capacity Units, which means the cleanup you deferred is now funded by the workloads you kept. Four decisions determine how much of it you carry across.
Retire reports on a window that matches your reporting cycle, not Power BI’s
What this decision entails
Which Power BI reports earn a Fabric workspace and which get archived. Microsoft treats this as a defined lifecycle stage with published guidance for retiring content at the end of its life.
Nuances and trade-offs
The window is where teams get this wrong. A quarterly board pack reads as unused for eleven weeks out of thirteen. Take 30 days literally, and you retire the reports with your most senior readers while keeping whatever somebody left open in a browser tab.
Case in point
Microsoft’s auditing guidance recommends storing a tenant inventory snapshot every week or every month and comparing it against the activity log to find items nobody has opened.
The reason that snapshot matters sits in the modern usage metrics report, which carries a rolling 30 days and deletes anything older unless you export it first. The window Microsoft ships and the cycle your business runs on are different lengths, and only one of them is adjustable.
How can you decide
Start the snapshot now, before scoping, so history accumulates while the plan is still being written. Set the threshold at zero unique viewers across a full reporting cycle, 90 days at minimum and twelve months for anything tied to close, audit, or statutory filing.
Stay updated with Simform’s weekly insights.
Cut pipelines with no consumer before your capacity prices them in
Deciding which ingestion and transformation jobs still have something downstream. Purview lineage runs source through dataflow, dataset, report, and dashboard, so a producer can see which reports consume a dataset and which datasets feed nothing.
Nuances and trade-offs
Throttling never names the culprit. It applies at the capacity level, so when a dead nightly refresh tips a capacity into overload, the person who feels it is whoever is running a live query at that moment. The complaint arrives as slow reports, and the reflex answer to slow reports is a bigger SKU.
Case in point
An F64 holds a fixed daily budget of 1,536 CU hours, and background operations that completed up to 24 hours earlier still count toward whether the capacity is overloaded.
Throttling then continues until unused capacity pays off every carryforward CU. A refresh nobody reads is competing for headroom with month-end close, a day after it ran.
How can you decide
Run the Purview scan before you scope, then treat an empty downstream as a question and not a verdict. Confirm it against refresh history and the activity log before anything moves to the retirement list.
When the symptom is throttling, hold the SKU upgrade until that list is settled, because sizing around dead weight prices it in for the life of the commitment.
Replace duplicate datasets with pointers before you argue about deleting them
What this decision entails
The near-identical tables that arrived through acquisitions, independent department tool choices, and manual copies that outlived their reason for existing.
Nuances and trade-offs
No approved-source figure exists for how much of a data estate is duplicated, and anyone quoting one is quoting healthcare records research or a vendor blog.
That absence is the useful part. Two similar tables can be a true duplicate or two departments with legitimately different definitions of the same noun, and no scan settles it.
Case in point
Fabric gives you a third option that did not exist on the legacy estate. OneLake shortcuts reference data in place instead of copying it, and Microsoft positions them explicitly to eliminate edge copies and remove the staleness that redundant copies introduce. The copy disappears while the access path survives, which means most of this list never reaches a deletion argument.
How can you decide
Sort candidates into three buckets. Shortcut the ones that exist only because a team needed its own access. Retire the ones nobody can attach to a consumer.
Route what is left to a named domain owner, because a definitional disagreement between finance and sales will not resolve inside a migration backlog.
Drop transformation rules nobody can explain in one sentence
What this decision entails
The calculated measures, business rules, and warehouse code whose meaning nobody on the current team can restate.
Nuances and trade-offs
Duplicates at least announce themselves as duplicates. Business logic does not. The migration task list absorbs it without argument, because moving a rule takes less effort than convening the people who could explain it, and the cost lands later.
Every transformation carried across becomes another parity test that must be reconciled before cutover, and validation is where a three- to five-person data team runs out of capacity.
Case in point
The lineage you leaned on for pipelines stops short here, and Microsoft documents exactly where. Stored procedures containing drop or create statements are not captured. Lineage is recorded only when a procedure execution moves data from one table to another, and it is not extracted for functions, triggers, or temporary tables.
Views used as a source surface as table assets, so the same object can appear twice in the catalog. For the one category where automated proof matters most, the automation has published blind spots.
How can you decide
This decision ends with a person. Require a named business owner to restate what each rule computes and why, in one sentence, before it enters scope. Rules nobody claims come off the list, and each one you drop is a parity test you no longer have to staff.
Fabric is about to remove the signal that forces this decision
Everything above rests on throttling being the thing that eventually makes dead weight visible. Microsoft is in the process of making that optional.
Capacity overage, in preview since FabCon in March, lets an admin opt into automatic billing for excess usage instead of throttling. Jobs keep running, nothing gets delayed, and the overage bills at three times the pay-as-you-go rate.
For a genuine seasonal spike, that is a reasonable trade. For a capacity-carrying asset that should never have moved, it converts a visible performance problem into a quiet invoice at triple the rate.
Microsoft’s own FAQ is blunt about the attribution that goes with it, answering the question of which workload caused an overage with the accumulation of everything running on the capacity. The documentation is equally direct that the feature complements capacity management instead of replacing it.
Which turns the retirement decision into a question about your defaults. If an admin flips that switch during a busy quarter and nobody revisits it, when does anyone find out what you brought across?
Simform’s Microsoft Fabric practice starts mid-market engagements by scoping what moves and what stays behind, before the first workspace goes live.
