ERP Upgrade Guide: Move Versions Without Breaking the Business

What an ERP Upgrade Actually Is

An ERP upgrade is the process of moving from an older version of your ERP system to a newer release under the same vendor. It is not a greenfield reimplementation (starting over on a new system) and it is not a vendor switch (what we cover in our ERP migration guide). Upgrades cover functional enhancements, platform and database changes, security fixes, and regulatory or compliance updates.

How an upgrade lands depends heavily on deployment model. Cloud ERP follows a vendor-managed, continuous ('evergreen') model: the vendor pushes automatic updates on a published schedule and you validate them in a sandbox tenant first — there is no multi-year customer-side upgrade project. On-premise ERP is customer-controlled at the version level: you choose when to move to a new major version, typically in a multi-year project that includes code remediation, hardware or platform changes, and end-of-support pressure.

For SMEs, the practical reality is usually somewhere in between. Most Dynamics 365 Finance, Supply Chain Management, and Business Central customers run cloud tenants under Microsoft's One Version policy; most Odoo customers run either Odoo.sh or self-hosted instances on a versioned, customer-driven cadence. This guide covers both.

Microsoft Dynamics 365: The One Version Upgrade Model

Dynamics 365 Finance, Supply Chain Management, and Commerce run on Microsoft's One Version strategy: instead of infrequent, customer-driven major upgrades, Microsoft pushes managed service updates so that all customers run on or very close to the same current version.

Microsoft reduced the One Version service update cadence from seven releases per year to four. Version 10.0.38 (the February 2024 release) acted as the transition release, and version 10.0.39 (the April 2024 release) was the first service update shipped under the new quarterly cadence. The four annual releases now land roughly in February, April, July, and October. On top of those quarterly service updates, Microsoft delivers Proactive Quality Updates (PQUs) — more frequent cumulative hotfix builds pushed automatically, region by region, on a biweekly cadence (as of version 10.0.47), with near-zero downtime.

The rules that govern how often you must upgrade:

Customers must apply at least two service updates per year to remain supported (and may take up to four), and can pause a maximum of one consecutive update at a time — reduced from three as of February 19, 2024. That means you cannot defer upgrades indefinitely — the model is designed to keep everyone current.

Microsoft guarantees runtime/binary and functional compatibility for existing extensions, hides many new behaviors behind Feature management (so administrators opt in rather than being disrupted), and announces deprecations or breaking changes 12 months in advance. Release Waves frame the broader feature cadence: Wave 1 covers features releasing April through September, and Wave 2 covers October through March, with release plans published months ahead.

Business Central (the SME-focused Dynamics 365 app) runs on a separate evergreen cadence: two major updates per year aligned to the April and October release waves, plus monthly minor updates, with administrator-controlled maintenance windows and sandbox environments for pre-production validation.

The SME takeaway: under One Version, 'upgrade' is a continuous validation discipline, not a one-off project. The risk is not the upgrade itself — it is that a quarterly update changes a behaviour your customisations or integrations depend on without anyone noticing until period close.

Odoo: Versioned, Customer-Driven Upgrades

Odoo is the opposite model: a versioned, customer-controlled upgrade cycle. Major releases ship annually (the .0 release, typically September through October), and each major version receives roughly three years of standard support — including helpdesk support, bug fixes, and security updates — with extended support available for an additional fee afterward. Upgrades between major versions are your decision and your project.

Three official upgrade paths exist, depending on how Odoo is deployed:

Odoo Online: upgrades are automatic and handled by Odoo SA. Odoo Enterprise and Odoo.sh customers use the integrated Upgrade platform (upgrade.odoo.com), which produces a neutralised upgraded test database (scheduled actions disabled, outgoing mail, payments, and bank sync neutralised) plus an upgrade report, followed by an irreversible production upgrade. Self-hosted Community Edition relies on the OCA's OpenUpgrade framework — an open-source migration project providing the openupgrade_framework server-wide module, openupgrade_scripts migration set, and the openupgradelib Python helper. OpenUpgrade migrations must run sequentially, one major version at a time.

Odoo.sh branch upgrades are the recommended SME workflow. You pick a staging branch, choose a target version in the UPGRADE tab, and the platform sends the latest daily production backup to the upgrade platform and puts the branch into 'update on commit' mode: every git commit restores the upgraded backup and re-runs your custom module upgrade scripts, with logs at ~/logs/upgrade.log and automatic rollback on failure.

Customised databases require a two-step process: first make custom modules installable on an empty target-version database, then handle data migration. Migration scripts live in `$module/migrations/$version/` as pre-*.py, post-*.py, and end-*.py files, each exposing a `migrate(cr, version)` function for schema and data transformations, with Odoo's upgrade-utils helpers (rename_field, rename_model, recompute_fields) for common operations.

Common breakage between Odoo major versions: renamed or removed fields and models, OWL and UI view changes, accounting and localisation data shifts, deprecated APIs, and stale noupdate records. Because Odoo upgrades are discrete and customer-driven, they tend to be more disruptive per event than Dynamics 365 updates — but they also happen far less frequently.

