The release plan never told you what your upgrade would break. It listed what Microsoft changed, feature by feature, and left the mapping to your processes as an exercise. A team that scoped Business Central upgrade testing from that list tested Microsoft's work. The processes your own tenant runs got tested only if someone remembered them.
That list has now stopped. The update 29.0 page on Microsoft Learn (2026) says: "Starting in September 2026, Microsoft stops publishing release plans." Existing plans remain available "for historical reference until further notice." A regression plan that began by walking the release plan has no input left.
A tenant-derived regression scope is a ranked list of the business processes your Business Central tenant executes, ordered by transaction volume, financial value and the named person who owns each outcome, with every process mapped to the extensions, integrations and scheduled jobs it depends on. The upgrade test plan runs down that list until the time budget runs out.
Why release-plan scoping misses what your tenant runs
A release plan is organized by Microsoft's product areas. The 29.0 what's-new page lists its features the same way: Finance, Supply Chain Management, Reporting and data analysis, Service and platform, one row per feature with an availability status. Your tenant is organized by process. The overnight sales invoice posting. The EDI order import. The month-end close. The approval chain on purchase orders above a limit. No row on Microsoft's list says which of those a feature touches, because Microsoft has no view of your extensions, your integrations or your posting volumes.
| Attribute | Release-plan scoping (vendor view) | Tenant-derived scoping (your view) |
|---|---|---|
| Unit of listing | A Microsoft feature, grouped by product area | A business process, grouped by outcome |
| Knows your extensions | No | Yes, from Extension Management and web service telemetry |
| Knows your volumes | No | Yes, from posted document counts and call counts per endpoint |
| Names an owner | No | One person per row; a row with no name is a finding |
| Path to a test script | You translate each feature into your processes first | Each row is already a process with a result to check |
| Source after September 2026 | Frozen: new capabilities go to the AI at Work roadmap | Unchanged: the inputs sit in your tenant |
Take one line from the 29.0 page. Under "Optional features now mandatory" sits "Feature: Disable SOAP web services on Microsoft UI pages." The line tells you nothing until someone answers which of your systems call a SOAP endpoint built on a UI page, who owns each one, and how often it fires. Your tenant can answer that. The Web Services Call trace (event RT0008) records the endpoint type, the endpoint and the extension behind it, and a separate "Deprecated endpoint called" event (RT0053) carries the example message "SOAP webservice on UI page by Microsoft publisher" (Microsoft Learn, 2026). Both require the environment to send telemetry to Application Insights. If yours does not, that gap is your first finding.
What replaces the Business Central release plan
Microsoft's answer to the retirement is a set of vendor-side feeds. The AI at Work roadmap carries new capabilities. The what's-new page for each update lists what shipped, and every feature row on the 29.0 page carries a Roadmap ID that links to its roadmap entry. The preview sandbox, available a month before a major release, lets you check extension compatibility. Each feed answers a question about Microsoft's product. None answers a question about yours.
The Release Planner site carries two lines to read before you cite anything from it: "Release Planner retires by November 15, 2026" and "content shown here reflects information as of September 1, 2026." Treat anything you copied from it as a snapshot dated September 1, 2026.
Use the feeds at step 5 of the method below, as lookups against a list you built from your own tenant.
Business Central preview sandbox: what it can test and what it can't
Microsoft's update-cycle documentation (Microsoft Learn, 2026) draws the line. A preview sandbox "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." The preview supports exploring new capabilities and validating that per-tenant extensions still work. It disappears 30 days after the official release.
Your own data meets the new version only after the update reaches your environment. Microsoft's instruction for that moment: copy production to a sandbox, schedule the update on the sandbox for the current date, and set "Allow the update to run outside the update window" to Yes.
The calendar around that step is fixed. For 29.0, the what's-new page says existing customers are notified when the update is available and admins can schedule it "to any date within the five-month update period, which ends in February 2027." A one-month grace period follows. Then comes an enforced period in which extensions that make the update fail "might be automatically uninstalled." Your test window is the stretch between the sandbox copy and the date you schedule production. Scope has to be settled before that window opens, and nothing Microsoft publishes settles it.
Business Central upgrade regression testing: the tenant-derived method
Seven steps. Steps 1 to 4 need only production and can start before the update is available.
- Inventory what runs. In production, list the installed per-tenant extensions and Marketplace apps (Extension Management), the published web services (Web Services) and the scheduled work (Job Queue Entries). If telemetry reaches Application Insights, add RT0008 call counts per endpoint and extension. One row per process, integration or job.
- Rank by volume. Count posted documents per type per month and calls per endpoint. The process that runs most often goes first, because a defect there repeats fastest.
- Re-rank by value. Lift any low-volume process that moves large sums or carries a statutory deadline: a payment run, the month-end close, a tax submission. Volume and value disagree. Both belong above the line.
- Name the owner. Each row gets one person who can look at a result and say it is right. A row with no name cannot be signed off, so it gets an owner before it gets a test.
- Map dependencies. For each row, list the extensions, integrations and jobs it needs, then look each one up against the what's-new page for the target update and the AI at Work roadmap. Microsoft's feed enters the method here as a lookup, not as the scope.
- Script from the top. Turn the highest-ranked rows into repeatable scripts. Page Scripting, which reaches General Availability in 29.0, records and replays a user's path through the client. The same release lists GA tooling to run AL tests from command-line and CI/CD workflows and to build data-driven AL test suites, which covers extension code. Rows below the cut line get a smoke check and an owner who accepts the cut.
- Run it on the copy, sign it by owner. Execute against the sandbox copy of production once the update is available. Each owner signs their row. The admin schedules production when every row above the line has passed.
Microsoft can tell you what changed. Only your tenant can tell you what you run. Every row above your cut line traces back to the second half of that sentence, and the release plan only ever supplied the first.
Business Central update 29.0 worked against a tenant inventory
Five rows from the 29.0 what's-new page show how step 5 works. The right column is the question your inventory has to answer before the sandbox copy exists.
| 29.0 item (Microsoft's what's-new page) | Where your tenant records the answer | Question to settle before the sandbox copy |
|---|---|---|
| Disable SOAP web services on Microsoft UI pages (now mandatory) | RT0008 trace (category SOAP) and RT0053 "Deprecated endpoint called" event | Which external systems call a SOAP endpoint on a Microsoft UI page, how often, and who owns each integration? |
| Base application no longer includes several objects marked obsolete in earlier versions (listed in the page's on-premises notes) | Extension Management and your partner's dependency list | Does any extension you run reference one of those objects, and does a compatible version exist? |
| Improve purchase order matching in Payables Agent (GA) | Whether the agent is enabled in your environment; monthly purchase invoice volume | If it is on, which vendor invoice volume flows through it, and who signs the posted result? |
| Four Supply Chain Management items covering subcontracting, manufacturing documents and capacity calendars | Production order and subcontracting purchase order counts per month | Do you subcontract at all? If so, who owns the production order and the purchase order that follows it? |
| Faster data loading with improved data model for table extensions | Extension list: which extensions add fields through table extensions | Which posting routines and reports read those tables, and who signs their output? |
Who receives the Business Central update notice
The method assumes someone hears that the update is coming. Microsoft emails the notification recipients on the tenant when an update is available, scheduled or failed. The list holds up to 100 addresses, a person maintains it by hand, and Microsoft's page says you must verify the emails are not redirected to a spam folder. They come from [email protected] (Microsoft Learn, 2026).
A failed update restores the original application version and reschedules itself for seven days later. Microsoft's own wording on who hears about it: "If no notification recipient is set up, then no email is sent."
An extension that blocks the update runs a longer clock. Microsoft's typical timeline is 10 weeks of emails, six weeks of in-product notifications and one month of more explicit in-product notifications. After that, Microsoft typically starts "force-uninstalling apps, including per-tenant extensions." Data isn't deleted, and the process the extension carried stops anyway. Microsoft's web service troubleshooting table lists uninstalling or updating an app as a cause when an endpoint that used to work starts returning 404. For an integration, that is what a forced uninstall looks like from the outside.
Open the notification recipients list in the Business Central admin center and check it for the name of whoever decides when production updates. If that person is absent, the signal that starts the whole sequence lands with someone who cannot act on it. The gap between a signal and the person who acts on it is what the Decision Latency Diagnostic scores in 12 questions.
Frequently asked questions
How do you scope Business Central upgrade regression testing?
Start from the tenant, not the vendor's change list. Inventory the extensions, web services and job queue entries in production, rank each process by monthly volume, re-rank by financial value or statutory deadline, and give every row a named owner who can sign the result. Map each row's dependencies against Microsoft's what's-new page for the target update. Run scripts top-down on a sandbox copy of production once the update is available, and let the owners sign before the admin schedules production.
Can you test a Business Central upgrade in a preview sandbox with production data?
No. Microsoft's update-cycle documentation says a preview sandbox contains demonstration company data, and that 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. You can use it to explore new capabilities and to validate per-tenant extensions. Preview sandboxes are removed 30 days after the official release. To test with your own data, copy production to a sandbox once the update is available, schedule the update on the sandbox for the current date, and set 'Allow the update to run outside the update window' to Yes.
What replaced the Business Central release plan?
Per Microsoft's update 29.0 page, starting in September 2026 Microsoft stops publishing release plans, and new Business Central capabilities are published to the AI at Work roadmap. Existing release plans remain available for historical reference until further notice. The Release Planner site states that it retires by November 15, 2026. The 29.0 what's-new page lists each feature with a Roadmap ID that links to its roadmap entry. None of these tells you which of your own processes a change touches.
What happens when an extension blocks a Business Central update?
Microsoft pauses the update and sends a notification. Its typical timeline is 10 weeks of emails to the notification recipients, six weeks of in-product notifications, and one month of more explicit in-product notifications. If the problematic app is still installed, Microsoft typically starts force-uninstalling apps, including per-tenant extensions. Data isn't deleted and can be recovered by installing a compatible extension version after the update succeeds. A failed update restores the original version and reschedules for seven days later.