Quick Tip: Almost Every BC Major Release Gets Paused. Are Your Environments Ready?

Microsoft pauses the Business Central major release rollout almost every time.

This is not a bug in the process. It is the process working as designed, and it has been that way since at least 2020. The question is not whether a pause will happen, but whether your environments are in a good position when it does.

This happens almost every time

Looking at the historical record, a rollout pause has occurred with nearly every major release since BC17. A few examples from recent releases, based on the postponed updates history maintained by Dynamics 365 Lab:

• BC28 (2026 wave 1): paused April 14, resumed April 17; paused again May 6, resumed May 11
• BC25 (2024 wave 2): paused October 8, resumed October 11
• BC24 (2024 wave 1): paused April 30, resumed May 6; paused again May 7, resumed May 13
• BC23 (2023 wave 2): paused October 10, resumed November 4
• BC22 (2023 wave 1): paused April 8, resumed April 14; paused again April 20, resumed April 24

For anyone managing production environments on behalf of customers, a pause is a normal part of the release cycle that requires preparation, not just a reaction.

What Microsoft actually does when a pause is called

When Microsoft discovers a critical issue mid-rollout:

• The update rollout state changes to Postponed.
  That status is visible in the Business Central Admin Center, both on the Environments list and on individual environment pages.
• Notification recipients receive an email confirming the pause.
  The email does not include a resume date, because Microsoft genuinely does not know how long the fix will take.

Here is what happens to your environments during a pause:

• Environments not yet upgraded are held in place and rescheduled to seven days after the original update date.
• When the rollout resumes, the update deadline is extended by the number of days the pause lasted, so no scheduling window is lost.
• Environments already upgraded before the pause was called are not rolled back. They stay on the new version with whatever issue triggered the pause.

That last point is the one that matters most. An environment upgraded before a pause is called cannot be protected after the fact.

The structural reason this keeps happening

Business Central SaaS runs across thousands of tenants in dozens of regions, with an enormous variety of per-tenant extensions, localizations, and configurations. Microsoft runs a staged rollout precisely because it is impossible to test every combination in advance.

The staged rollout design means that partners who schedule environments early in the window are volunteering their customers as early adopters. That is rarely the intent, but it is the practical outcome.

Where partners consistently get caught

Three situations account for most of the pain when a pause hits.

• Scheduling production environments too early.
  If you leave the update date at whatever Microsoft proposes by default, your environments will often land in the first wave.
• Not configuring notification recipients.
  The Admin Center banner is passive. You only see it if you happen to log in. The email Microsoft sends when a rollout pauses is the only proactive signal, and it only reaches people if recipients are configured per environment. Without it, you find out when something breaks.
• Skipping sandbox testing.
  Microsoft sends a compatibility warning email before every major update if a per-tenant extension has known issues with the new version. If no recipient is configured, that warning goes nowhere. Even with the warning, partners who have not tested in a sandbox before the production update runs have no baseline to compare against when something goes wrong.

What to do about it

None of this requires exotic tooling. The practical response comes down to three habits applied consistently across every customer environment.

• Schedule production environments toward the end of the update window.
  For Microsoft-localized environments, the window is now up to five months. Use it.
  There is no benefit to upgrading production early. Let the first wave of tenants absorb the risk, and move once the rollout has been running without interruption for a few weeks.
• Configure notification recipients for every production environment.
  Add at least the partner’s project lead and a customer contact. Make sure the sending address no-reply-dynamics365@microsoft.com is not filtered by the customer’s spam rules. This is the only way to get proactive notification of a pause, a resume, or an extension compatibility warning.
• Test in a sandbox before the production update date.
  Create a sandbox from the production environment and update it first. If something breaks, you have time to investigate before the production window arrives. If a pause is called between the sandbox update and the production date, you have already validated the version and know what to expect once the rollout resumes.

The Admin Center mechanics for scheduling updates and managing the update window are covered in detail in How Do I: Manage and Postpone BC Updates in the Admin Center.

The uncomfortable observation

Microsoft’s staged rollout system protects most environments from critical issues, the deadline extension is fair, and the notification system gives partners the information they need.

The problem is that most partners do not configure the system to take advantage of it. Default settings, no notification recipients, and no sandbox testing are far more common than they should be. The tooling to avoid it has been there for years.

That said, not every pause is something you could have prevented.
Microsoft sometimes discovers issues during the rollout itself that no amount of sandbox testing would have caught, because they only surface at scale across the full production infrastructure.

In those cases, the pause is exactly the system working correctly. The goal of good preparation is not to eliminate the risk of a pause. It is to make sure your environments are not in the affected group when one is called.