Release waves are ending. Is your Dynamics 365 release governance ready?

Microsoft is ending the twice-yearly release-wave disclosure model for Dynamics 365, Power Platform and Dataverse. From September 2026, new roadmap content is being published continuously through the Microsoft AI at Work roadmap, with Release Planner scheduled to retire by 15 November 2026.

This does not mean Dynamics 365 product release schedules have disappeared. Products with established release schedules continue to follow them.

The significant change is how forward-looking plans are disclosed and updated.

Instead of waiting for two large planning moments each year, organisations will encounter a continuing flow of capabilities moving through development, rollout and launch.

That distinction matters.

Many Dynamics 365 Finance and Supply Chain Management programmes have built governance around release-wave publications. Architects examine the plan, product owners select relevant features, teams estimate work, and a change portfolio is assembled.

If the publication model becomes continuous but the governance model remains periodic, important changes may be identified late, assessed inconsistently or separated from programme priorities.

Give each source a clear role

The first step is to avoid combining several information sources into one vague concept of “the Microsoft roadmap.”

Each source answers a different question.

The AI at Work roadmap is the forward-looking public view. It helps teams monitor planned capabilities, status and rollout information. Its entries can change as Microsoft's plans evolve, so they should not be treated as guaranteed customer implementation dates.

Message Center provides tenant-relevant change notifications. It should be monitored for changes that apply to the organisation's services and environments. It is more operationally specific than a public roadmap, but it still does not replace internal ownership and approval.

Microsoft Learn remains the source for product documentation and implementation guidance. A roadmap item can identify a change worth investigating, but architecture and delivery decisions should be based on available documentation, supported scenarios and validated product behaviour.

Finally, the programme backlog or change-governance record must remain the customer's authoritative system of record.

That is where the organisation records ownership, impact, dependencies, decisions, validation evidence and delivery commitments.

Microsoft's sources inform the decision. They do not make or govern it.

Establish a continuous governance loop

The operating model I would recommend is:

The important point is that this is not merely a process diagram. Every stage needs an accountable owner and a defined governance output.

Monitor: Architecture/release management identifies a signal and records it.

Assess: Functional and technical owners establish business impact, technical impact, dependencies, security implications and risk.

Decide: The appropriate architecture or portfolio authority chooses to adopt, defer, monitor, reject as not applicable, or investigate further.

Validate: Delivery, testing and security teams establish whether prerequisites and expected behaviour have actually been demonstrated.

Deliver: Release and operational teams move an approved change through controlled deployment and confirm the outcome.

Across all five stages sits one persistent control:

That record should contain, at minimum, ownership, affected processes, technical impact, dependencies, security considerations, decision and rationale, validation evidence, target release and final outcome.

This is the distinction between monitoring Microsoft's roadmap and governing ERP change.

Monitor signals, not commitments

Create filtered roadmap views for the products, regions and themes relevant to the ERP estate. RSS and CSV downloads can support monitoring and consolidation.

The Microsoft Release Communications MCP Server can also provide programmatic access to information powering the roadmap for compatible AI clients.

These are useful inputs. They are not governance controls.

An AI summary may accelerate scanning and classification, but it can omit context or overstate certainty. Neither an MCP feed nor a spreadsheet export should become the authoritative record of what the programme has accepted.

Assess across the ERP architecture

Every material change should be assigned an owner and assessed against a consistent set of questions.

What business process is affected?

Is the capability optional, automatically enabled or associated with an operational deadline?

Does it affect integrations, extensions, data, reporting, security roles, segregation of duties, regulatory controls or support procedures?

Finance and Supply Chain Management changes rarely remain within a single module.

Consider a warehouse capability affecting mobile execution. What initially looks like a Supply Chain feature could also affect identity, device management, network design, integrations, extensions, operational procedures, testing and user training.

A Finance capability could similarly affect posting controls, reporting, reconciliation, audit evidence or segregation of duties.

