The immediate consequence for administrators is straightforward: teams that have treated Release Wave 1 and Release Wave 2 as their fixed planning calendar need a replacement process now. Microsoft’s August announcement says Message Center remains the authoritative source for tenant-specific change notifications, while the AI at Work roadmap is for public plans and status. Those are complementary channels, not interchangeable ones.
Forvis Mazars correctly identifies the consolidation as a planning change for business-application customers. But Microsoft’s own transition details reveal the more concrete issue: this is also a migration away from a planning tool and its saved views, with a limited set of historical roadmap entries moving into the new experience.
Release Planner has a retirement date
Microsoft’s previous release-plan model centered on semiannual documentation covering a defined period: Wave 1 generally ran from April through September, and Wave 2 from October through March. Those plans gave Dynamics 365 administrators, solution architects, Power Platform governance teams, and implementation partners a predictable window to review features, assess dependencies, and brief business owners.
That cadence is ending. Microsoft says it will no longer publish new Dynamics 365 and Power Platform release plans beginning in September 2026. Instead, it will add roadmap entries individually when they are “committed and ready to share,” then update their state as they move through In Development, Rolling Out, and Launched.
The company has set out a three-part transition:
- New Dynamics 365, Power Platform, and Dataverse roadmap items began appearing in the AI at Work roadmap in September 2026.
- Existing entries with a public-preview or general-availability date of June 1, 2026 or later will migrate between September and November.
- Release Planner is due to retire on November 15, 2026, after which the AI at Work roadmap becomes Microsoft’s primary public roadmap destination for these products.
The June 1 cutoff deserves attention. Microsoft says older material remains in existing release plans on Microsoft Learn for historical reference, rather than being fully folded into the new roadmap. An organization researching why an older capability was introduced, what Microsoft originally promised, or what dependencies were documented at the time may therefore need to search both systems.
That is a practical distinction for IT teams maintaining internal architecture decisions and release records. A single new roadmap does not mean a single complete archive.
Continuous disclosure changes the planning rhythm
Microsoft presents the change as a way to disclose planned capabilities earlier rather than holding them for the next wave announcement. That can give customers more time to assess an upcoming feature, but it also removes the built-in deadline that made release planning a recurring organizational event.
Under the wave system, many companies could schedule a predictable review: inventory planned changes, determine which environments were affected, identify licensing or governance questions, test relevant previews, and prepare communications for business users. An always-on roadmap puts that responsibility back on the customer. Microsoft recommends a monthly or quarterly review rhythm, depending on how quickly an organization adopts changes.
For Dynamics 365 and Power Platform administrators, monthly is a more credible starting point than an annual or semiannual review. Roadmap items are plans, not deployment notices, and delivery dates can still move. But waiting for a major feature to surface in a quarterly executive review can leave little time to evaluate a change that affects data models, business process flows, role-based access, connectors, Copilot grounding, or integration behavior.
The new model also creates a risk of uneven attention. Product teams closest to Power Apps, Power Automate, Dynamics 365 Sales, Customer Service, Finance, Supply Chain Management, or Dataverse may watch relevant items, while enterprise architecture and security teams miss cross-product changes. Microsoft’s stated rationale is precisely that these workloads increasingly operate together; the governance process should reflect that reality.
The replacement for the old release-wave workshop should be a standing change-review process with product owners, platform administrators, security staff, integration owners, and training leads. The roadmap can identify what may be coming. Message Center, service-health communications, implementation documentation, and testing in nonproduction environments remain necessary to determine whether a particular tenant will actually receive a change and what action it requires.
Saved views will not follow customers to the new roadmap
The least visible change is one Microsoft makes explicit in its transition FAQ: personalized saved views in My Release Plans will no longer be available after Release Planner retires. The AI at Work roadmap does not offer an equivalent personalized saved-view feature.
That means organizations relying on saved filters should not assume their current setup will carry over. A filtered view may represent substantial institutional knowledge: selected products, regions, cloud environments, lifecycle states, and feature categories that a particular team monitors. If that configuration exists only inside Release Planner, it becomes a de facto undocumented dependency.
Microsoft’s substitute is a combination of product filtering, sharable roadmap links, CSV exports, RSS subscriptions, feature IDs, and advanced search. Those tools can support a workable monitoring process, but they distribute the job across several mechanisms rather than preserving a personal dashboard.
Before November 15, administrators should document their existing Release Planner views and translate them into a repeatable monitoring method. At minimum, that should include the business applications and Power Platform components each team owns, the cloud environment or geography relevant to its tenant, the rollout states it follows, and the internal recipients who need notification when a roadmap entry changes.
CSV exports may be useful for comparing a current roadmap snapshot with a previous one, provided the organization stores the exports and records the date retrieved. RSS can provide a lightweight alerting channel, though it should feed a shared team process rather than an individual mailbox. A roadmap item is most valuable when someone is assigned to decide whether it affects configuration, licensing, customizations, training, or release communications.
The MCP server is useful, but it is not a change-control system
Forvis Mazars highlights Microsoft’s Release Communications Model Context Protocol server as a way to incorporate roadmap data into AI-assisted planning and reporting. That capability is real: Microsoft documents the Release Communications MCP Server as a public, remote MCP service that lets compatible AI clients search and retrieve current release information in natural language.
Microsoft says the service can be used with tools including Visual Studio Code, Visual Studio, GitHub Copilot CLI, and other MCP-compatible clients. It requires no authentication or license to access, according to Microsoft’s documentation, although the company says users remain subject to its API terms.
For technical teams, that can make roadmap monitoring easier to automate. A platform team could use the server to retrieve newly published items matching selected products, create a briefing for a change-advisory meeting, or compare developments across Dynamics 365, Power Platform, Microsoft 365, Copilot, and Azure Updates without manually browsing several sites.
But the MCP server should be treated as a retrieval interface, not proof that a change is approved for deployment. Natural-language queries can return useful summaries, yet they do not replace tenant-specific notices, release notes, access controls, testing, or an internal decision on whether to enable a feature. This is especially important where Copilot capabilities may surface enterprise data, invoke actions, or depend on Dataverse permissions and connected systems.
The safer pattern is to use MCP-derived results to identify and triage items, then verify the specific feature against Microsoft documentation and the organization’s own tenant communications before scheduling implementation work.
Message Center remains the tenant-level signal
Microsoft has been unusually clear about what this roadmap transition does not change. Products with established release schedules will continue to follow those schedules. Microsoft Learn remains the documentation home. And Message Center remains the source for notices relevant to a customer’s own Microsoft 365 tenant.
That last point limits how much customers should infer from a public roadmap entry. A capability marked Rolling Out can be relevant to a product a company licenses without being immediately available in that company’s region, cloud, environment type, or tenant configuration. A roadmap entry can also change before release; Microsoft has long cautioned that planned dates and features may move or not ship.
The AI at Work roadmap therefore solves a discovery problem, not a deployment-control problem. It gives organizations a broader window into Microsoft’s direction across business applications and AI. It does not tell an administrator, by itself, whether to turn something on, whether a configuration will change, or whether a custom solution will remain unaffected.
Microsoft’s shift will reward organizations that turn roadmap watching into a formal operational discipline. The deadline is no longer the next Wave 1 document: it is November 15, 2026, when Release Planner and its saved views are set to disappear.