Testing Dynamics 365 updates: four service updates a year, seven days to validate, and life after RSAT

Nobody upgrades Dynamics 365 in the old sense any more. Microsoft updates it for you, on a calendar Microsoft sets. That removes the five-year upgrade project, and it replaces it with something harder to staff: a regression cycle several times a year that has to finish before production changes underneath you. This guide covers what that calendar looks like today for Finance and Supply Chain Management and for Business Central, the rules that decide how much room you have, and what to do about RSAT before its support ends.

Finance and Operations: four updates, one pause, seven days

Microsoft releases four service updates a year for the finance and operations apps, with auto-updates in February, April, July and October^[1]. The cadence dropped from seven releases to four starting with 10.0.39, the April 2024 release^[2]. You can pause one update at a time, and you must take at least two a year^[1],[3]. Each release now has two auto-update windows, four weeks apart; to pause a release you must pause both windows, because pausing the first does not pause the second^[3].

Here is the published schedule for the next four releases. Microsoft marks these dates as subject to change.

Source: Microsoft’s targeted release schedule^[1]. Three rules in Microsoft’s FAQ shape your test plan more than the dates do. First, the designated UAT sandbox is updated seven days before production, and that is your validation window if you wait for the auto-update^[2]. Second, there is no rollback once a service update is applied^[2]. Third, major updates come in April and October; breaking changes are announced 12 months ahead and new features stay opt-in for 12 months^[2].

The pause rules have teeth. Only the Lifecycle Services project owner can pause, a pause has to be set at least four hours before downtime, and you cannot pause at all if any sandbox or production environment has fallen too far behind^[3]. Microsoft grants extra pauses only for a confirmed Microsoft bug with no workaround. Issues in ISV solutions, partner customizations or other non-Microsoft components do not qualify^[3]. In practice, your ISVs are part of your regression scope whether or not their contract says so.

Business Central: two majors, a five-month window, then enforcement

Business Central online gets two major updates a year, in April and October, and minor updates in the other months^[4]. Preview sandboxes appear about a month before each major update, with demo data only; they are deleted 30 days after general availability^[4]. Version 29.0, which started 2026 release wave 2, can be scheduled anywhere in a five-month update period that ends in February 2027^[5].

After the update period comes a one-month grace period, then an enforced period in which Microsoft may uninstall extensions that block the update, so the update succeeds^[4]. Microsoft “strongly recommends” testing critical scenarios before production is updated, and its recommended method is to copy production to a sandbox, update the sandbox first and test there^[4].

One trap for testers: a sandbox copied from production is not production. Business Central stops the job queue, turns off agents, disables integration setups such as the CRM and Dataverse connections, and blocks outbound HTTP calls from extensions by default^[10]. A test that passes there may never have called the bank. Decide which integrations you re-enable for each cycle and write it down.

A note on terminology. Microsoft stopped publishing Dynamics 365 release plans in September 2026 and now publishes upcoming capabilities on its AI at Work roadmap^[5]. Business Central still labels 29.0 “2026 release wave 2”, but plan your testing from the Business Central update cycle and the Finance and Operations release schedule, not from release-plan PDFs.

RSAT has an end date

For years the default answer to “how do we regression test service updates?” was RSAT: functional users record tasks with Task recorder, and RSAT converts the recordings into automated tests stored in Azure DevOps, with parameters kept in Excel^[6]. Microsoft has now marked RSAT for deprecation; it will not be supported after May 15, 2027^[6]. Microsoft has not named a direct replacement in its RSAT documentation.

A second change compounds the first. Finance and Operations administration is moving from Lifecycle Services to the Power Platform admin center, and several Lifecycle Services features are not carried over, including the Business process modeler and the Task recorder library (Microsoft’s guidance is to save files locally)^[7]. Teams that kept their only copy of RSAT recordings in a BPM library should export them now.

Treat the exit as a project with a date, not a tool swap:

1. Inventory every RSAT test case and Task recorder recording: process, owner, last run, pass rate, and whether it still matches the current screens.
2. Decide for each one: rebuild in the new tool, retire, or merge. Critical end-to-end processes go first.
3. Write requirements from your own failure history, then pilot candidates on ten critical processes across one real service update.
4. Run old and new suites side by side for one update before retiring RSAT.

Keep RSAT in its lane while it lasts. Microsoft positions it for business-cycle tests late in the lifecycle; unit and component tests belong in SysTest with the Acceptance Test Library, and data integration tests belong in the data management framework’s data task automation^[6].

Business Central teams gained tools

Business Central moved the other way. The page scripting tool records and replays user actions in the web client, with validation steps, conditions and parameters, and saves scripts as YAML^[8]. Scripts can run in a pipeline through the bc-replay npm package^[8], and page scripting reached general availability in version 29.0, alongside running AL tests from the command line and CI/CD workflows^[5]. It is not a generic browser tool: it cannot automate control add-ins or embedded Power BI^[8].

Under that sits the AL test framework: test codeunits, test pages, UI handlers and test runners^[9]. Microsoft does not allow tests in production, discourages long test runs in sandboxes, and recommends container-based environments for large suites and CI gates^[9]. Use page scripts for business-process regression and AL tests for extension logic; both should run before every major update reaches production.

What to put in every update cycle

On security, Microsoft’s own post-update steps are to review changed standard roles, audit current settings, test in a sandbox, update custom roles and monitor assignments afterward^[11]. On performance, Microsoft’s implementation guide puts performance testing on a Tier 4 or 5 sandbox and says Tier 2 or 3 typically cannot model a real concurrent workload^[12].

Then measure three things per update: critical process coverage, regression cycle time and escaped defects. If cycle time is not falling, the suite is not keeping up with the calendar. The free Dynamics 365 Service Update Regression Plan holds the calendar, scope rules and a release log, and the Regression Suite Inventory & RSAT Exit Plan counts back from May 15, 2027. For roles, use the Security Role & SoD Test Matrix.