Business Central Update Testing: Surviving a Monthly Release Cadence

Start with the arithmetic, because it explains most of what follows.

Microsoft ships Business Central two major updates a year, in April and October, and a minor update every other month. That is ten minor updates and two major ones, twelve update events annually, arriving on a schedule that does not pause for your year-end, your busy season or the fact that your finance manager is on leave.

Now the second number. Most Business Central customers are small and mid-sized businesses. There is usually no QA team, no test manager and no automation engineer. There is an IT generalist who also handles laptops and the phone system, a finance lead who knows what correct looks like, and an implementation partner on a support retainer. Between them they are expected to absorb an update event every month.

So the useful question is not how you test a Business Central update. Anyone can test one update. The question is what rhythm a two-person team can hold twelve times a year, indefinitely, without it quietly becoming the thing that gets skipped.

The Actual Cadence, and Why F&O Advice Doesn’t Transfer

Worth setting out precisely, because a surprising number of BC teams have never seen it written down in one place.

That preview row is the most under-used thing in the whole schedule. A full month of advance access to the exact version that is coming, and most BC teams have never spun one up.

Now the comparison that matters. Almost every piece of published Dynamics 365 update-testing guidance is written for Finance & Operations, and F&O is a different animal in three ways that change the advice completely:

• Cadence. F&O teams plan around a handful of service update events. BC teams face one a month. A process that takes two days is fine at F&O frequency and impossible at BC frequency.
• Team shape. F&O customers are large enough to have QA functions, test leads and environments they control. BC customers frequently have neither a tester nor a spare environment.
• Who holds the dependencies? F&O customization is mostly built in-house or by a large partner. BC runs on AppSource apps from third-party ISVs, and that difference turns out to be the one that bites hardest.

So if you have been reading D365 upgrade guidance and finding it unrealistic, the guidance is not wrong, it is written for someone else.

ONE THING THAT CHANGED IN AUGUST 2026 Microsoft retired the twice-yearly release wave announcement model for Dynamics 365, Power Platform and Dataverse, moving to continuous publishing on a single roadmap. It is worth being precise about what that did and did not change: it changed how updates are announced and planned, not how they are built or deployed. Business Central still receives two major updates a year in April and October, and minor updates monthly. What you have lost is the twice-yearly document that told you what was coming, which makes a standing testing rhythm more valuable, not less.

The Five-Month Clock Is a Countdown, Not a Cushion

When a major update ships, you do not have to take it that day. Microsoft gives an update period of five calendar months from general availability, and inside that window an administrator can reschedule to any date they choose. April’s release runs until early September. October’s runs until early March.

Almost every BC team reads that as breathing room. It is more useful to read it as a countdown, because of what sits on the other end of it.

When the five months expire, there is a one-month grace period during which the update can no longer be pushed further out. After the grace period comes the enforced update period, where Microsoft applies the update on its own terms. Along the way, if an update attempt fails, the environment rolls back to its original version and is automatically rescheduled for another attempt seven days later.

There is also a door that closes quietly behind you: once you have successfully updated to a later version, you cannot restore the environment to a version that is in its grace or enforced period. The old version stops being somewhere you can go back to.

The five months are not time you have. They are time you are spending, whether or not you are using them.

The failure pattern is consistent. A team defers in month one with good intentions, defers again in month three because a busy period landed, and arrives in month five with no validated position, no preview testing done, and an update that is now going to happen regardless.

The Sentence in Microsoft’s Documentation Most BC Teams Haven’t Read

Here is what happens in the enforced update period when something in your environment is blocking the update. Microsoft’s own documentation puts it plainly:

“During this period, any extensions causing the update to the next major version to fail, for example, because of compatibility issues, might be automatically uninstalled from the environment so that the update succeeds.”

Read that again with your own customizations in mind. When there is a standoff between the update and your extensions, Microsoft resolves it in favor of the update. The thing that gets removed is yours.

