Business Central or F&O — the update cadence, and what…

Business Central or F&O — the update cadence, and what each costs you in change management

Both Dynamics 365 ERPs take a major update in April and October. That is where the similarity ends — one model hands the admin a five-month window and a cancel button, the other hands you seven calendar days and no rollback.

This is for the CIO or IT director costing the two options, or running both.

The claim: the same two months, a completely different contract

Cadence is usually the last line on the comparison slide, right after the licence cost. It belongs near the top, because it determines how many people you need on the payroll to keep the thing current. Every cell below is quoted or read directly from Microsoft's pages.

**Major updates a year** — Business Central: "two major update cycles per year, with major releases every April and October" · Finance & Operations: "There are two major updates each year: the April update and the October update."
**Everything else** — Business Central: "Minor updates are released every month in which there's no major update release, that is, every month except April and October." · Finance & Operations: Four service updates a year total: "Service updates are released only in February (December self-update), April, July, and October."
**Who picks the date** — Business Central: The admin. "Administrators can reschedule the update to any date within the update period." · Finance & Operations: Microsoft, from your configured window: "customers can choose between two autoupdate windows that occur four weeks apart"
**How long you can defer a major update** — Business Central: "The update period lasts for five calendar months", then a one-month grace period · Finance & Operations: One pause: "The maximum number of consecutive updates that can be paused is reduced from three to one."
**The mandatory floor** — Business Central: Grace period ends, then the enforced update period begins · Finance & Operations: "Customers can take up to four service updates per year and are required to take a minimum of two per year."
**Testing window Microsoft gives you** — Business Central: The whole update period, on a sandbox you create from production · Finance & Operations: "You have seven calendar days for validation after the update is applied to your sandbox environment."
**Can you stop it once it starts** — Business Central: Yes. "Canceling a running update stops the update process and restores the environment to its state immediately before the update started." · Finance & Operations: No. "As with other code promotions, rollbacks can't be done after a service update is applied."
**What breaks first** — Business Central: Extensions. Incompatible ones "might be automatically uninstalled from the environment so that the update succeeds" in the enforced period · Finance & Operations: Nothing, by design: "Service updates are backward compatible, and new experiences are configurable."
**Where you manage it** — Business Central: Business Central administration center · Finance & Operations: Lifecycle Services

Two rows deserve reading twice. Business Central can cancel a running update and roll the environment back. F&O cannot — and its compatibility promise is the reason it does not need to. The trade is a stronger guarantee in exchange for a much shorter window.

The version numbers do not cross-walk, and here is why

This gets asked in every dual-ERP estate. The two schemes encode different things.

**Business Central** — What the parts mean: Major number increments once per release wave; the second number is the monthly minor · July 2026, as published: 28.3 — "Application Build 28.3 Platform Build 28.0", availability July 2026, documented as "Update 28.3 for Business Central 2026 release wave 1"
**Finance & Operations** — What the parts mean: The 10.0 prefix does not move; the third component increments once per service update, four times a year · July 2026, as published: 10.0.48, labelled "CY26Q3: 10.0.48" — first autoupdate production start date July 3, 2026

So in the same calendar month one estate is on 28.3 and the other on 10.0.48, and neither number tells you anything about the other. Business Central's major number does track the wave; F&O's does not track anything except its own sequence, and Microsoft's label for it — CY26Q3 — encodes a calendar quarter.

Two more asymmetries. The release plan puts the two products in different branches of the same document — Business Central under smb, finance and operations under enterprise-resource-planning. And the Business Central release plan for a wave names no version number at all: the 2026 release wave 1 page says only that it "lists features that are planned to release from April 2026 through September 2026", with Microsoft's warning that "delivery timelines may change and projected functionality may not be released".

One live example, on Microsoft's own page today: the Business Central What's new or changed article lists 28.1, 28.2 and 28.3 under 2026 release wave 1, while the release-plans link on the same page is labelled "Current wave: 2025 release wave 2". Read the version table, not the wave label.

Who controls the date — the real difference

Business Central's model is a calendar you own. The update period "starts when a new major version is generally available (GA), typically the first workday of April and October" — keep the typically — and lasts five calendar months, "ending in early September for update periods that start in April, and in early March for update periods that start in October". Inside it you pick any date, and you set the window: "The update window must be a minimum of six hours".

