Power BI Updates Archive - How to Use It Without Drowning in Release Notes

Every month Microsoft ships a new version of Power BI Desktop. Every month a handful of features move from preview to general availability, a few settings change their defaults, and something you relied on quietly gets deprecated. If you run a BI team at a mid-sized Australian organisation, you probably don't have time to read every monthly blog post. Most people don't.

That's where the Power BI updates archive comes in. It's the running record of what changed in past Desktop releases, month by month. It isn't glamorous. It's a long page of feature summaries. But it's the single most useful page I point clients to when they ask "why does my report look different?" or "when did that change?"

I want to talk about how we actually use it, because most teams either ignore it completely or treat it like a news feed. Neither works well.

What the archive actually is

Microsoft keeps a "what's new" page for the current Power BI Desktop release. Once a release ages out, its notes get moved to the archive. So the archive is effectively the history of Power BI Desktop, grouped by month, covering reporting, modelling, data connectivity, visualisations and Copilot features.

Each entry is short. You get a heading, a sentence or two, sometimes a link to the full feature documentation. The detailed write-ups live on the Power BI blog and in the feature-specific docs. The archive is the index.

The thing that makes it valuable is that it's in one place. When a client in Brisbane told us their measures were suddenly formatting differently after an upgrade, we didn't have to guess. We checked which Desktop version they jumped from and to, scanned the archive for those months, and found a change to how a visual handled default formatting. Ten minutes instead of an afternoon of poking at the model.

Why Australian organisations should care

Here's the pattern we see a lot. A finance or operations team builds reports in Power BI Desktop. IT controls the desktop image and only updates software every six months, sometimes longer. Meanwhile, the Power BI service updates continuously. Nobody controls that.

So you end up with authors on a Desktop version that's two or three releases behind the service. Most of the time that's fine. Occasionally it isn't. A report built with a newer feature in one person's Desktop won't open properly in someone else's older Desktop. Or a visual that renders one way in Desktop renders slightly differently once published.

The archive is how you work out the gap. If your SOE has Desktop from, say, April and the service is on November, you can read the archive entries between those months and know what your authors are missing and what might behave differently once published.

For regulated industries this matters more. We work with financial services and government clients where a change in how a number is displayed can trigger questions from auditors. Being able to say "this change came in with the September release, here's the documentation" is a much better conversation than "we're not sure why it changed."

How we recommend teams use it

I'll be honest: reading the archive end to end is a waste of time. It's a reference, not a book. Here's what actually works.

Do a monthly 15-minute scan. One person on the BI team (rotate it) reads the current month's notes when the release lands and flags anything relevant. Not everything. Just the stuff that touches your reports, your data sources or your governance settings. Post a short summary in your team chat. That's it.

Use it for upgrade planning. Before you roll a new Desktop version across the organisation, read the archive entries between your current version and the target version. Look specifically for:

• Features that moved from preview to GA (these may now be on by default)
• Changes to how existing visuals behave
• Deprecations, especially older connectors or legacy visuals
• Anything mentioning default settings

Use it for troubleshooting. When something changes and nobody touched the report, the archive is the first place to check. Work out the version numbers involved and read the relevant months.

Use it to kill zombie workarounds. This one gets overlooked. A lot of Power BI models we inherit are full of clever workarounds for limitations that Microsoft fixed two years ago. Someone built a calculated table to fake a feature, or a complicated bookmark setup to get behaviour that's now a single toggle. Scanning the archive for features related to your workarounds can show you where you can simplify. We did this for a logistics client and removed about a third of the hacks in their main model, which made it noticeably easier for their team to maintain.

What's good about it

The archive is consistent. The format barely changes, which makes it easy to scan. Entries are grouped by area, so if you only care about modelling or only care about visuals, you can skip around.

It's also honest about preview status. Microsoft labels preview features clearly, and the archive lets you see how long something sat in preview before going GA. That's useful when you're deciding whether to build on a preview feature now. Some features sit in preview for a long time. If you see something has been in preview for over a year, that tells you something.

What's still rough

A few things frustrate me about it.

It's Desktop-centric. The service gets updates too, and those don't always line up neatly with Desktop releases. If you're trying to understand a change in the service, the archive will only get you partway. You'll also need the Power BI blog and the Fabric release notes, now that Power BI sits inside Microsoft Fabric.

The Fabric overlap is messy. Since Power BI became part of Fabric, some features get announced under Fabric and some under Power BI, and it's not always obvious which. Semantic model features, Direct Lake, Copilot capabilities, these can show up in either place. I'd love a single unified changelog. We don't have one.

Detail is thin. The archive entries are summaries. For anything significant you need to click through, and sometimes the linked docs have been updated since, so you're reading the current behaviour, not what shipped that month. If you need to know exactly what changed at a point in time, it can be fiddly.

Search is just browser find. Ctrl+F is your friend. There's no filtering by area or by feature status. It works, but for a page this long it's a bit primitive.

A practical upgrade checklist

Here's roughly what we hand clients when they're planning a Desktop rollout:

1. Find your current Desktop version (Help, then About) and note the month.
2. Pick your target version. We usually recommend staying within one or two releases of current, never more than three.
3. Read the archive entries for every month in between. Note anything touching your data sources, custom visuals or key report features.
4. Test your top ten reports in the new version before rolling it out. Open them, refresh them, publish them to a test workspace.
5. Check custom visuals specifically. These break more often than native visuals.
6. Communicate changes to report authors. Short list, plain language.
7. Roll out, then keep the cadence going so you never fall far behind again.

The last point is the important one. The pain of upgrading is roughly proportional to how far behind you are. Teams that update every month or two barely notice changes. Teams that update once a year get a pile of changes all at once and spend a week fixing things.

If your organisation installs Desktop from the Microsoft Store, it auto-updates, which removes most of this pain. We generally recommend the Store version for that reason, unless IT has a specific reason to control versions. Where they do, the archive becomes even more important.

Where Copilot fits

Over the past year or so, a growing share of the archive entries have been about Copilot in Power BI. Report creation with Copilot, DAX query help, narrative summaries, that kind of thing. These change quickly, and the behaviour you tested three months ago may not be what users get today.

My advice: if you're rolling out Copilot in Power BI, treat the archive as required reading every month. AI features shift faster than traditional visuals, and the gap between what a pilot user saw and what a wider rollout sees can be surprisingly large. We've had clients sign off on a Copilot pilot only to find the experience had changed by the time they went live. If you're working through how to roll out these features responsibly, our Power BI consultants help teams do exactly that, and our broader AI for business intelligence work covers where AI actually adds value in reporting.

Who should own this

In smaller teams, the BI lead. In larger organisations, whoever runs your Power BI centre of excellence or platform team. The point is that someone owns it. When nobody owns release tracking, changes get discovered by end users, usually the week before a board meeting.

For organisations that have moved onto Fabric more broadly, the release-tracking job gets bigger, because you're now tracking Power BI, Data Factory, lakehouses, warehouses and more. We help clients set up a lightweight process for that as part of our Microsoft Fabric consulting work. It's usually a monthly review and a shared page of "changes that affect us." Nothing fancy, but it saves a lot of confusion.

The short version

The Power BI updates archive is boring, and it's useful. Scan it monthly, read it properly before upgrades, check it first when something changes unexpectedly, and use it to find old workarounds you can delete. That's 90% of the value, and it costs you maybe an hour a month.

Microsoft is going to keep shipping monthly. You can't stop that. You can make sure your team isn't surprised by it.