
// article
Microsoft's Business Central 28.0 release notes set a clear date for online customers: administrators can schedule the update within a five-month update period that ends on August 31, 2026. That makes the remaining work less about reading a feature list and more about proving that the business can operate normally after the update. Microsoft Learn documents the version 28.0 update window and feature changes.
The platform has continued moving during that window. Microsoft's July release notes describe Business Central 28.3 and direct existing customers to schedule it when it becomes available for their environment. The Business Central administration center remains the tenant-specific authority for the latest available version and next update date. Review the current 28.3 release notes before you lock your test target.
An update deadline is not a reason to panic. It is a reason to replace assumptions with evidence.
A technically successful update is only one layer of readiness. A useful rehearsal tests three layers separately:
Platform compatibility: installed extensions can move to the target version without blocking the environment update.
Business behavior: the workflows people depend on still produce the expected documents, postings, approvals, and integrations.
Operating readiness: owners, timing, communications, evidence, and fallback decisions are defined before production changes.
The goal is not to prove that every screen opens. The goal is to prove that the company can complete its critical work.
Open the Business Central administration center and record the current production version, the latest available version, the next scheduled update, the update window, and the notification recipients. Microsoft allows administrators to schedule available or planned versions within the supported update period. The update window must be at least six hours, and users cannot sign in while the environment is being updated. Microsoft's update-management guide explains these controls.
Do not build the plan around an email remembered from last month. Capture the values visible for the actual environment and save a screenshot with the rehearsal record.
Use a sandbox that represents production closely enough to expose real compatibility and process issues. It should include the relevant apps, per-tenant extensions, setup, permissions, integrations, job queues, report layouts, and representative data. Microsoft notes that an existing sandbox can be updated to a preview version so teams can test with installed extensions and familiar configuration. Microsoft Learn describes how preview sandboxes support extension and workflow testing.
For the current version 28 production update, use the target version available to your tenant. Preview environments are useful for future-wave preparation, but they have lifecycle limitations and should not be treated as permanent test systems.
Choose workflows by business impact, not by menu coverage. A typical rehearsal might include:
Quote or order through shipment, invoicing, and customer payment.
Purchase order through receipt, invoice matching, approval, and vendor payment.
Inventory adjustments, transfers, reservations, costing, and replenishment.
Bank reconciliation, recurring journals, allocations, and period-end review.
Role-specific approvals, document output, email delivery, and exports.
For each workflow, define the starting data, expected result, owner, evidence, and pass or fail decision. If a test only says it looks good, it will be difficult to diagnose later. A posted document number, integration log, permission result, or before-and-after total gives the team something concrete to review.
Microsoft warns that a per-tenant extension can conflict with a new base-application version. Microsoft also performs compatibility checks before major updates and notifies registered recipients when it detects issues. Its guidance is to test a corrected app in a sandbox on the new major version and, after successful testing, stage the compatible app for the next major version. See Microsoft's extension-compatibility guidance in the admin-center documentation.
Your review should cover more than compilation. Confirm authentication, API contracts, event subscribers, background jobs, Power Automate flows, email accounts, external storage, document layouts, and reconciliation paths. If an integration fails, the team should know who receives the alert and how to identify records that need replay.
For the development side of the rehearsal, the existing AL extension upgrade strategy guide explains how upgrade codeunits, version metadata, and data migration protect customizations. The customization technical-debt field note can help identify changes that deserve extra scrutiny.
Choose the production date and update window only after the rehearsal has an owner-approved result. Microsoft recommends scheduling the update for a time when the environment can remain inaccessible until the update window ends. Record who monitors the operation, who verifies Business Central after completion, and who communicates with users.
Use exit criteria that can be answered without debate:
CheckpointEvidence requiredOwnerEnvironment targetAdmin-center version and schedule capturedBusiness Central administratorExtensionsCompatibility result and corrected packages recordedAL or app ownerCore workflowsExpected documents and postings verifiedProcess ownersIntegrationsSuccessful transactions plus failure and replay testIntegration ownerProduction windowCommunications, monitoring, and post-update checks approvedBusiness sponsor
No one can name the latest available version for the production environment.
The sandbox does not contain the same critical extensions as production.
Testing covers navigation but not posting, approval, document output, or integration results.
Compatibility warnings are sitting in an unmonitored mailbox.
The update date is selected, but no one owns post-update verification.
A failed integration has no reconciliation or replay procedure.
Any one of these signals is a useful finding. It tells you where to focus before production rather than after users return.
Open the administration center and capture the current version, latest available version, next update, update window, and notification recipients.
Select a representative sandbox and align its extensions and configuration with the workflows you must protect.
Assign one owner for each critical workflow and integration boundary.
Run the rehearsal, store the evidence, and separate blocking defects from follow-up improvements.
Schedule production only after the exit criteria have named approvals.
Business Central's managed update process handles the platform operation. Your team still owns the business proof. A short, evidence-based rehearsal gives administrators, process owners, and developers the same answer to the most important question: are we ready to keep operating after the update?
If your version 28 update is approaching and the extensions, integrations, or test plan are still unclear, book a call to review the readiness gaps with Bitta Apps.