Why Customization Breaks During Upgrades (and Configuration Does Not)

The single biggest predictor of upgrade cost and risk is how much your ERP is customised versus configured. Heavy customisation — modifying core code or objects — is tightly coupled to internal ERP structures and breaks during upgrades. Configuration (settings, low-code extensions, personalisation) is generally upgrade-safe, which is why both Microsoft and Odoo recommend extensions and add-ons over intrusive customisation.

This applies on both platforms. In Dynamics 365, ISVs and partners are recommended to maintain at least two branches under One Version: a servicing branch (fixes, built against the oldest supported version) and a development branch (new work aligned to a recent or upcoming version), validating every Microsoft release during the Preview phase. In Odoo, custom modules that touch core models or override views are exactly the code that the OpenUpgrade or upgrade.odoo.com scripts cannot auto-fix.

For SMEs, the highest-ROI upgrade decision is to minimise customisation from day one: start with out-of-the-box standard processes and use configuration, Odoo Studio, or extensions rather than core code modifications. This dramatically reduces both the upfront upgrade effort and the ongoing cost of every future release. If you are already heavily customised, see our ERP customization vs configuration guide for how to unwind the worst offenders.

Impact Analysis and Regression Testing

ERP regression testing re-executes previously validated test cases after an upgrade or patch to confirm existing functionality still works. It is critical in ERP because modules are tightly integrated — finance, supply chain, manufacturing — and failures cascade across order-to-cash, procure-to-pay, and period-close processes.

Exhaustive full regression testing on every update is impractical, which is why delta (impact) analysis is the discipline that makes upgrades affordable. Impact analysis systematically identifies the differences between source and target versions and maps them to your specific customisations, integrations, and reports — enabling risk-based, targeted testing instead of testing everything.

For Dynamics 365 Finance and Operations, the native tool is the Regression Suite Automation Tool (RSAT), which converts Task Recorder recordings into parameterised, Excel-driven tests run via Azure DevOps. Important caveat: RSAT is marked for deprecation and will not be supported after May 15, 2027, and Microsoft has named no direct replacement — so teams should begin evaluating alternatives now. Microsoft's own guidance is platform-neutral ('we don't recommend one tool over another') and points to options including SysTest/ATL for unit and component tests, plus third-party platforms. Third-party platforms that specialise in impact-driven regression for ERP include Panaya (Test Dynamix and Change Intelligence), Tricentis (Tosca and SAP Change Impact Analysis), and Worksoft (Certify and Impact); they correlate code and transit changes to business-process test coverage so you test only what the update actually touched.

For SAP customers moving to S/4HANA, conversions are guided by the Simplification Item Catalog and custom-code analysis (ATC/SCI), with the conversion itself run through the Software Update Manager (SUM). SAP S/4HANA Cloud (Public Edition) uses a 3-system landscape (3SL) in which the test system is upgraded ahead of production, and the RASD (Release Assessment and Scope Dependency) tool delivers a personalised view of release impact filtered to your activated scope items.

For Odoo, there is no equivalent native regression tool — testing is manual plus whatever you build with the Odoo testing framework or third-party automation. This is a real gap, and one reason Odoo version upgrades feel more labour-intensive than Dynamics 365 updates.

Cutover and Hypercare

A cutover is the coordinated switch from the legacy to the upgraded system, usually planned for a weekend or low-business window of under 48 hours. A clean cutover includes data and transaction freezes in the legacy system, a code freeze, a detailed hour-by-hour runbook, dry-run rehearsals, explicit go/no-go criteria, and a documented rollback plan. Microsoft publishes cutover guidance for Dynamics 365 implementations covering all of these elements.

Hypercare is the intensive post-go-live support window — typically 30 to 90+ days — during which a dedicated team monitors issues, applies urgent fixes, and stabilises the system before transitioning to business-as-usual support. Hypercare matters for upgrades as much as for fresh implementations, because even well-tested updates surface issues only once real users and real transaction volumes hit the system.

For SMEs, the discipline that saves the most cutover pain is the dry run: rehearse the cutover runbook against a sandbox copy of production at least once before the real event. Most cutover failures are process failures (forgotten integrations, missing static data, un-tested reports), not software failures. Our ERP go-live checklist and ERP hypercare guide cover the structure in detail.

Upgrade vs Migration: Don't Confuse the Two

Upgrades stay on the same vendor and move to a newer version. Migrations switch systems (for example, moving from an on-premise legacy ERP to Dynamics 365 or Odoo, or switching vendors entirely). The two have different risks, costs, and timelines, and they require different plans.

If you are staying on your current platform and moving versions, you are upgrading — and this guide applies. If you are switching platforms, that is a migration, and our ERP migration guide and cloud ERP guide are the right starting points. The most expensive mistake SMEs make is treating a major version upgrade as a chance to 'start clean' — which balloons scope, re-introduces implementation risk, and usually delays go-live by months. Upgrades should be boring; reserve ambition for a separate migration project.