A Release Readiness Framework for Dynamics 365 Finance and Operations

The question changed before the answer did

At Community Summit this month in Nashville I walked a room of Finance and Operations teams through a release readiness framework. The session will be available on demand in a few weeks. This is the written version, with the parts that matter most for the 10.0.50 update window, which opened October 23.

The starting point is simple. Release readiness used to be a project question, asked twice a year when a wave arrived. It is now a standing question. Microsoft retired the release wave model as a communication vehicle in August and moved to continuous roadmap publishing. The deployment calendar itself did not change: Finance and Operations customers can take up to four service updates a year and must take at least two. What changed is that nothing bundles the work into two seasons anymore. Features land when they land, AI capabilities among them, and each service update still arrives on Microsoft's schedule.

The traditional model for an ERP release was test late, test manually, test once. It fit a world where change arrived in big, scheduled blocks. It does not fit a world where change is continuous and the platform updates whether or not your team is ready. The framework below is about moving validation earlier, where it is cheaper, and doing that without handing functional and operations staff another job.

Readiness is a set of answers, not a test count

Most teams measure readiness by activity: how many test cases ran, how many passed, how many people signed off. Those numbers describe effort. They do not describe risk.

A release is ready when the organization can answer four questions with evidence rather than opinion:

1. What changed? Not the Microsoft release notes, but the list of changes that touch your configuration, your extensions, your integrations, and your data. Microsoft documents the platform. Nobody documents your implementation except you.
2. Which business processes does that change reach? Order to cash, procure to pay, period close, warehouse operations. A change to a posting profile matters because of the invoices behind it, not because of the field itself.
3. What must remain true after the change? Debits equal credits. A sales order picks from the right site. An intercompany transaction lands in both ledgers. These are invariants. They are the things a test should assert, and they are far more stable than the clicks it takes to reach them.
4. What evidence shows it is true? A record someone outside the team can read: what was checked, against what data, with what result. A green status is a claim. A record is evidence.

If you can answer those four questions for a change, you are ready to ship it. If you cannot, more test cases will not help. The framework is about getting to those answers earlier and with less effort each cycle.

Three stages where earlier validation pays for itself

Shift left is an old idea in software engineering. It has been slow to reach ERP because the people who know the business process are rarely the people who write the code, and the tooling has not bridged that gap. Here is where the bridge belongs in a Finance and Operations development cycle.

Stage one: when the change is built

A developer finishes an extension, a configuration change, or an integration update. Today, validation usually waits until that change has been bundled with ten others into a release. The cost of a defect found here is measured in hours. Found later, it is measured in days of coordinated retesting. The practical move is to attach the invariant to the change at the moment it is made: this customization exists to make X true, so the check for X runs the moment the build lands in a development environment. That is a developer task, and it should feel like one.

Stage two: when the change meets the platform

A Microsoft service update applied to a sandbox is the first time your change and Microsoft's change coexist. Most production surprises come from this collision, not from either change alone. The standard practice is to validate in the sandbox during the update window, which is correct but late if it is the first time anyone looks. Validating here should be a rerun of checks that already exist, not a fresh campaign. If the regression suite is built on invariants rather than click paths, the sandbox run is confirmation, and failures are real findings rather than maintenance work.

Stage three: when the business decides

The go or no-go call before production. This is where functional and operations staff have historically carried the load: pull people off their day jobs for a week, walk the scripts, sign the sheet. In the framework, stage three is a review of evidence produced in stages one and two. The business reads what was checked and what was found, exercises judgment on the exceptions, and decides. It should take hours, not a week. That is the whole point of moving the work earlier: the people who own the process still make the call, but they are no longer the test bench.

The measure of whether this is working is where defects are found. If most findings surface at stage one, the framework is doing its job. If most surface at stage three, or in production, the work has not moved yet.

AI-enabled workflows widen the surface you validate

The part of the session that drew the most questions was not the framework. It was what happens to it when Copilot and agents start touching production workflows.

