With the regular cadence of Power Platform and Dynamics 365 release waves, we would have already seen the 2026 release wave 2 plans published in July. As the weeks rolled by and there were no signs of the new plans, it began to look like Microsoft was about to do something different this time around.

On August 25, the official announcement arrived: there will be no more release waves or release plans for Power Platform and Dynamics 365. Instead, it will all be under a single AI at Work roadmap.

As someone who has been a heavy user of release plan information over the years, as well as having built two replacements for the official Release Planner site from MS, I have some perspectives to share on this topic. So, buckle up for this final release train ride!

What’s the story behind the BizApps release waves? They go back eight years, with the first signs of “wave” terminology presented in this March 2018 blog post from James Phillips. His Digital Feedback Loop became a very familiar concept to everyone attending MS leadership keynotes for the next few years.

It was a time when the big restructuring brought the BizApps side of Microsoft’s product portfolio together with more mainstream productivity tooling on the Office side, namely PowerApps and Microsoft Flow (both correct spelling at the time), forming what we now call the Power Platform. New ways of working had to be invented and the format of biannual release waves with their plan publication process was the result of this shift.

During that time, the BizApps cloud products were moving into a single version model, meaning it was no longer possible to simply talk about Dynamics CRM 2016 etc. Instead, we had just an evergreen Dynamics 365 that covered all the different business apps and which had no meaningful version numbers or other identifiers to use.

That wasn’t a comfortable idea for many customers. While the agile software development practices and the cloud delivery model meant it was the obvious route for Microsoft to pursue, customer representatives in charge of actual CRM and ERP systems running the day-to-day operations of corporations didn’t necessarily see it that way. And I think the voice of the customer was indeed right about there needing to be more than just MS engineering practices that determine how the business software changes are rolled out.

It wasn’t a simple equation. The grand divide between what is beneficial for new Power Apps canvas apps built by citizen developers vs. what enterprise LoB systems require was the inherent source of tension. On one hand, you want to move fast and ship the latest software experiments out there quickly to gather usage metrics from real customers, to help you prioritize future development. At the same time, changing features that impact thousands of big, customized enterprise systems deployed for customer-specific workflows is not something you can just do on a whim.

The customers demanded information in advance — and Microsoft delivered that. The PDF documents that were originally called Business Applications Release Notes started arriving in all their 200+ page glory in 2018. Oh wow! These kinds of massive information drops sure gave us consultants a lot to chew on; as well as topics to discuss with customers who were even more dizzy from all this info.

Microsoft’s purpose was not to drown everyone in feature details, though. The reason for why the release plans (as they were later named) were created and shipped this way was all about demonstrating consistency and reliability. A standard format for all of the different products under the BizApps umbrella was an effective vehicle in driving home the idea that this truly was a platform — not just a collection of SaaS apps with shared marketing websites.

Microsoft Docs (later rebranded as Microsoft Learn) was soon included as a modern content management platform to host the release plan pages. The oldest bookmark I have is for the Power Platform 2019 release wave 2 plan. As the number of features and products grew, splitting the PDFs into Dynamics vs. Power Platform soon became a practical requirement.

This also evolved into a dogfooding project where the team building the Power Platform used tools from the same platform to manage and publish the Power Platform release plans. Their blog post “How Microsoft publishes product release plans using Power Platform” was accompanied by a Release Planner solution published on GitHub as a template for anyone looking to build something similar.

Finally, in 2022 there was a Release Planner website published to surface that Dataverse data via Power Pages. I was initially excited about it, then later grew frustrated with the GUI design and limitations and just kept using MS Learn pages for tracking things. Until I finally built my own version and published it via the releaseplans.net domain for the whole world to use.

James Phillips often used the “Swiss train” metaphor to highlight what was behind all those documents, sites and release item data. The idea was to have the Business Applications unit shipping software with the level of reliability and predictable schedules as you could find in some of the best run railway systems in the world. It was all about building trust.

When you knew in advance what the rhythm of the release waves was (wave 1: April through September, wave 2: October through March), together with the plan documents and clearly communicated early access / GA schedules, that served this goal quite well. Updates were no longer an uncontrollable threat. Instead, it was about change management where Microsoft promised to do its part of the process.