Two qualifications, in fairness. The data belonging to an uninstalled extension is not deleted, and can be recovered by installing a compatible version afterwards. And this only happens at the far end of a timeline that has already given you five months plus a grace period. Microsoft is not doing anything unreasonable, and it is explicit about the expectation: keep apps and per-tenant extensions ready to update at any time, and actively test compatibility.

But notice what that expectation actually requires. “Ready to update at any given time” is not a project you complete. It is a standing state you maintain, which is another way of describing a testing rhythm, and it is the real reason Business Central update testing cannot be an annual event.

Your Dependency Chain Runs Outside Your Building

This is where BC differs most sharply from every other Dynamics product, and where the most avoidable damage happens.

A typical Business Central installation runs several AppSource apps, a payments provider, a document management add-on, an industry-specific module, a shipping integration, alongside per-tenant extensions written by the implementation partner. Each is maintained by somebody else, on their own schedule, with their own view of how urgent your major update is.

Which produces a situation with no equivalent in an in-house customization model: you can do everything right and still be blocked. Your own extensions can be tested, compatible and ready, and if one ISV has not shipped a version compatible with the incoming major release, your update either fails or proceeds by removing their app.

The practical response is unglamorous and works. Keep a written list of every installed app with the vendor’s name and support contact, most BC teams do not have one. Then, in the month before each major update, ask every vendor one question: is your app validated against the incoming version, and if not, when? Ask in March and September, when the preview environment appears. An ISV who cannot answer that in the preview month is the single best predictor of an update problem you will get.

Then test the combination rather than the parts. Each app can be individually compatible and still conflict with another in your specific configuration how business central extensions break each other, which is a whole subject of its own, and one worth understanding before a major update rather than during one.

What Actually Needs Testing, and How Often

The instinct when facing twelve update events is to build one regression pack and run it every time. It does not survive contact with reality: a suite thorough enough for a major update is too slow to run monthly, and one fast enough to run monthly is too thin for April and October.

Two tiers, with different jobs.

Monthly minors: the confidence check

Minor updates carry fixes and regulatory changes, not new functionality. The risk is narrow but real, regulatory changes touch tax, VAT and reporting, which is exactly where a silent error is expensive.

What you want is a thin, fast pass over the transaction spine: the handful of flows the business cannot operate without. For most companies that is sales order to shipment to posted invoice to the general ledger entry, the equivalent path on the purchase side, and whatever your regulatory reporting produces. Twenty to thirty scenarios. It should confirm the money ends up in the right place, not that the screens look right.

Major updates: the full pass

April and October need everything the monthly check does, plus the things only a major update disturbs: every extension in combination, the integrations in and out of BC, the reports and documents that finance depends on, permission sets, and anything running on functionality Microsoft has flagged as deprecated.

This is what the preview environment is for. Running the full pass in March and September against the incoming version converts the major update from an event into a confirmation.

One principle underneath the table: assert against the data, not the screen. A test confirming that a posted sales invoice produced the correct general ledger entries tells you the business is intact. A test confirming that a success message appeared tells you a message appeared. Business Central’s interface moves constantly across twelve updates a year, and tests tied to its surface will spend their lives being repaired.

Building a Rhythm Two People Can Actually Hold

Here is the constraint that decides whether any of this happens, and it is not a technical one.

If validating a minor update takes two days, it will not survive to month four.

Not through negligence. Through arithmetic. Two days a month is twenty-four days a year from a team that does not have twenty-four spare days, so it gets shortened, then deferred, then skipped for a quiet month, and by the following spring nobody has validated anything since the last major update, which is the state most BC teams are actually in, whatever the plan says.

So the monthly check has to be cheap enough that running it is not a decision anybody makes. Under an hour, unattended, scheduled, with results that explain themselves. At that cost it survives busy periods, holidays and the month everything went wrong, because nobody has to choose to do it.

That single constraint drives every other choice. It rules out manual regression, because manual regression cannot be cheap. It rules out any automation that needs repair when a screen changes, because the repair cost is the real cost and BC changes screens twelve times a year. What is left is testing that runs itself and does not break when the interface moves.

How Sofy Handles the Business Central Cadence

