How Do I: Manage and Postpone BC Updates in the Admin Center

BC28 is rolling out. That is fine, mostly. What is less fine is what happens to an environment that gets upgraded to a version Microsoft then discovers has a critical issue. The rollout stops. The fix takes days, sometimes longer. Environments still on the previous version are protected. Environments that were already upgraded are stuck.

This is not a theoretical edge case. Microsoft paused the BC28 rollout shortly after it started. If you manage Business Central environments for customers, understanding how to control the update schedule in the Admin Center is not optional reading.

How the update rollout works

Business Central SaaS environments receive two major updates per year, in April and October, plus monthly minor updates. Microsoft does not push all environments at once. The rollout is staged across regions and tenants over several weeks, which gives you a window to control when your environments actually update.

When Microsoft discovers a critical issue mid-rollout, they pause it. What that looks like in practice:

A banner appears in the Admin Center, both on the Environments list and on each individual environment detail page
The banner states that updates to the current version are temporarily postponed
No status field or label changes on the environment itself. The scheduled date and target version stay exactly as they were
Environments scheduled to update during the pause are held and rescheduled to seven days after the original date
When the rollout resumes, the update deadline is extended by the number of days the pause lasted

The same banner appears when you open an individual environment, alongside the full update picture: current version, latest available version, scheduled update date, and the deadline for the major update.

The important consequence: an environment that was already upgraded before the pause was called does not get rolled back. It stays on the new version with whatever issue triggered the pause. That is the situation you want to avoid for production environments, and the main reason to schedule updates toward the end of the allowed window rather than the beginning.

Setting up notification recipients

The banner in the Admin Center is passive. You only see it if you happen to log in. The email Microsoft sends when a rollout is paused is the only proactive signal, and it only reaches people if notification recipients are configured.

When a rollout is paused, the email explains exactly what happened and what to expect: the environment will not update automatically, and the update will be rescheduled to seven days after the originally scheduled date. Without that email, you find out when the update runs at the new date, or you do not find out at all until something breaks.

To configure notification recipients, go to the Notification Recipients tab in the left navigation of the Admin Center. Add at least one recipient per production environment.

Microsoft sends notifications for the following events:

A new version becomes available for the environment
An update is scheduled
An update succeeds or fails
A rollout is paused or resumes
A per-tenant extension has compatibility issues with an upcoming version

That last one is worth highlighting. Microsoft checks extension compatibility before every major update and sends a warning email if issues are detected. If no recipient is configured, that warning goes nowhere and the first signal is an update failure.

Notification emails come from no-reply-dynamics365@microsoft.com. Make sure that address is not caught by spam filters, particularly in organizations with strict email policies.

Scheduling an update

In the Business Central Admin Center, open an environment and look at the Update Settings section. Two things are configurable from there.

The update window defines the daily time slot during which Microsoft is allowed to apply updates. To set it:

Select Update Settings in the action bar, then Set update window
Specify the time zone, start time, and end time
The window must be at least six hours
Set it outside business hours; this applies to all updates, major and minor

The scheduled update date is controlled via the Modify link next to the Next Update field. This opens the Schedule Environment Update pane, where you pick a target version and a date. A few things worth knowing:

You can target any version higher than the current one within the allowed update period
You can select a planned version that is not yet released; Microsoft will not schedule the update until that version ships
If you select today’s date but the update window has already passed, the update starts the following day within the next window
To delay as long as possible, pick a date close to the deadline shown in the Update to next major before field

The update window

Since BC25, Microsoft-localized environments have up to five months to schedule a major update. Partner-localized environments have a shorter window of roughly 60 days. Check which applies to each environment before assuming you have the full five months.

What you can control, and what you cannot

You can delay. You cannot skip. Every environment will eventually reach the new major version. Beyond that:

If your scheduled date falls during a Microsoft-initiated postponement, the update does not run and is rescheduled to seven days after the original date
If an update fails due to an incompatible per-tenant extension, Business Central restores the environment to its previous version and reschedules for seven days later
You can move a rescheduled date earlier once the issue is resolved, but not beyond what Microsoft allows
If an extension remains incompatible past the 90-day grace period, Microsoft updates the environment and uninstalls the extension

The practical recommendation

Schedule major updates not immediately when the update becomes available! Waiting a few weeks/days after GA does not mean running outdated software. It means not being the test cohort for production issues.

As a checklist for every production environment you manage:

Configure at least one notification recipient
Verify the update window covers a safe maintenance period outside business hours
Set the scheduled update date deliberately, do not just accept whatever Microsoft proposes
Check the Admin Center banner periodically during active rollout periods

More information

One last thing: this is not a BC28 anomaly.

Postponed rollouts have been a recurring pattern since Business Central SaaS launched. Almost every major release has had at least one pause. The tooling to manage it has been there from the start. Most partners just do not think about it until they are on the phone with an unhappy customer explaining why production is misbehaving on a version Microsoft stopped rolling out two days ago.