The theoretical plan was all good. It’s the messy real world that caused problems. The release plans that started as big commitments made in official looking PDF documents eventually turned into an ever-evolving backlog. The first version of the plan released before the start of the wave didn’t match with what actually got delivered along the way. Features were continuously added into the plans, as well as existing items getting either postponed or getting the “Deprioritized and will not be delivered” stamp.

Active community members still kept posting “my top X items from release wave Y” lists, whereas the more pessimistic ones (*ahem*) decided to deprioritize the biannual wave plan drops instead. What actually mattered was keeping an eye on the change history page of the current wave and seeing what Microsoft was actually investing in building. The gap between what was the sales pitch vs. the practical reality for Power Platform customers kept growing — even before LLMs arrived and turned the product team blog posts from facts into marketing fiction co-authored by Copilot.

It’s not all AI’s fault, though. There was one systemic flaw in the waves model that can be attributed to the James Phillips era leadership decisions. It’s the hard cliff between the waves that felt like an artificial construct, designed from the perspective of product marketing rather than engineering or end customers. Whether a feature eventually ships in September or October makes little difference in the real world. Yet in the release plan world this meant the information would be found in different docs and pages — or hidden behind a website filter for no obvious reason. Cutting the calendar year into two six-month periods was a compromise between the old world of software versions and the new reality of evergreen cloud apps. It was merely an agreement that had to be followed because someone had decided on it. Those kinds of things rarely last forever.

Is there now a legitimate grand plan behind the new model where Business Applications are merged with what was formerly Microsoft 365 Roadmap? Or is this whole thing just another renaming exercise?

What makes me somewhat suspicious about the grand plan is that in July there was a separate announcement about the Copilot Studio and certain agents having their release plans moved to the M365 side. That was less than two months ago. If everyone at MS was already planning to unify the release management process under “One Roadmap”, why bother making that announcement about a subset of products? Especially since nothing major has been published on the MCS roadmap yet.

It’s more likely that this is just another case of Microsoft shipping their org chart. Because Charles Lamanna is now in charge of not just the business side of Copilot and Dynamics 365 but also Microsoft 365. According to reports from The Verge, Charles now leads the Copilot, Agents, and Platform (CAP) team inside Microsoft that includes M365. That sounds like a mighty big team.

The release waves were the creation of Charles’ predecessor. It’s only natural for them to now be let go as part of this transition. Looking at the specifics of what is changing, Microsoft 365 message center message MC1461529 outlines the impact to customers as follows:

The change is said to be only about the communication layer. Deployment and rollout processes, preview and testing programs — all of this should remain unchanged. Which means that a lot of the earlier customer guidance will need to be “reimagined”. This includes documentation such as the general availability deployment page for Power Platform, which relies on there being a release wave twice a year:

Looking at that page, we see that the next GA version will get deployed to major regions like Europe on October 9-12, 2026. We are seven weeks away from it and there is still zero public information available to customers on what’s going to go live and when they can test it. Which is quite different from how the release schedules were designed back in the days, with plans out in June, early access available in August, and GA in October. It’s almost as if there’s no longer a recognized need to build the Swiss train type of trust…

The platform has of course changed from those days, too. We now have dedicated early release cycle environments, as well as the choice between monthly channel vs. semi-annual channel for model-driven apps. Not to mention the many feature flags and admin settings gating what actually happens when a user interacts with solutions or tools from Power Platform. Updates can be made less disruptive to customers.

Are they less disruptive in reality, though? The thing with us humans is that we tend to pay attention to what breaks down and take the things that work for granted. With the growing number of features Microsoft launches every year, there are logically more chances for disruptive bugs or functional changes to cause nasty surprises to customers. Even if average update reliability were to improve, it’s by no means certain that customers would trust their tech vendor more. Meaning that the need for actively building trust through non-technical means never goes away.

My gut reaction to the end of release waves and plans wasn’t all too positive, after I learned what’s going to replace them. Whenever I’ve glanced at the Microsoft 365 Roadmap in the past, I’ve never once found myself thinking “I wish we had that in the Power Platform world.” The information published there about upcoming features has always felt far too vague and the schedules uncomfortably imprecise.

