Republishing the report kept the numbers and broke everything pointing at them

The re-upload works. It is the aftermath that costs you

Repointing a report through Power BI Desktop means downloading the .pbix, changing its data source and republishing, and the service treats a republished file as the creation of a new report object. One report takes 15 to 20 minutes and looks harmless. Across a consolidation touching fifty, it is 12 to 16 hours of mechanical work before anyone has revalidated anything.

The time is not the worst of it:

• Every republish mints a new report ID. The identity the whole organisation has been linking to is replaced silently, and there is no way to ask for the old one back.
• Shared and embedded URLs go dead, because the URL derives from the ID. Links in email, wikis, chat and embedded applications resolve to nothing, and you hear about it from users rather than from a log.
• Downstream references break quietly. Dashboard tiles, bookmarks and subscriptions were bound to the old report, and nothing errors at the moment of republish, which is what makes this class of breakage expensive to trace afterwards.
• Permissions, row-level security and subscriptions get rebuilt by hand, each one a chance to get an access rule subtly wrong under time pressure.
• Revalidation is the hidden second job, rarely in the estimate and often longer than the change itself.

It was never a data source change. It was a new report wearing the old one's name

That is the whole diagnosis. Everything pointing at the original knew the difference even when the numbers were identical, which is why the cost landed downstream rather than in the edit.

A change that preserves the artefact needs no communication plan at all, and that saving never shows up in the time-per-report column, which is why the manual route keeps getting chosen.

One endpoint, and the report never notices

The Rebind Report endpoint takes a report and a target dataset and redirects one to the other. No file, no republish, no new object. The report ID does not change, so the URL holds, and every bookmark, tile and subscription bound to that report keeps working.

Two behaviours are worth knowing before a batch. If the new dataset lives in another workspace, a shared dataset is created automatically inside the report's own workspace; and if the report used a live connection, that connection is replaced with a direct binding. Neither is a failure, but both change the shape of the workspace and are easier to reason about deliberately than to discover afterwards.

The endpoint supports service principals, which is what makes this an unattended deployment step rather than a faster manual one. It will not validate schema compatibility (a mismatched dataset succeeds and surfaces later as broken visuals), it does not cover paginated reports or live connections to external models, and it does not trigger a refresh. A batch rebind is a planned operation with a pre-flight check, not something to fire at a production workspace on a Friday afternoon.