Microsoft just retired the Dynamics 365 release wave. Here's how to plan without it.
For several years, Dynamics 365 customers built their planning calendar around two fixed dates a year: a spring release wave and a fall release wave. That calendar is gone. On August 25, 2026, Microsoft announced it is retiring the twice-yearly release wave model for Dynamics 365, Power Platform, and Dataverse, replacing it with continuous publishing to a single destination called the AI at Work roadmap. There is no Release Wave 2 plan this September, the first time that has happened in years, and the announcement is less than two weeks old as we write this.
If your organisation used those two dates to schedule budget reviews, training sessions, and change approvals, you now have a gap where a checkpoint used to be. This post covers what changed, why, and how a mid-market team can keep planning discipline without a fixed date to plan around.
What actually changed on August 25, 2026
Microsoft's announcement, posted by Richard Riley, General Manager of Agents and Low Code, confirmed that Dynamics 365, Power Platform, and Dataverse roadmap content is moving into the AI at Work roadmap alongside Microsoft 365 and Copilot. The company put it plainly: "We're retiring the twice-yearly release wave 1 and release wave 2 model in favor of continuous publishing. We'll publish new capabilities as soon as plans are committed and ready to share, rather than holding them until the next scheduled wave."
The FAQ attached to the announcement removes any ambiguity about this fall. It asks directly whether there will be a September 2026 release wave 2 announcement. Microsoft's answer is one word. No. New capabilities will be disclosed on the AI at Work roadmap as they become committed, rather than grouped into a twice-yearly release wave announcement.
The transition follows a set timeline. New capabilities began publishing to the AI at Work roadmap in September 2026, and any existing roadmap item with a public preview or general availability date of June 1, 2026 or later is migrating over during the fall. By November 15, 2026, Release Planner, the site Dynamics 365 admins have used for years to browse and save release plans, retires, and personalized saved views in My Release Plans will not carry over, so anything your team has bookmarked there needs to be rebuilt before that date.
What is not changing is the underlying delivery schedule. Products with established release cadences, such as Dynamics 365 Finance and Operations, continue on those schedules. Message Center remains the source for tenant-specific notices, and Microsoft Learn remains the documentation home. Microsoft's Message Center notice on the topic makes the distinction plainly. This transition changes how Microsoft communicates roadmap information, not how products are built, released, or deployed.
Why Microsoft made the change
Microsoft's stated reason is that most customers do not run Dynamics 365 in isolation. Dynamics 365, Power Platform, Microsoft 365, Copilot, and custom agents built in Copilot Studio increasingly operate together, and Microsoft wants one place to see what is coming across all of them rather than separate wave documents per product line. A single roadmap, filterable by product and environment, is the stated goal.
There is also a practical reason the twice-yearly model was showing strain. Capabilities, especially AI features, now ship on a rolling basis throughout the year. Grouping them into two announcements a year meant some features were held back from disclosure for months after they were effectively ready, and others slipped their stated wave date without much visibility into why. Continuous publishing lets Microsoft disclose a capability as soon as it is committed and then track it through development, rollout, and launch, rather than freezing it at a single point in a six-month document.
What this means if your budget and training calendar were built around two fixed dates a year
Many mid-market organizations treated release wave 1 and release wave 2 as forcing functions. The wave document landed, someone on the team read through it, flagged what mattered, and that review fed a training plan, a testing window, and sometimes a budget line for the next six months. The wave date was imperfect, but it was a deadline that got a room of stakeholders to pay attention at the same time.
That deadline is gone. Capabilities will now appear on your roadmap on their own schedule, sometimes as often as weekly, with no single moment where the whole organization is prompted to look. If nobody owns that review, capabilities will roll out to your tenant with no one having decided whether they should be turned on, tested, or postponed. That is the real risk here. Microsoft has been clear that release schedules for established products are unaffected, so the product itself will not change unpredictably. The risk is that the planning habit your organization built around a fixed calendar date no longer has a calendar date to attach to.
Four questions to build a continuous-monitoring habit around
A continuous roadmap needs a continuous, but lightweight, review habit. Before Release Planner retires on November 15, 2026, we recommend your team can answer these four questions.
Who is actually watching the roadmap now? Under the old model, this question answered itself twice a year. Under continuous publishing, it needs a named owner, not "IT will keep an eye on it." That person should be responsible for reviewing new and updated items on the AI at Work roadmap, filtered to your products and environments.
How often will you review new capabilities? Microsoft recommends a monthly or quarterly cadence, built on a saved filter and an RSS subscription, depending on how quickly your organization adopts new features. A monthly cadence suits teams making frequent process changes. A quarterly cadence may be enough for organizations running stable, mature Dynamics 365 deployments. Either way, pick one and put it on the calendar, since nothing else will put it there for you.
What's your process for deciding what to turn on versus ignore? Not every roadmap item needs a project. Some capabilities are opt-in, some are enabled by default, and some are scheduled for enforcement whether you act or not. Your review process should capture the roadmap status, the rollout date, whether the feature is optional or automatic, and which business process it touches, then route that information to someone who can make a call.
Who tests changes in a sandbox before they hit production? This is the step most likely to get skipped when there is no fixed wave date creating urgency around it. Continuous publishing means changes can reach your tenant on a rolling basis, so sandbox validation needs to be a standing responsibility, not a task that only gets scheduled twice a year. Assign it to a specific role, not a general intention.
Where this creates opportunity, not just extra work
It is easy to read this change as one more thing to monitor. There is a real upside worth naming. Under the wave model, a capability could sit fully built for weeks or months before its scheduled disclosure date. Under continuous publishing, Microsoft is disclosing capabilities as soon as they are committed, which means your team can see, plan for, and in some cases pilot new functionality earlier than the old calendar would have allowed.
The AI at Work roadmap also gives you tools the old Release Planner did not: CSV export, RSS subscriptions scoped to a single feature, shareable filtered links, and search by feature ID. Combined with the Release Communications MCP Server Microsoft is publishing alongside it, organisations with the appetite to do so can pull roadmap data directly into their own planning tools rather than reading it manually. For a mid-market team willing to build the habit described above, that is a faster signal on new capability than the twice-yearly model ever provided, not a slower one.