For example, above is the SharePoint feature for HTML pages. I’ve been seeing those mentioned in both July and August “What’s New in Copilot” posts on the SharePoint blog. As well as many social posts. I tried it today in my M365 tenant and the feature works when prompted. Yet the M365 Roadmap says “rollout start: October 2026”. The feature description is also missing all the details that tech folks working with SharePoint would want to know.

Finally, not even Microsoft’s own blog posts reference that ID 569208 roadmap item. When I went looking for information on this specific feature recently, wanting to understand how it relates to other similar experiences, I found it really frustrating that it didn’t seem to have any anchor page — or even a proper feature name. The overarching feeling I got from this example was that the Roadmap is just another website that maybe gets used, or not.

This way of working may be “fine” when dealing with the kinds of information worker tools that are pretty much the same for all users. OneDrive and Teams aren’t different experiences across companies. Having a high-level item of a new button that’s going to be added somewhere doesn’t feel like that big of a deal. (Note: I’m not saying that admin, support and adoption work on the M365 side would be less demanding than the BizApps side. It’s just hard in different ways.)

What about with bigger line-of-business systems built on Dynamics 365 apps, with heavy customization and integration to other systems? The functional changes can be on quite a different level than those I see in many of the M365 Roadmap items today. It’s less about “a feature lands into a build and now everyone has the new button” and more about “the base product now includes these new options, we’ll need to plan whether this should be adopted into our configuration”.

Before the release waves concept arrived in 2018, what we also had in the BizApps world were roadmaps: PowerPoint decks with bullets about new things were said to arrive at some point. If we rewind all the way back to the era when on-prem servers were still an option, the timeframe for getting those bullets turned into live features running in the system was often measured in years. You couldn’t just casually preview new things in a live app. This naturally had its own challenges of validating whether the PM ideas met real-life user needs.

There was an upside to that friction, though. Someone had to think about the roadmap long and hard. Because it wasn’t possible to just go and fix things afterwards if you forgot to identify some dependencies or practical requirements. Whether this resulted in higher or lower software quality is impossible to determine. What I’m saying is that I had more trust in there being a vision and a plan behind what was being shipped.

These days, when I look at the chaotic way in which Frontier features are introduced in M365 Copilot, or how six different Sales agents are launched for D365 — I don’t feel all warm and fuzzy. The state of constant flux means that even if you stay alert on the changes, they can still arrive with zero notice and mess up your training course. Copilot Studio, the headline business product in the age of AI, is a great example of how to lose trust and alienate customers:

Ultimately, it doesn’t matter whether the comms strategy is called release plans or roadmaps. When neither customers, partners, nor product evangelists can trust that the features they rely on are going to be there the next morning, it’s messed up. Partial coverage of what is about to be launched into live environments is useless. There should be the commitment and an initiative similar to the release waves to regain trust and undo the damage from the past few years.

Instead, we now have the promise of an AI at Work roadmap site that will cover everything from Microsoft Clipchamp to Dynamics 365 Commerce. In theory, the quality of release comms might not deteriorate as a result of this. Is there a reason to assume it would improve? I’ll let you come up with your own answer to that question:

Five months ago, I built the current version of releaseplans.net site. Now, we know its data source will die on November 15. The Power Pages site behind Microsoft Release Planner will be deleted and the JSON API will stop sending me data. And that’s just how it goes. At least my site got to live a bit longer than the Release Plans Explorer Code Apps version published by Reza Dorrani from the Power CAT team. See the Release Plans Battle deck for a comparison of our approaches.

If anything, I think this is a great demonstration of why you should just vibe code things in the year 2026 instead of spending too much effort on building things the artisanal way. The world around us keeps changing at such a pace that any code you ship will become legacy faster than you could imagine…

“Boo-hoo… Stop crying your heart out, Jukka! Act like a grown man and use your vibe skills for something constructive instead.” Okay, I will. On the same day I learned about the end of Release Planner, I launched my Codex and told it to look at the Microsoft Release Communications MCP Server. After a few tokens spent, I had a “Frontier” version of the releaseplans.net site connected to MRC MCP.

Once the Power Platform and Dynamics 365 teams get their new plans uploaded to the AI at Work roadmap, I’ll be ready to take a look at them via this MCP. Then, the next iteration of my site will go live. Or should I say “the next wave”?