Dynamics 365 Finance and Operations receives service updates on Microsoft's schedule, not yours. You can pause a limited number of them, but you cannot opt out, and every customer runs a current version. The way to take those updates without risk is a routine: each release lands in a sandbox on day one, an automated regression suite runs over the processes the business cannot lose, findings are fixed inside the window, and production updates on schedule.
The old ERP world let you pick a version and sit on it, sometimes for a decade. That is how the AX 2012 estates we still migrate came to exist. One Version removed the choice. Microsoft publishes the release calendar, you choose a date inside each window, and the update is applied whether or not anyone on your side feels ready.
Organisations coming from the old world often treat this as a threat. Their first year shows it: each update becomes a small project, with meetings, a week of manual testing and a sigh of relief afterwards. By the third or fourth cycle, the project has usually decayed into waving updates through untested, which works until it does not.
The fear comes from not knowing what an update might break. Manual testing cannot remove that uncertainty, because nobody can re-test an ERP by hand every few months without cutting corners. The only way to know is to test the processes that matter, every time, automatically.
Build a regression suite over the processes you cannot lose: order to cash, procure to pay, financial close, and every integration in and out. Microsoft's Regression Suite Automation Tool (RSAT) covers a good share of this for Finance and Operations, and what it cannot reach gets scripted around it. The suite runs against the update in a sandbox the week the release lands. The output is a short list of real issues to fix.
Building the suite is real work. It belongs in the implementation budget, not the operations backlog. Programmes that build it before go-live inherit a calm update cadence. Programmes that skip it pay at every release, in manual testing or in risk.
Every extension is something that can conflict with a release, so each one is a small recurring cost paid at every update for as long as it exists. That is the practical reason we hold the line during implementations: configuration before code, standard capability before extension, and a written reason for every departure. Estates that held that line take updates quietly. Estates that extended freely feel every release.
The update cadence should also feed the backlog. When a release ships standard capability that an extension currently provides, retiring the extension is usually worth more than any feature request sitting next to it.
This is the routine we run for supported clients, and it is unexciting by design:
You can pause a limited number of consecutive updates, but you cannot skip them indefinitely. Microsoft applies the update at the end of the pause period.
With an automated suite, a few hours of run time and a day or two to work through findings. Without one, a thorough manual pass over the core processes takes weeks, which is why most organisations stop doing it.
The principle is the same. Business Central ships two major releases a year plus monthly minor updates, with a window to schedule each major one. The same routine applies: sandbox first, test what matters, production on schedule.
Owning the calendar, deploying each release to a sandbox, running and maintaining the regression suite, fixing or escalating findings, and applying the update to production on the agreed date. Our Dynamics 365 practice runs this as a standing arrangement, alongside environment administration and integration monitoring. The post on D365 support after hypercare covers what else that arrangement should contain.
Marcel Rizzolo is Director of Coder Trove.