Dynamics 365 Release Waves Are Ending: What That Does to Your Regression Testing Calendar

What Microsoft actually announced

On 25 August 2026, Microsoft said it was retiring the twice-yearly release wave 1 and release wave 2 model across Dynamics 365, Power Platform and Dataverse, in favour of continuous publishing. Instead of grouping announcements into two annual sets, it will publish new capabilities as soon as plans are committed and ready to share.

The mechanics matter more than the branding. Three dates carry them:

Features on the new roadmap move through three published stages, In Development, Rolling Out and Launched, and can be filtered by product, exported and followed by RSS. Microsoft's stated reason is pace: the impact of AI, it says, is driving technological change faster than before. For Business Central, Microsoft's own documentation now notes that features are no longer linked to release plans.

What has not changed: the updates still arrive

This is worth being precise about. Nothing here slows Business Central down or makes its updates unpredictable.

Update 29.0 is in public preview from the first week of September 2026 and is scheduled to become generally available in the first week of October. Microsoft automatically deletes preview sandbox environments 30 days after that. Minor updates continue to land monthly. The version train runs exactly as it did.

The checkpoint nobody admitted they were using

Here is the uncomfortable bit for implementation partners. A great many BC practices never had a formal regression policy. What they had was a release wave, and the wave did the work a policy would have done: it produced a document with a date on it, the document generated internal review, the review generated a client conversation, and somewhere in that sequence a regression pass got scheduled. The cadence was inherited, not designed.

Take the document away and the sequence does not fire. As ERP Today put it, governance calendars lose a built-in checkpoint. Continuous publishing is better for visibility and worse for anything that relied on a shared deadline to get attention. Regression testing on a managed BC estate relied on exactly that.

The failure mode is not dramatic. It is a practice that ran two regression passes a year without ever calling them that, and next year runs none because nothing turned up to start the conversation. Nobody decides to stop testing; the prompt just goes missing. We have written before about what regression testing is actually for.

Replacing a calendar you did not build

The work is small, and mostly about deciding explicitly what used to happen by accident.

Anchor your cadence to the version train, not the announcements. BC still has major updates and monthly minors, and those are dates you can diarise today without waiting for a plan. A regression pass against each major update, timed to the preview window rather than after general availability, gives you back the rhythm you were getting for free, and the preview sandbox is the place to run it.

Give someone the monitoring job by name. Continuous publishing only works if somebody reads it. Subscribe to the roadmap RSS feed, keep Message Center digests on, and put a recurring monthly review in one named person's diary. An unowned feed is a feed nobody reads.

Have a regression pack that survives between passes. This separates practices that will cope from those that will not. If the scope is rebuilt from memory and a spreadsheet each time, running it costs enough that a missing prompt is all it takes to skip it. If the suite already exists, is assigned and reports coverage, the pass is a scheduling decision rather than a project. That is the reason spreadsheet-based tracking breaks down on repeat work.

Test the behaviour, not the release notes. The wave document was never a test plan. It told you what was new, not what had moved underneath your customisations, and a continuous feed will not either. Your own Business Central test scenarios are what find the regression.

There is a commercial angle too. A partner who can say "we validate your environment against every major update on a defined schedule" is describing a retainer. One who tested whenever Microsoft published a document is describing a habit, and habits are not billable.