How to Retire and Archive Power BI Content Without Breaking Anything

October 3, 2026•9 min read•Michael Ridland

Every Power BI tenant I've audited in the last few years has the same problem. Somewhere between 40% and 70% of the content hasn't been opened in six months. There are workspaces named "Test - DO NOT USE", semantic models refreshing eight times a day that feed reports nobody reads, and three versions of the same sales dashboard with slightly different numbers.

Nobody deletes anything because nobody is sure what's safe to delete. And so the tenant grows, capacity costs creep up, refresh windows get crowded, and users searching for "sales report" find six of them and trust none.

Microsoft's implementation planning guidance has a section on retiring and archiving content, which is the final stage of the content lifecycle. It's the stage that gets the least attention, which is why I want to spend some time on it. Here's how we approach it with clients.

Why this matters more than it used to

Five years ago, unused Power BI content was mostly a tidiness problem. Now it costs real money and causes real confusion.

Capacity. If you're on Fabric or Premium capacity, every scheduled refresh of a dead semantic model is burning capacity units you're paying for. We worked with a professional services firm last year where retiring around 120 unused semantic models freed up enough capacity that they dropped a planned SKU upgrade. That was a meaningful saving for a few weeks of cleanup.

Copilot and AI. This one is newer. When users ask Copilot to find data, or when search surfaces content in the OneLake catalog, stale and duplicate items make the answers worse. An AI assistant pointing someone to a report built on a 2022 data extract is not a good look.

Security and compliance. Old content often has old permissions. People who left the organisation two years ago might still be listed on a workspace. Reports might contain personal information you're no longer meant to hold under your retention policy. The Privacy Act doesn't care that you forgot about it.

Trust. When there are four versions of the revenue report, people stop believing any of them. That's the most expensive problem of all, and the hardest to measure.

Retire versus archive

The two words get used interchangeably but they're different steps.

Retiring means taking content out of active use. Users can no longer find or open it, refreshes stop, it's removed from apps. But it might still exist somewhere in a recoverable form.

Archiving means keeping a copy of the content for a defined period because you might need it later, for audit, for legal hold, or because someone in finance will inevitably ask for "that report we used to have" in eighteen months.

Some content you'll retire and archive. Some you'll retire and delete outright. A small amount might need to be archived for years. The decision depends on what the content is and what your records management obligations say.

Step one - find what's actually unused

You can't retire content sensibly without data on how it's used. Gut feel from the BI team is not enough. Everyone has a story about deleting a report that "nobody used" and getting a furious email from the CFO's executive assistant who opened it every Monday.

The sources we use:

The activity log (via the admin REST APIs or the Fabric admin monitoring workspace). This tells you who viewed what and when. Pull at least 90 days, ideally longer, because some reports are only used at quarter-end or year-end. For Australian organisations, make sure your window includes June and July if you want to catch EOFY reporting.
The scanner APIs for an inventory of workspaces, reports, semantic models, dataflows and their owners.
Usage metrics reports at the workspace level for a quick view, though they're not great at scale.
Lineage view and impact analysis to see what depends on what. A semantic model with zero report views might still be feeding three other reports through a composite model, or be used directly from Excel.

That last point is important. Excel users connecting to semantic models via Analyse in Excel won't always show up the way report viewers do. We've seen "unused" models that were the backbone of a finance team's monthly spreadsheets. Check for those connections specifically before you touch anything.

We usually build a simple scoring model: last viewed date, number of distinct viewers, number of dependent items, owner still employed, and whether it's in an app. That gives you a ranked list of candidates rather than a giant spreadsheet of everything.

Step two - talk to the owners

This is where most cleanup projects stall, so be deliberate about it.

For each candidate, identify the owner. If the owner has left, find the business area that the content belongs to and identify someone senior enough to make a decision. Send them a clear message: here's the content, here's the usage data, we plan to retire it on this date unless you tell us otherwise.

Give a real deadline. Two to four weeks is reasonable. Silence is a yes.

What doesn't work is asking "do you still need this report?" without a default action. Everyone says yes. Nobody wants to be the person who said no to something that turns out to matter.

Step three - soft retire first

Don't go straight to deleting. A soft retirement stage catches the cases your usage data missed.