Two things are new. First, AI features arrive through the same update channel as everything else, and some are on by default. A capability can be active in production before anyone has decided whether the process it touches should rely on it. Second, AI-assisted steps are not deterministic in the way a posting routine is. The same input can produce a different suggestion, and the workflow downstream of that suggestion has usually never been tested against a range of outcomes.

The framework handles this without a separate AI testing program, because invariants do not care how a value was produced. If an agent proposes a vendor match, the invariant is still that the payment lands on the right vendor and the right ledger account. If Copilot drafts a purchase requisition, the invariant is still that approvals fire according to the policy you configured. Validate the outcome and the guardrail, not the suggestion.

Three additions to the readiness questions for any workflow where AI participates:

1. Treat agent instructions and permissions as configuration. They are part of "what changed" and belong under change control like a workflow definition.
2. Test the guardrail directly. An approval threshold or a role restriction that is meant to catch a bad AI suggestion should have its own check, run every cycle. An untested guardrail is an intention.
3. Decide who owns pass or fail. If an AI-assisted check is part of validation, a person still signs the evidence. Automation can produce the record. It should not be the authority on it.

Run it on 10.0.50, which opened October 23

The framework is abstract until you put dates on it. Here are the dates. The 10.0.50 preview opened October 23 and is available now. General availability is December 22. The last preview update Microsoft will ship lands November 17. Sandboxes receive the production update seven days before production does, and the first production autoupdate windows are January 31 and February 28, 2027. All of this is on Microsoft Learn under the targeted release schedule.

That is roughly two months between preview and GA, and a further five to ten weeks before production is updated for you. Used well, the rest of the window looks like this:

Window	Dates	Stage	What happens
Preview (open now)	Oct 23 to mid Nov	One	Pull the change list for your implementation. Attach invariants to every in-flight customization and integration change. Developers validate their own work in a preview environment.
Last preview update	Nov 17	Two	Apply the final preview to a sandbox. Run the full regression suite once. Every failure is triaged as a real finding or a brittle test, and brittle tests are rewritten as claims.
GA to sandbox autoupdate	Dec 22 to late Jan	Two	Rerun on GA. This run should be confirmation. If it produces new findings, ask why the preview run missed them.
Go or no-go	Week before Jan 31	Three	Business reviews the evidence record and the exceptions. Decision in hours.

Two cautions. December 22 is three days before Christmas and most finance teams are in close. Plan the GA run for the first week of January and do not let the holiday absorb it. And if your organization has a change freeze, the freeze does not pause the Microsoft schedule. The preview and sandbox work above is exactly the work a freeze should allow, because it produces the evidence that lets the thaw go quickly.

Three numbers that outlast any single update

A framework that is only checked once is a project. These three measures make it an operation.

1. Days from "update available" to "validated in our environment." This is your real readiness requirement, in units anyone can read. When it shrinks from weeks to days, the update calendar stops being a threat.
2. Share of findings caught at stage one. If developers are catching their own defects before a change is bundled, the framework is working. Track it per cycle and expect the share to rise.
3. Hours of functional and operations time per cycle. The point of moving validation earlier is that business experts stop being the test bench. If this number is not falling, the work has shifted on paper only.

At The TestMart we see the first number vary widely across otherwise similar Finance and Operations environments. The difference is rarely the size of the implementation. It is whether validation runs continuously against invariants or is rebuilt by hand each time.

Start with one process

Do not try to apply the framework to the whole system in one update cycle. Pick one process your business depends on, such as order to cash or period close. Write down what must remain true for it. Attach those checks to the next change that touches it. Run them in the 10.0.50 preview, which is open now. Measure the three numbers above for that one process.

The session recording will be available through Community Summit's on-demand library. If you attended and want to compare notes on your own environment, or want the one-page version of the framework, reach out and we will send it along.

Matt Sabath is Chief Product and Technology Officer at The TestMart, maker of Horizon, a validation platform for Microsoft Dynamics 365. This article also appears on the TestMart blog.