Then it tightens twice. In the grace period — one month — "you can't reschedule an update to a later date or to a target version within the environment's current major version." After that, the enforced update period, where extensions that block the update "might be automatically uninstalled from the environment so that the update succeeds", and where updates "can't be canceled".

F&O's model is a window Microsoft owns. You configure the maintenance day and time in Lifecycle Services; Microsoft applies the update to the designated sandbox, and "You have seven calendar days to do testing and validation before the production environment is updated." The other sandboxes get no window at all — "All other sandboxes are automatically updated on the same day as the production environment."

The testing burden is a different shape, not a different size

Business Central gives you months of calendar and a preview you cannot test your data on. The preview period for regular tenants "starts a month before the release of the new major version, that is, every March and September" — but "The newly created preview sandbox environment contains demonstration company data. Trying the preview on a copy of your current production data is not yet supported; nor is testing the upgrade from your current version to the preview." Testing on your own data starts after general availability, when you copy production to a sandbox and update that.

F&O gives you a production-shaped sandbox and one week. The designated Tier-2/UAT (user acceptance testing) sandbox is updated seven days before production, and Microsoft's answer to the compression is a recorded regression suite: "We recommend that you use tools such as the Regression suite automation tool (RSAT) for regression testing."

Both run a compatibility check, and on Business Central Microsoft says what that check is *not*: "Microsoft tests code based on technical compatibility. As the publisher, you're still responsible for all functional and logical validation."

What each cadence costs you in change management — ours, not Microsoft's

Everything above is Microsoft's. This section is our assessment — argue with it rather than defer to it.

**The scarce resource** — On Business Central: Extension custody. The calendar is generous; the thing that fails is code you or a partner published · On Finance & Operations: Calendar. The compatibility promise holds; the week does not stretch
**Who has to be available** — On Business Central: A developer who can rebuild an extension, across five months · On Finance & Operations: A test team that can clear a regression pass inside seven calendar days, four times a year
**The failure you actually get** — On Business Central: An update that fails on an incompatible extension, auto-rescheduled seven days later, repeating until someone fixes the app · On Finance & Operations: An update that lands and cannot be taken back, so the response is forward-only
**The clock nobody schedules for** — On Business Central: Marketplace apps "might be removed from Marketplace 30 days after the release of that version", and a blocker to a critical security update "might be uninstalled within 14 days" · On Finance & Operations: The second autoupdate window, four weeks after the first — which for 10.0.49 starts November 1, 2026, outside the four months Microsoft names for autoupdates
**The right unit to budget in** — On Business Central: Developer days per wave · On Finance & Operations: Test-suite maintenance, continuously

The one-line version: Business Central buys you time and charges you in code custody. F&O buys you compatibility and charges you in calendar.

Where this goes wrong

Costing Business Central's five months as slack. It is only slack if your extensions are already compatible. The grace and enforced periods exist because, for many tenants, they are not.

Treating F&O's seven days as the test plan. It is the calendar the test plan has to fit inside. If a regression pass takes longer than a week, the model is telling you to make the pass repeatable, not to ask for more days.

Running one governance process across both. Business Central's risk is a publisher who stopped maintaining an app. F&O's risk is a week of validation capacity in February, April, July and October. Different people, different escalation paths.

Assuming Business Central's cancel is a costless undo. It restores the environment, but the restore "might take more than an hour" on a large database, and it is unavailable once the enforced update period starts.

Where we would draw the line

We would not put an optimization app's release cycle on the ERP's cadence on either platform — the point of surrounding the ERP is that our release train and yours stay separate. We would not accept a Business Central estate where nobody can name the publisher of every installed extension, because that list is the update risk register. And we would not sign an F&O change freeze spanning more than one pause window, because the next update is not optional.

Dynamics 365 manages the update on both platforms, and manages it well. Deciding what it costs you — and which of your decisions are sensitive to a version moving under them — is the part it leaves to you.

About Cognilium Cognilium is the AI optimization layer for Dynamics 365 — complementary apps that optimize the pricing, inventory, warehouse and planning decisions your ERP manages but can't optimize. Built on Power Platform, Dataverse and Azure. https://cognilium.ai · https://www.linkedin.com/company/37180269/

Count the installed extensions on your Business Central estate whose publisher you cannot name, or the hours your last Finance & Operations regression pass took. Book a fifteen-minute call and we will walk the number with you, live — no deck. https://cognilium.ai

Business Central or F&O — the update cadence, and what each costs you in change management