Recording “no impact” without identifying who assessed those dimensions is not governance.

Dependencies also need to be explicit: platform updates, Dataverse, Power Platform components, integration patterns, ISV solutions and country-specific functionality can all change the implementation decision.

Decide explicitly

The governance forum should make a clear decision for each material item.

Typical outcomes include:

The decision should include its rationale, accountable owner and target release or review date.

Roadmap status is not a delivery commitment.

“Rolling Out” does not prove availability in every geography, tenant or environment, and a planned date can change.

Internal plans therefore need to distinguish Microsoft's current indication from the programme's approved delivery commitment.

Continuous governance also does not mean continuous production change.

A useful feature may legitimately be deferred because of financial close, peak trading, transformation milestones, regulatory deadlines or insufficient testing capacity.

Continuous governance means continuously making informed decisions about change: not continuously deploying it.

Validate before committing

Before committing to deployment, validate the capability in the context of the organisation's solution.

Confirm documentation, prerequisites, availability and enablement behaviour.

Then test the relevant business scenarios, integrations, extensions, security controls, performance expectations and regression scope.

Validation should be proportionate to risk.

A minor user-interface improvement should not require the same controls as a change affecting inventory valuation, production execution or financial posting.

The governance record should therefore define the evidence required before approval, rather than relying on a generic “testing complete” status.

Deliver through normal release controls

Approved changes should enter the normal delivery process with a target release, implementation owner and acceptance criteria.

Release planning should consider environment sequencing, configuration or data changes, user communication, training, support readiness and rollback or mitigation options.

After deployment, confirm the expected outcome.

That closes the loop between roadmap monitoring and realised business value.

Without it, teams risk measuring governance by the number of roadmap items reviewed rather than the number of controlled, useful changes delivered.

Make the recurring review decision-oriented

A recurring architecture and release review should focus on exceptions and decisions, not reading roadmap entries aloud.

Its inputs should include newly identified roadmap items, status changes, relevant Message Center notices, documentation updates and unresolved assessments.

A large global ERP estate might operate weekly triage with a monthly decision forum. A smaller organisation might combine both every two weeks.

The precise cadence matters less than the operating principle:

Avoid replacing release-wave theatre with automation theatre

Continuous roadmap publication creates an obvious automation opportunity.

Feeds can be aggregated. Changes can be classified. AI can summarise updates. MCP can make roadmap information accessible to agents and other tooling.

Those capabilities can substantially reduce manual scanning.

But automation cannot determine whether a capability fits a customer's control framework, operating calendar, extension strategy or risk appetite.

And it cannot approve a production change.

Treat AI and MCP-enabled monitoring as an analyst assistant: useful for finding, comparing and organising signals, but subordinate to verified documentation, architecture judgement and formal programme decisions.

What should Dynamics 365 programmes do before 15 November?

Before Release Planner retires, I would expect a Finance or Supply Chain Management programme to have done five things:

1. Identify dependencies on Release Planner. Find reports, meetings, bookmarks, processes and controls that currently assume it exists.
2. Establish replacement monitoring. Define the relevant AI at Work roadmap views and Message Center responsibilities.
3. Assign ownership. Decide who monitors, who assesses functional and technical impact, and who has decision authority.
4. Create the continuous governance record. Make ownership, impact, dependencies, decisions, evidence and target releases traceable.
5. Move unresolved decisions into that record before retirement. Do not allow knowledge to disappear with the tool.

The retirement deadline is therefore more than a tooling migration milestone.

It is a useful deadline for testing whether the organisation's release-governance model still matches Microsoft's release-communication model.

The architecture point

The key change is not the loss of a familiar release-wave document.

It is the loss of the assumption that two planning exercises each year are enough.

Dynamics 365 programmes now need continuous awareness without uncontrolled delivery:

And keep the programme: not Microsoft's roadmap, an RSS feed, an AI agent or an MCP server: as the authority for what actually enters your ERP estate.