Here is a question most ERP teams cannot answer, and it is worth sitting with for a moment before reading on.
When Microsoft ships a Dynamics 365 update to your production environment, how long is it before you have validated that your business processes still work?
Not how long until testing *starts*. How long until you actually know.
For most organizations the honest answer is one to three weeks. During that window, the system running your finance function has not been validated by anyone.
Nobody chose that. It is the arithmetic of how conventional testing works, and it has become considerably worse over the past three years without anyone deciding it should. This piece is about that window, why it exists, why the update cadence made it structural rather than occasional, and what it would mean to close it.
The Window Nobody Measures
Every ERP update creates a period during which the system in production differs from the system your test suite was written against. Call it the validation gap: it opens the moment the update lands and closes when coverage catches up.
Teams measure a great many things about their testing, pass rates, coverage percentages, execution time, and defect counts. Almost nobody measures this window, which is odd, because it is the only period in which you are demonstrably operating without assurance.
| What Happens | Typical Duration | What You Know |
| Update lands in production | Day 0 | Nothing about its impact |
| Broken tests triaged and repaired | Days 1–5 | Which tests broke, not why |
| Regression suite re-run | Days 5–10 | Whether old behavior still holds |
| New behaviour covered | Days 10–20, if at all | Whether new features work as expected |
Two things are worth noticing in that table. The first is that the earliest stages produce no assurance at all, repairing broken tests tells you your tests were fragile, not whether your business processes are correct. The second is that the final row frequently never happens. Coverage of genuinely new functionality is the thing that gets dropped when the next sprint starts.
Why Coverage Always Lags the Change
The lag is not a resourcing failure. It follows from how conventional tests are built.
A test written against a system encodes that system as it existed on the day it was written, the screens, the fields, the paths, the identifiers. That encoding is what makes the test executable, and it is also what makes it a description of the past. When the system changes, the description is stale by definition.
Which produces a sequence that cannot be shortened much by working harder. The update lands, tests referencing changed elements fail, someone triages the failures to separate genuine regressions from stale references, the stale ones get repaired, and only then does the suite tell you anything about whether the business still works.
You cannot validate a new version with tests written against the old one. You can only find out how much of your test suite the update broke.
That is the crux, and it explains why more testing resource does not close the gap proportionally. Doubling the team halves the repair time and leaves the underlying dependency intact, coverage still has to be rebuilt against each new state before it means anything.
The Cadence Made It Structural
This was a tolerable arrangement when ERP systems updated annually. A two-week validation gap once a year is a manageable exposure and a reasonable planning assumption.
That is not the current cadence.
| System | Update Frequency | Validation Gaps Per Year |
| SAP S/4HANA | Quarterly support packs, plus feature packs | 4–6 |
| Dynamics 365 F&O | Two release waves, plus monthly quality updates | 2 major, 12 minor |
| Business Central | Monthly, plus two major waves | 12+ |
| Plus AppSource extensions | Each vendor’s own schedule | Unpredictable, uncoordinated |
At Business Central’s cadence, a two-week validation gap consumes close to half the calendar year. And the gaps are not independent, an extension update can land mid-way business central extension through validating a base update, changing the system underneath the validation in progress.
The obvious response, defer updates until you are ready, is largely unavailable. Cloud ERP updates are mandatory with limited pause windows. You can delay slightly. You cannot opt out, and delaying compounds the problem by making each eventual update larger.
What Zero-Day Validation Means
Zero-day validation is coverage that exists at the moment an update lands, because it was never written against the previous version in the first place.
The mechanism is the same one that makes agent-based testing durable generally: if the artefact describes a business outcome rather than a UI path, it does not go stale when the path changes. “A vendor invoice over the approval threshold routes to the finance approver” was true before the update and is true after it. Nothing about that statement references a screen, a field ID or a click sequence.
So the validation does not need rebuilding. It needs running.
| Conventional | Zero-Day | |
| Coverage on day 0 | None, suite is stale | Full, outcomes unchanged |
| First useful signal | Days 5–10 | Hours |
| What day 1–5 produces | Test repair | Findings |
| New feature coverage | Days 10–20, or never | Describe it, covered same day |
| Effect of higher cadence | Compounds | Neutral |
The difference is not that validation runs faster. It is that there is nothing to rebuild before it can run at all.
The fourth row matters as much as the first. Genuinely new functionality still needs someone to say what correct looks like, but describing a scenario is minutes of work rather than a scripting exercise, so new-feature coverage stops being the thing that gets dropped.
What It Doesn’t Mean
Three boundaries, because a term is only useful if it means something specific.
- It does not mean the update is risk-free. It means you find out on day zero instead of day fifteen. Updates still break things; the change is in how long the breakage runs undetected.
- It does not eliminate human judgment on new functionality. When SAP or Microsoft ships a capability that did not previously exist, someone still has to decide what correct behavior is for it. What disappears is the mechanical work between that decision and having coverage.
- It is not a substitute for the vendor’s own release notes and impact analysis. Knowing what changed is still worth doing. Zero-day validation tells you what the change did to your processes, which is a different question from what the vendor says it changed.
Measuring It
If the validation gap is the exposure, then the metric worth tracking is straightforward: **time to validated coverage**, hours from an update landing in an environment to a complete pass of your critical business processes.
Most teams have never measured it, and the first measurement is usually the persuasive part of the exercise. Three things to capture:
- Hours from update to first complete run. Not to first test execution, to a run that covers your critical processes end to end.
- Proportion of that time spent on repair versus finding. If most of the window is spent fixing tests rather than discovering issues, the suite is the bottleneck rather than the update.
- Whether new functionality was covered at all. Track it explicitly, because this is the coverage that silently never happens and what monitoring does not tell you.
That third measure tends to be uncomfortable. Many teams discover that new-feature coverage has not happened for several consecutive release waves, which means their regression suite is validating an increasingly incomplete picture of the system.
How Sofy Fits In
Sofy’s ERP agents validate business outcomes at the data layer rather than replaying screen paths, which is what makes day-zero coverage possible rather than aspirational.
In practice, when a support pack or release wave lands, the existing validation runs against the updated system without modification, asserting that postings still hit the correct accounts and periods, that approvals still route according to the delegation matrix, that sub-ledgers still reconcile. Where the update changed something structurally, agents adapt their approach rather than failing and queuing for repair.
For SAP specifically that covers the quarterly support pack cycle across SAP FI/CO, MM, SD and the SAP integration layer. For Dynamics 365 it covers both release waves and the monthly updates that arrive between them, including Business Central’s faster cadence.
And because specialist agents share context through a coordination layer (multi agent orchestration), a release-wave validation can span the mobile front end, the API layer and the ERP transaction as one run rather than three disconnected checks whose combined result nobody assembles.
Frequently Asked Questions
What is zero-day validation?
Zero-day validation is ERP test coverage that exists at the moment an update lands, because the validation was never written against the previous version. It is possible when tests describe business outcomes rather than UI paths, an assertion that an invoice over threshold routes to the finance approver holds true regardless of how the screen changed, so nothing needs rebuilding before it can run.
How long is the typical validation gap after an ERP update?
One to three weeks for most organizations. Days one to five usually go on triaging and repairing tests that broke on changed elements, which produces no assurance about business correctness. The regression suite delivers its first meaningful signal around days five to ten, and coverage of genuinely new functionality, if it happens at all, lands later still.
Why can’t we just defer updates until we have tested them?
Cloud ERP updates are largely mandatory with limited pause windows, so deferral is available in weeks rather than quarters. It also compounds the problem: a deferred update is a larger change when it eventually lands, which widens the validation gap rather than removing it.
Does zero-day validation mean updates carry no risk?
No. Updates still break things. What changes is detection latency, finding out within hours rather than after two weeks of running invalidated software in production. Genuinely new functionality also still requires someone to define what correct behavior looks like; what disappears is the mechanical work between that decision and having coverage.
How do you measure the validation gap?
Track time to validated coverage: hours from an update landing to a complete pass of your critical business processes. Alongside it, measure what proportion of that window went on repairing tests versus finding issues, and whether new functionality was covered at all. The third measure is usually the revealing one, many teams find new-feature coverage has not happened for several consecutive waves.
The Bottom Line
Every ERP update opens a period in which the system running your business has not been validated by anyone. That was a tolerable annual event. At quarterly, monthly and continuous cadences it is a recurring condition, and for Business Central customers it consumes a meaningful share of the year.
The gap exists because conventional tests encode the system as it was, which makes them stale the moment it changes, so the first week after an update produces test repair rather than assurance. More resource shortens that; it does not remove the dependency.
Zero-day validation closes the gap by removing what has to be rebuilt. Describe the outcome rather than the path, and the description survives the update that invalidates everything written against the interface.
Whatever you conclude about tooling, measure the gap first. It is the number that makes the case, and almost nobody has it.
Measure Your Own Validation Gap First
Before evaluating anything, time it. Hours from the last update landing to a complete pass of your critical processes. That number is the business case, and most teams have never calculated it.