The old ERP world let you choose your version and sit on it, sometimes for a decade, which is how the AX 2012 estates we still migrate came to exist. Dynamics 365 removed the choice. Under One Version, Microsoft ships service updates on its calendar, you can pause a limited number of them, and everyone runs a current version whether they planned to or not.
Organisations coming from the old world often treat this as a threat to be managed, and their first year shows it: each update becomes a small project, with meetings, a scramble of manual testing, and a sigh of relief afterwards. By the third or fourth cycle, the scramble has usually decayed into waving updates through untested, which works right up until it does not.
Both patterns miss what One Version actually asks for. Updates on someone else's schedule are not an event to survive. They are a load-bearing routine, and routines want machinery.
The reason updates feel dangerous is uncertainty about what they might break, and the honest way to remove uncertainty is to test the things that matter, every time, without heroics.
That means an automated regression suite over the processes the business cannot lose: order to cash, procure to pay, financial close, the integrations in and out. Microsoft's Regression Suite Automation Tool covers a decent share of this for F&O, and what it cannot cover gets scripted around it. The suite runs against the update in a sandbox the week the release lands, and the output is a short list of genuine issues instead of a long month of anxiety.
Building the suite is real work, which is why it belongs in the implementation budget rather than the operations backlog. Programmes that build it before go-live inherit a calm update cadence for free. Programmes that skip it buy the anxiety on a subscription.
The other variable is the customisation layer. Every extension is a thing that can conflict with a release, so each one is a small recurring tax, paid at every update, forever. This is the practical argument for the discipline we push during implementations: configuration before code, standard capability before extension, and a genuine reason on file for every departure. Estates that held that line sail through updates. Estates that extended freely feel every release.
It also means the update cadence should feed back into the backlog. When a release ships standard capability that an extension currently provides, retiring the extension is usually worth more than any feature request beside it.
The pattern we run for supported clients is unexciting by design. The release lands in a sandbox on day one. The regression suite runs that week. Findings get fixed or raised with Microsoft inside the window. Production takes the update on schedule, and nobody meets about it beyond a standing half hour. Twice a year, the release notes get a proper read for capability worth adopting, because updates are also where the new value arrives, and estates that only defend against releases never collect it.
That is the whole trick. Not confidence, machinery.
Marcel Rizzolo is Director of Coder Trove. Our Dynamics 365 practice runs One Version update management, regression testing and environment administration as standing support arrangements.