DR DYNAMICSIn brief
On 25 August 2026 Microsoft announced that Dynamics 365, Power Platform and Dataverse are joining the AI at Work roadmap, and that the twice-yearly release wave communication model is ending. New capabilities publish continuously from September 2026, and Release Planner retires on 15 November 2026 along with saved views and personalised filters. Delivery is unchanged: finance and operations apps still take four service updates a year in February, April, July and October, and feature management still moves features from optional to on by default to mandatory. What disappears is the calendar entry that came bundled with the wave. The replacement is one recurring hour a month, one checkpoint per service update, a named owner, and roadmap filters rebuilt as RSS subscriptions before November.
Microsoft has moved Dynamics 365, Power Platform and Dataverse onto a single always-on roadmap. What ships, and when it ships, is unchanged. The governance rhythm around it now has to be built rather than inherited.
Since Microsoft moved Dynamics 365 to a two-wave cadence in 2018, ERP change governance has come with a free forcing function. Twice a year a release plan was published, someone on the programme read it, and a meeting appeared in the calendar. Wave 1 reached general availability from April, wave 2 from October. Two fixed points where product change met programme planning.
That forcing function is being retired.
What Microsoft announced
On 25 August 2026 Microsoft announced that Dynamics 365, Power Platform and Dataverse are joining the AI at Work roadmap, the renamed Microsoft 365 Roadmap, and that the twice-yearly release wave communication model is ending. Message Center notice MC1461529 carries the same detail for tenant administrators.
The dates that matter:
- September 2026. New capabilities begin publishing to the AI at Work roadmap as they are committed. New release plans stop appearing on Microsoft Learn.
- September to November 2026. Existing content with public preview or general availability dates of 1 June 2026 or later transitions across.
- 15 November 2026. Release Planner retires. Saved views and personalised filters go with it.
Release plans already published stay on Microsoft Learn for historical reference. Release Wave 1 and Wave 2 announcements stop.
What did not change
This is the part worth stating precisely, because the announcement is about disclosure, not delivery.
Finance and operations apps still take four service updates a year. Autoupdates run in February, April, July and October, in two windows four weeks apart. Customers take a maximum of four and a minimum of two, and can pause a maximum of one consecutive update at a time. An environment more than two updates behind the latest release cannot pause at all.
Feature management still behaves the way it always has. A feature arrives as released and optional, sits there for six months or so, moves to on by default, and eventually becomes mandatory with a major release. Microsoft’s own documentation is direct about the consequence: features can be enabled without the customer’s knowledge when they move to on by default, and again when they become mandatory.
Message Center still carries tenant-specific notices. Deployment process, support lifecycles and end-of-service dates are untouched.
So everything that actually moves risk in an F&O estate, from the quarterly update to the feature that quietly flips on by default to the regression suite that has to clear before the autoupdate window opens, sits exactly where it sat in July.
The wave was a document. The date on it did the work.
Release waves were never how features arrived in finance and operations. Features arrive through service updates and feature management. The wave was a communication artefact.
It was a communication artefact with two useful properties.
First, it was read as a set. Someone sat down with the whole release plan and formed a view about the product direction, rather than reacting to individual items as they surfaced.
Second, it produced a shared object. A programme could triage a release plan, assign owners against it, and revisit the same list six months later.
A twice-yearly review sitting on top of a four-times-a-year update calendar was already lagging the product. It just happened to lag on Microsoft’s schedule, which made it feel like governance.
Always-on disclosure is a better input
The AI at Work roadmap is a stronger source than the wave documents were. Filtering by product and by environment. Feature IDs that can be searched and cited in a change record. Status tracking through in development, rolling out and launched. CSV export. RSS on any filtered view.
Microsoft also provides the Release Communications MCP Server, a public endpoint at https://www.microsoft.com/releasecommunications/mcp that exposes AI at Work roadmap and Azure Updates data to any MCP-compatible AI client. No authentication, no licence. For a team that wants a monthly change brief generated rather than assembled by hand, that is the piece that makes a monthly rhythm cheap enough to actually run.
Better inputs. What none of it comes with is a date in your calendar.
Build the monthly rhythm before November
The replacement for two annual roadmap exercises is not four. It is one recurring hour a month, one checkpoint per service update, and a named owner. Twelve hours of review across the year, plus four checkpoints that attach to work the team already does when an update lands.
Every month, sixty minutes.
- Pull the delta. RSS or CSV from the roadmap filtered to your products and your environment. Everything that changed status since last month.
- Triage into three buckets: this affects our configuration, this affects our customisations, this affects our users. Anything that lands in none of the three is context, not work.
- Give whatever survives triage an owner and a decision date.
Every service update, quarterly.
- Review the feature management workspace. Which features moved to on by default. Which are heading for mandatory. Turning one off is a decision, and it should carry a reason and an expiry date.
- Run regression against the update in a sandbox while the autoupdate window is still ahead of you.
Once a year.
- Reconcile. Which features were enabled, which were paused, which are now mandatory, and what that leaves on the customisation backlog.
The short list before 15 November
- Rebuild Release Planner saved views as filters on the AI at Work roadmap, and subscribe to them by RSS. Personalised views do not survive the retirement.
- Check who receives Message Center posts. It should be a distribution list, not one administrator who has since changed roles.
- Put the service update calendar into the programme plan properly: autoupdate window dates, and the end-of-service date for the version you are running.
- Name the owner of the monthly change review, and put the hour in the calendar for the next twelve months.
- Search the internal documentation, runbooks and ALM strategy for “release wave” and update every reference that treats it as a planning input.
Two of those take ten minutes. None of them take longer than an afternoon.
The point
Microsoft has improved the way product change is disclosed. Continuous publication, one destination across Dynamics 365, Power Platform, Dataverse and Microsoft 365, and a queryable endpoint on top of it.
What is gone is the calendar entry that came bundled with it. A lot of programmes used a Microsoft communication rhythm as their own governance rhythm without ever deciding to. Those programmes have until 15 November to notice.
Architecture governance needs a monthly product-change rhythm. It always did. The release wave made it possible to postpone that conclusion for another six months at a time.