The wave date was doing a job nobody named
Microsoft's post of August 25, 2026 says Dynamics 365, Power Platform, and Dataverse roadmap content joins the AI at Work roadmap from September 2026, and that release wave 1 and wave 2 announcements end. Capabilities will publish continuously, in the post's words, as soon as plans are committed and ready to share rather than being held for the next scheduled wave. Release Planner retires on November 15, 2026. One destination, always on.
We think the part most teams will miss is what the wave date did for them. Twice a year an announcement landed on a known date, and that date forced a meeting. A platform owner blocked a morning, product owners turned up, and someone walked through the list. Nobody wrote down that the wave date was the trigger for release ownership in the tenant, because it never had to be written down. It arrived on its own.
Continuous publishing takes that trigger away. The roadmap will be more current and easier to filter, and there will be no morning on which everyone is obliged to look at it. The post is candid about whose problem it solves. It says the transition changes how Microsoft communicates upcoming innovation and does not change how products are built, released, or deployed. The tenant side stays yours.
A saved filter is a statement about who owns what
The post lists what the new roadmap offers. Filter by product and cloud environment, export a full or filtered view to CSV, subscribe by RSS, search by feature ID, share a direct link, and connect through the Release Communications MCP Server. Every one of those is built on a filter, and a filter is a decision about scope. The moment someone saves a view limited to one Dynamics 365 app in one cloud environment, they have drawn a line around what the team will notice.
In a tenant with four product lines and three environment types, that is twelve lines, and the question is who holds each one. In most shops we see, the answer today is one solution architect who set up the Release Planner view years ago and shared the link. Our companion piece on getting ready for the switch covers the inventory work. The rebuild is the moment to put a name against each filter rather than reproducing one shared view that belongs to everyone and so to no one.
The export needs a person, and so does the feed
An RSS feed lands in a channel. If the channel is the platform team's general chat, the feed gets read on the day it is set up and ignored from the second week. We'd route each filtered feed to the product owner whose filter it is, and we'd have the platform owner check once a quarter that those feeds still have readers. An owner who left the company in March still has a feed, and nobody notices until a feature reaches production that the team swears was never announced.
The export has the same problem in a different shape. Microsoft's guidance in the post is a recurring review, monthly or quarterly, built on saved filters and RSS subscriptions. The export is how that review gets an agenda. Someone has to pull it, set it beside the last one, and mark what changed status since the previous meeting. Without a named person, the monthly review becomes a standing agenda item that gets skipped whenever the meeting runs long. We described the same failure in automation, where nobody owns the recovery, and roadmap review collapses the same way.
Deployment keeps its owners while planning loses its trigger
The post says products with established release schedules keep them, and that Message Center remains the source for tenant-relevant change notifications. So the deployment end of the chain does not move. The environment admin still gets a Message Center post with a date, still respects the boundary between roadmap signal and tenant notice, and still runs the same change process.
What changes is upstream. Before, a wave announcement gave the planning conversation a start date and the Message Center post gave it an end date. Now the start date is whenever a capability is committed and shared, which means any day. If nobody in the tenant owns the planning end, the first time a product owner hears about a change will be when Message Center says it is arriving. That is a change advisory board finding out at the deployment stage, and it is exactly the situation the wave meeting used to prevent.
Write the owner into the environment strategy
The practical move is one extra column in whatever document defines your environments. If you follow our environment strategy guide, each production environment already has an owner for promotion. Give the same person, or a named delegate, the roadmap filter for that environment's products, the feed that comes off it, and the review slot. If a filter has no owner, that environment has no roadmap coverage, and the document should say so.
The review itself can be short. Our Release Radar format fits: what changed status since the last review, which of it touches an environment we run, and who is looking at it before Message Center brings it back around. Twenty minutes a month per product line is the cost. The alternative is a single always-on roadmap that everyone assumes someone else is reading.
Before the first September publication lands on the new roadmap, put a name against each product and environment filter, then ask that person for the date of their first review and what they plan to compare it against.