Sofy’s Dynamics 365 test agents approach is built around exactly that constraint: the monthly check has to cost almost nothing to run.

Tests are expressed as business outcomes, not click paths. You describe what should be true, a posted sales invoice creates the correct GL entries, a VAT calculation produces the expected figure for each tax group, and the agent works out how to verify it in Business Central as it stands today. Twelve interface changes a year stop being twelve rounds of test repair, because no click path was ever stored.

Validation happens at the data layer. The check confirms the ledger entries, the tax figures and the document flow rather than the screens that display them, which is both a better test and one that survives a UI change in self healing test automation.

The monthly pass runs unattended. Schedule it against the update, and it reports what changed rather than requiring somebody to sit and watch. Under an hour, no decision required, which is the whole point.

The preview month becomes usable. Point the same set at the preview environment in March and September and the major update stops being the event it currently is. Coverage is available against the new version before zero-day validation arrives rather than after it breaks something.

What this does not replace

Three things, stated plainly. AL test codeunits still belong in your extension development, unit-level testing of your own code is a different job. Your partner’s upgrade work on per-tenant extensions is still their work. And genuinely new functionality in a major release still needs a human to decide whether it does what the business wants, because no test can tell you whether a feature is a good idea. What automated update testing removes is the repetitive confirmation that everything which worked last month still works, which is most of the effort and none of the judgement.

Frequently Asked Questions

How often does Business Central update?

Two major updates a year, in April and October, plus a minor update every other month, ten minor updates annually. Major updates bring new functionality and remove previously deprecated code; minor updates carry fixes and regulatory changes. Preview environments for each major release become available roughly a month ahead, in March and September.

How long can you postpone a Business Central update?

The update period runs five calendar months from general availability, and an administrator can reschedule to any date within it. After that comes a one-month grace period where the update can no longer be deferred, and then an enforced update period where Microsoft applies it. April releases run until early September; October releases until early March.

Will Microsoft really uninstall my extensions?

In the enforced update period, yes, Microsoft’s documentation states that extensions causing the update to fail might be automatically uninstalled so the update can succeed. The data is not deleted and can be recovered by installing a compatible version afterwards, but the app stops running. This is the end of a long timeline rather than a surprise, and the way to avoid it is to keep extensions continuously ready rather than dealing with compatibility at the deadline.

Do we need to test every monthly update?

Yes, but not thoroughly. Minor updates carry fixes and regulatory changes, so a thin pass over the transaction spine and anything tax or reporting related is enough, twenty to thirty scenarios confirming the money lands correctly. Reserve the full regression for April and October. The test that matters is whether the monthly pass is cheap enough to survive a busy month; if it takes days, it will not.

What is the difference between BC upgrade testing and update testing?

In practice the terms are used interchangeably, though “upgrade” more often refers to major version moves, April and October, or a migration from on-premises NAV, while “update” covers the monthly minors as well. The distinction that actually matters is not the word but the depth: major versions remove deprecated code and change platform behavior, so they need the full pass; minors need a fast confidence check.

Is update testing our responsibility or our partner’s?

It depends entirely on your agreement, and this is worth confirming rather than assuming, a common and expensive discovery is that both parties believed the other was covering it. Partners typically handle per-tenant extension compatibility and the upgrade itself. Validating that your business processes still produce correct results is usually the customer’s, because only the customer knows what correct looks like. Automating that half also makes the partner conversation easier, since you arrive with evidence rather than a suspicion.

The Bottom Line

Business Central’s cadence is not going to slow down, and the five-month update period is not the cushion it appears to be. At the end of it, the update happens on Microsoft’s terms, and anything of yours that stands in the way can be removed so that it can proceed.

None of which is a crisis if extensions stay continuously ready and the monthly check is cheap enough to survive a bad month. It becomes a crisis when validation is treated as a project that happens twice a year, because twelve update events a year will always outrun a twice-yearly habit.

The practical test is not whether you have a testing process. It is whether your process would still be running in month nine. If the honest answer is no, the cost of the check is the thing to fix, not the discipline of the people who keep skipping it.