With an on-premise ERP, a version upgrade was a project: you decided on it, budgeted for it, and could put it off for two years. With a SaaS ERP, the update arrives whether you planned for it or not. The only real decision left is whether your organisation receives it prepared, or finds out about it on Monday morning.
This guide is written for CIOs, ERP application owners and key users. It compares the release rhythms of the main vendors, details a six-step release cycle, and offers an annual calendar and a governance checklist. It deliberately stays vendor-neutral: for the Microsoft-specific case, see our analysis of the end of Dynamics 365 release waves.
The End of the Upgrade Project: What the Evergreen Model Changes
In the traditional model, the customer controlled three things: when to upgrade, the scope, and the duration. The evergreen model (a single version, continuously updated by the vendor) flips that logic. The vendor sets the calendar; the customer keeps control of what to activate, what to test and, depending on the vendor, whether a version can be skipped.
Three practical consequences:
- The cost changes nature. No more large upgrade budget every four years, but a recurring load of monitoring, testing and training, which belongs in the run budget.
- The risk shifts. It no longer comes from a single migration but from small repeated breakages: a renamed field, a deprecated API, a modified screen.
- Ignorance is no longer an option. Not reading release notes means being subjected to change rather than steering it. Other vendors are heading the same way: proALPHA has abandoned major versions in favour of continuous releases.
Vendor Rhythms: What Is Published, What Can Be Deferred
The cadences below come from vendor documentation or partner sources, cited in the table. They change over time: always check your vendor’s official page before locking in your internal calendar.
| Vendor / product | Cadence | Customer room for manoeuvre | Source |
|---|---|---|---|
| SAP S/4HANA Cloud Public Edition | Two major releases a year (February and August), plus non-disruptive monthly updates and bimonthly fixes | Non-disruptive new features are activated on demand; deferral of the major release is not documented in the source consulted, to be confirmed with SAP | Gambit, S/4HANA Cloud update cycle |
| Microsoft Dynamics 365 Finance & Operations | Several service updates a year (four, two of them mandatory, according to Microsoft’s announcement on update flexibility) | Choice of maintenance window; update applied to UAT first, then production; one consecutive update can be paused | Microsoft Learn, One Version and Microsoft announcement |
| Oracle Fusion Cloud Applications | Four updates a year, named 26A to 26D | Dates vary by customer: the University of Wyoming, for example, publishes 26A on 22 February, 26B on 17 May, 26C on 23 August and 26D on 22 November 2026, with downtime from Friday evening to Monday morning | University of Wyoming, Oracle 2026 schedule |
| Odoo | Major versions with three years of standard support; intermediate “SaaS” versions every two to three months, reserved for Odoo Online | Beyond three years, paid extended support; SaaS versions are not eligible | Odoo documentation, support |
| Sage Intacct | Four quarterly updates; 2026 dates announced for February, May and August | Automatic deployment, so no deferral to wait for; the challenge is to read the notes and test beforehand | PKF, Sage Intacct lifecycle |
Two takeaways. First, “twice a year” or “quarterly” says nothing about effort: a major SAP release and an Intacct update do not carry the same volume of change. Second, the room to defer is thin everywhere, and where it exists (a single skippable version at Microsoft), it only postpones the testing debt.
For Microsoft, note that feature planning is itself evolving, which strengthens the case for structured internal monitoring rather than reliance on a single vendor calendar.
The 6-Step Release Cycle
Whatever the vendor, the process comes down to six steps. It should be written down, dated and assigned.
Step 1: Monitoring
Appoint someone to read the “what’s new” pages, release notes and above all the deprecations (retired functions, replaced APIs, removed screens). The reading follows a rhythm: every time notes are published, not the night before the update. Microsoft, for example, states that release plans let you discover upcoming features up to three months ahead (Microsoft Learn): that lead time is what funds your preparation.
Step 2: Impact Analysis
For each change, three questions: does it touch a critical process? Does it touch one of our extensions or interfaces? Does it require action from us (activation, configuration, training)? The deliverable is a short table, ranked on three levels: no impact, to watch, to handle before cutover.
Step 3: Sandbox Testing
Vendors generally apply the update to a test environment first. At Microsoft, the update goes to UAT and then to production, which leaves time for validation (Microsoft Learn). Use that interval: it is your only window. Check from day one that your sandbox is up to date and loaded with representative data.
Step 4: Regression Testing
See the sub-section below. This is the most expensive step, and the one most easily reduced through automation.
Step 5: Communication
Warn users before, not after. A short message gives the date, the visible changes, any downtime and the contact in case of problems. Key users get a more detailed note and a demo slot. For screen or workflow changes, a before/after screenshot is worth ten paragraphs.
Step 6: Cutover and Follow-up
On the day, a quick checkpoint (logins, interfaces, three sample transactions), then a few days of heightened vigilance with a dedicated channel for reporting anomalies. The review feeds the indicators described below.
Automating Regression Testing
Manual regression across the whole ERP is not sustainable two or four times a year. The rule: a minimal scope, focused on the processes whose failure is costly.
- List the 10 to 20 critical processes: order-to-cash, procure-to-pay, period close, payroll, production, shipping.
- Automate stable journeys first (few variants, high frequency). Tools vary: Microsoft offers a no-code business process testing tool and a data task automation tool for integrations (Microsoft Learn); with other vendors, you rely on third-party tools or in-house scripts.
- Keep a stable test data set, anonymised where needed for GDPR.
- Complete with guided manual testing on highly variable journeys, run by key users.
- Archive the evidence: screenshots and results are useful in an audit or a dispute with the vendor or integrator.
To build the scenarios, draw on our ERP UAT checklist before go-live: your initial acceptance scenarios are the natural basis for your regression suite.
Roles: Who Does What
| Role | Responsibilities in the cycle |
|---|---|
| CIO / ERP application owner | Runs the process, arbitrates dates and deferrals, reports to leadership |
| Business key users | Read the changes in their scope, run business tests, sign off acceptance, brief their teams |
| Integrator / application support | Analyses technical impact on extensions and interfaces, fixes, runs automated tests |
| Security / compliance officer | Reviews changes affecting access rights, audit logs and personal data |
| Finance leadership | Approves cutover windows around period close |
Set impact-analysis deadlines after release-note publication in the support contract, otherwise your integrator will discover the release at the same time as you.
Managing Extensions and Interfaces That Break
In a SaaS ERP, what breaks is almost never the standard: it is your extensions, your interfaces and your custom reports. Every customisation is a debt that reactivates with each release.
- Inventory extensions and interfaces with, for each, an owner, the processes it touches and the standard APIs or tables it uses.
- Watch for deprecations that target those specific hooks.
- Favour supported mechanisms (API-based extensions, integration platforms) over core modifications.
- Reduce the scope: every extension replaced by standard functionality is one less line in your test plan.
This is the heart of the “clean core” logic detailed in our article on SAP clean core strategy and BTP extensions. The principle applies beyond SAP: the more standard your core, the less painful the releases.
A Typical Annual Calendar and Windows to Avoid
The goal is to cross the vendor’s calendar with the company’s. A planning model:
- Windows to avoid: month-end close, year-end close, stocktaking, commercial peaks (sales, year-end for retail), payroll runs, audits.
- Favourable windows: quiet periods specific to your business, the start of the month (outside close), periods when key users are available.
- When the vendor lets you choose (a maintenance window at Microsoft, for example), take the window that avoids your peaks. When the vendor imposes the date (Oracle, Intacct), adapt your testing and change-freeze calendar instead.
A typical twelve-month calendar for a vendor with two releases a year:
| Period | Activity |
|---|---|
| T-8 to T-6 weeks | Reading release notes, impact analysis |
| T-6 to T-3 weeks | Sandbox testing, fixing extensions |
| T-3 to T-1 weeks | Full regression, user communication |
| Week T | Cutover, heightened vigilance |
| T+1 to T+4 weeks | Review, test suite update |
For a vendor with four updates a year, the same logic applies in a lighter form: monitoring becomes continuous and regression is limited to the minimal scope.
5 Classic ERP SaaS Release Management Mistakes
- Discovering the release at cutover. Consequence: screen or workflow changes imposed on users, a flood of tickets. Countermeasure: a named monitoring owner, with an impact table delivered before testing.
- Testing on a stale or empty sandbox. Consequence: everything passes in test, nothing passes in production. Countermeasure: check the sandbox version from day one and feed it representative data.
- Forgetting the interfaces. Consequence: the ERP works, but payroll, logistics or the bank no longer receive anything. Countermeasure: list every flow in the inventory and cover it in regression.
- Deferring systematically. Consequence: when the vendor no longer allows deferral, you accumulate two releases of gap and double the testing effort. Countermeasure: treat deferral as an exception arbitrated by the CIO, not a habit.
- Cutover in the middle of close or a peak. Consequence: an anomaly blocks invoicing or close at the worst moment. Countermeasure: cross the vendor calendar with the finance calendar in January, and freeze changes around closes.
Metrics: Measuring Process Quality
A release process without metrics does not improve. Four measures are enough:
- Post-release incidents: number of anomalies reported in the days after, tied to the release. Distinguish what comes from the standard, extensions and interfaces.
- Impact analysis time: delay between release-note publication and delivery of the impact table.
- Regression coverage: share of critical processes covered by a test, automated or not.
- Surprise rate: changes discovered after cutover although they were in the release notes. Ideally zero.
Set your own targets from your first two or three releases; there is no reliable universal benchmark, and an internal trend beats an unverifiable benchmark.
Release Governance Checklist
- A vendor-monitoring owner is appointed, with a deputy
- Release notes and the list of deprecations are read at every publication
- Each release produces a three-level impact table
- The inventory of extensions and interfaces is up to date, each item has an owner
- The sandbox is up to date and loaded with representative data
- The 10 to 20 critical processes each have a regression test
- Cutover windows avoid closes, stocktaking and activity peaks
- Users are warned before cutover, key users are trained
- A rollback or workaround plan exists for critical processes
- The support contract sets impact-analysis deadlines
- The four metrics are measured and reviewed after each release
- The review updates the test suite and the inventory
Going Further
Release management changes fast: vendors alter their cadences and deferral rules from one year to the next. To keep up with these changes, subscribe to the erpimplementation.eu newsletter using the form in the footer. In addition, see our UAT guide for go-live and our analysis of the SAP clean core strategy.
