The wave you are planning for does not exist
If your release calendar has a 2026 release wave 2 on it, take it off. Microsoft is retiring the twice-yearly release wave model for Dynamics 365, Power Platform and Dataverse, and there is no wave 2 to plan against. The announcement, titled One always-on roadmap, went up on August 25, 2026 under the byline of Richard Riley, General Manager, Agents and Low Code at Microsoft. The last wave Microsoft lists is 2026 release wave 1, covering April 2026 to September 2026, and nothing follows it.
What replaces it is a continuous roadmap. The announcement FAQ puts it plainly: "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." Features get published when Microsoft commits to them, on a rolling basis, at the single destination Microsoft is moving its roadmap into.
That is a real change to how the work gets scheduled. Two fixed dates a year, each with a long document attached, is what made release planning possible for teams that book regression testing months ahead. A rolling feed has no publication date, so there is nothing to build a test schedule around.
Microsoft's reasoning holds up better than the timing
Riley's stated reason for the change is that customers do not run these products separately. "Few organizations run a single Microsoft product in isolation. Dynamics 365, Power Platform, Microsoft 365, Copilot, and custom agents built in Microsoft Copilot Studio increasingly operate together to power business processes, employee productivity, and AI transformation."
That observation matches what most platform owners see every week. A change to Copilot Studio lands in a Dynamics 365 customer service queue. A Dataverse change turns up in a Power BI report someone in finance runs on a Monday. None of that respects the boundary between one product's release plan and another's, and running Dynamics 365 on a six-month rhythm while Copilot shipped continuously meant two halves of the same tenant moved on different schedules.
The argument for one roadmap is sound. The argument that a continuous roadmap is easier to plan against has not been made by Microsoft, and admins should not make it on Microsoft's behalf. A predictable publication date is what let a platform owner book a test window in January for work landing in April. Losing it moves that cost onto your team.
What switches off, and when
New release plans stop publishing to Microsoft Learn beginning September 2026. The release plans hub states that "Release Plans will no longer be published starting in September 2026" and that "Existing release plans will remain available for historical reference until further notice." Everything already published stays readable. Nothing new joins it.
A migration window runs from September to November 2026, covering content with a public preview or general availability date of June 1, 2026 or later. Anything earlier stays where it is. That cut-off matters if you track a feature that was announced early and then slipped, because the older entry does not travel to the new roadmap.
The Release Planner retires by November 15, 2026. The site already carries a banner reading "Release Planner retires by November 15, 2026" and says it is "no longer being updated; content shown here reflects information as of September 1, 2026." If any part of your change process depends on that tool, a saved filter, an exported feature list, a link sitting in a runbook, November 15 is the date it stops working.
The release channel is the lever you actually hold
The opt-in model changed alongside the roadmap. Microsoft Learn states that "The Early Access concept is deprecated and is replaced by the monthly release channel." Admins now set a release channel per environment in the Power Platform admin center, under Settings, then Product, then Behavior. That setting is the main control you still have over when a feature reaches users.
The monthly channel surfaces features monthly, with weekly preview updates on top of that. The semi-annual channel surfaces them at general availability deployment in April and October, and shows no preview features at all. Switching between the two is reversible, takes effect on save with no deployment, and does not change the database version number, because the channel is a feature flag rather than a version change.
Run the monthly channel in a sandbox and the semi-annual channel in production and you get an early look at what production will take in April or October. That split costs nothing to configure and is the closest surviving equivalent of the old wave preview window. Where your environment boundaries sit decides how much of that lead time you can use.
You cannot defer an update, only decide when you test it
The documentation is direct about deferral. It poses the question "Can I skip or postpone an update?" and the answer it gives is no, with Microsoft deploying weekly regardless. For the finance and operations apps, five business days separate the sandbox update from the production update, and those five days are the entire testing window.
So the planning question is when you test, not whether you take it. That changes the shape of a regression calendar. Instead of one large pass in the weeks before a wave lands, you need a smaller recurring pass tied to the channel each environment sits on, and a working method for triaging change notes matters more once the notes stop arriving in batches.
A change board that met twice a year around wave dates now has nothing to meet about. A board that moves at the pace of the platform is the version that survives a monthly cadence, and the message center becomes the feed that drives it rather than a document somebody reads in March. The line between roadmap chatter and a tenant-specific message center post gets more important, not less.
The opt-in page will send you to a tool that is being switched off
One warning before you point anyone at the documentation. The opt-in page has not been updated for the retirement, and it still directs readers to the Release Plans and the Release Planner. It still shows a 2026 release wave 1 table. An admin following it today gets sent straight to a tool that already carries a retirement banner.
The release schedule documentation carries a related trap. Its milestone table still lists September 16 and October 1, which read as wave 2 dates until you notice the label on them, and the label says they are example dates. There is no 2026 release wave 2, so treat those milestones as illustration rather than schedule.
The wave mechanics themselves are still documented and still accurate for history. "Release wave 1 covers features releasing from April through September" and "Release wave 2 covers features releasing from October through March." For 2026 wave 1, release plans became available on March 18, 2026, general availability was April 1, 2026, and additional languages followed on April 3, 2026. Those are the last dates of their kind.
What to do before November 15
Open the Release Planner this week and export what you have. Any saved list, any feature set you track for a named project, anything a runbook or a statement of work links to. After November 15 that content is gone from the tool, and the historical release plans on Microsoft Learn are all that remain.
Then open the Power Platform admin center and write down the release channel on every environment you own. Most tenants have never touched that setting, so production is sitting on whatever the default happened to be and nobody can say which one. Decide which environments run monthly and which run semi-annual, set them, and record the choice where the wave dates used to live.
Last, go through the calendar entries, runbook lines and onboarding notes that mention a release wave, and rewrite them. The features are still coming. The document that told you when has stopped being written, and whoever inherits that runbook in January will otherwise spend a morning hunting for a wave that was never published.