What soft retirement looks like in practice:

Remove the content from any Power BI apps.
Remove broad access (security groups, organisation-wide links), leaving only the owner and the BI admin team.
Turn off scheduled refresh on the semantic model.
Rename with a prefix like [RETIRING 2026-11] so anyone who still has a bookmark sees what's happening.
Optionally, move it to a dedicated "retiring" workspace.

Leave it in that state for 30 to 60 days. If nobody complains, proceed. If someone does, you've found a hidden user and you can have a proper conversation about whether it should be kept, merged with something else, or rebuilt.

Turning off refresh is the step that gives you the capacity savings straight away, and it's also the quietest signal. Users who depend on the data will notice it's stale within a day or two and get in touch.

Step four - archive properly

If the content needs to be kept, decide what "kept" means. There are a few options and they suit different situations.

Source control. If your team uses Power BI Projects (PBIP) and Git integration, the report and model definitions are already in your repository. Archiving can be as simple as tagging the last commit and noting the retirement in a changelog. This is the cleanest approach, and one more reason to get your team onto PBIP if you haven't already.

PBIX download to a controlled location. For content not in source control, download the PBIX and store it in a SharePoint library or storage account with appropriate retention labels. Note that you can't always download a PBIX, for example when the model has been modified in the service via XMLA, or when it uses incremental refresh with large partitions. Check before you assume.

Data snapshots. Sometimes what you need to keep isn't the report, it's the numbers at a point in time. For audit purposes, exporting the underlying data to a lakehouse or a set of files, with documentation, is often more useful than keeping a report that will no longer refresh because the source system has been decommissioned anyway.

Paginated report exports. For regulatory reports that were produced as PDFs or Excel files each period, the archive should be the outputs themselves, not the report definition.

Whatever you choose, record it. A simple register with the item name, original workspace, owner, archive location, retention period and deletion date is enough. The day someone asks "where did that report go?", you'll be glad it exists.

Step five - delete and clean up the edges

Once the soft retirement period passes and archives are in place, delete the content. Then clean up the stuff around it that's easy to forget:

Subscriptions and alerts pointing at the deleted reports.
Gateway data source connections that are no longer used.
Dataflows feeding only the retired models.
Empty workspaces. Delete these too. An empty workspace with old permissions is still clutter.
Bookmarks and links in SharePoint pages, Teams tabs and intranet sites.

Deleted workspaces can be restored by an admin for a limited retention period, so there is some safety net. Don't treat it as your archive though.

Make it a process, not a project

The biggest mistake I see is treating this as a one-off spring clean. You do a big cleanup, everyone feels good, and in two years you're back where you started.

What works better is building retirement into your normal governance:

A quarterly review of content with no views in 90 or 180 days, sent to owners automatically.
A rule that every workspace has a named business owner, checked as part of the review.
Expiry dates on sandbox and test workspaces from the day they're created.
A clear policy written down: what triggers retirement, how long soft retirement lasts, what gets archived, how long archives are kept.

Some of this can be automated with Power Automate and the admin APIs, or with a scheduled notebook in Fabric that reads the activity data and emails owners. We've set up a few of these for clients and they tend to pay for themselves quickly because the BI team stops spending hours chasing people manually.

What's still awkward

A couple of honest gripes. Getting reliable usage data across a large tenant still requires more plumbing than it should. The admin monitoring workspace has improved, but most organisations of any size end up building their own pipeline from the activity log to get the history and detail they need.

Dependency tracking also has gaps. Lineage view is good inside Power BI and Fabric, but it won't tell you about the Excel workbook on someone's desktop or the external app hitting a semantic model through XMLA. You need to cover those cases with a soft retirement period and good communication.

Wrapping up

Retiring content isn't exciting work, but a tenant with less, better-governed content is faster, cheaper and far easier for people to trust. It's also a prerequisite for getting decent results from Copilot and other AI features sitting on top of your data.

If your tenant has got away from you, our Power BI consultants can run a usage audit and set up a retirement process that sticks. For organisations moving to Fabric, it's worth doing this cleanup before migration rather than after, and our Microsoft Fabric consultants can help plan that work. You can also get in touch if you just want a second opinion on where to start.