Many CIOs believe they’re tackling an IT project when they sign off on a major upgrade. In reality, they’re embarking on a business transformation project disguised as a maintenance budget. The vendor presents the new version as continuity, the integrator mentions a cost “significantly lower than a new project,” and the CFO makes decisions based on estimates that prove incomplete the moment the first regression tests fail.
This article addresses the subject candidly. It explains why moving from SAP ECC to S/4HANA, from Sage 200 to Sage X3, or from Odoo v13 to v17 is not a simple update. It details the cost items most proposals ignore, establishes a seven-step methodology, and helps resolve the question that always arises: upgrade or re-implementation.
Why We Talk About Major Upgrades, Not Simple Updates
Minor Updates Versus Major Upgrades
A minor update fixes bugs, provides ergonomic improvements, and applies security patches. The configuration remains intact, customizations continue working, users notice almost nothing. It’s a recurring exercise, sometimes automated, that mobilizes neither business management nor the investment budget.
A major upgrade changes the game. It moves the system from version N to version N+1 (or more), with compatibility breaks in the data model, interfaces, or even the underlying architecture. Moving from SAP ECC to S/4HANA involves a database change (HANA replaces Oracle, DB2, or SQL Server), a financial model overhaul (the ACDOCA table replaces BSEG and BKPF on the finance side), and a new user interface layer (Fiori).
Moving from Odoo v13 to v17 changes the ORM, deprecates APIs, reorganizes billing logic, transforms some fields into others. A custom module written in 2020 won’t run as-is in 2026.
Moving from Sage 200 to Sage X3 isn’t even an upgrade: Sage has classified it as a new implementation, the two products being distinct platforms (Mysoft).
Three Scenarios That Trigger a Major Upgrade
End of vendor support. This is the hardest trigger to negotiate: it has a date. SAP ECC 6.0 mainstream maintenance ends December 31, 2027, with paid extended maintenance available until end of 2030 for customers on EHP 6 to 8 (Rimini Street). SAP S/4HANA on-premise Compatibility Packs have been extended one final time until May 31, 2026 (SAP News). RISE with SAP or S/4HANA Cloud Private Edition customers retain usage until December 31, 2030.
Technical stack change. The vendor rewrites its foundation, and the previous version becomes industrially unmaintainable. SAP HANA is the canonical example: the in-memory database forces a performance and reporting overhaul for customers coming from ECC. Same logic at Odoo when the vendor refactors core modules: v17 modernized accounting entries and purchasing module management compared to v13, at the cost of non-trivial data migration.
UX or architectural overhaul. SAP Fiori, Salesforce Lightning, Dynamics Unified Interface: the vendor pushes a user experience that makes classic screens obsolete. The upgrade then becomes a change management project: users demand training, business managers must review their procedures, internal support explodes for three months.
The Special Case: Upgrade That Becomes Re-implementation
In practice, a major upgrade with more than 40% customizations compared to standard almost systematically ends up as disguised re-implementation. Teams start in conversion mode, realize that SAP Z-tables or custom Python modules don’t transfer, and switch to overhaul mode after a few months. The initial budget is then exceeded by a factor of two or three, and the project becomes politically difficult to stop.
Hidden Costs No One Budgets For
An “official” upgrade is costed on three visible items: additional licenses, conversion services, training. These three items typically represent 30 to 40% of the real cost. The remaining 60% emerges along the way.
Customizations to Redo or Rebuild
Every customization is a candidate for breakage. SAP Z-tables written on BSEG must be rewritten to point to ACDOCA. Custom Odoo modules must follow the refactor cycle v14, v15, v16, v17, Odoo’s official upgrade service only handles Odoo core apps, not third-party or custom modules (Odoo documentation). Each intermediate version must be tested, validated, documented.
Typical impact: 30 to 45% of the total upgrade cost, depending on customization volume and configuration age.
Integrations That Break
An ERP in production is never alone. It talks to a CRM, WMS, supplier portal, e-commerce, payroll tool, EDI. Each interface relies on an API contract or file format. A major upgrade reshuffles the cards: endpoints change, schemas evolve, webhooks no longer trigger at the same moment.
Inventorying these interfaces from the project start is a tedious exercise that IT teams underestimate. For an average mid-market company, count 20 to 60 active integration points to re-certify. Each mobilizes a team that’s often not the one managing the upgrade.
Data Migration When the Model Changes
Moving from SAP ECC to S/4HANA fundamentally changes the financial model. Accounting entries no longer live in BSEG and BKPF but in ACDOCA, with a history to reconstruct if you want to compare fiscal years. Reports frozen by controllers for ten years no longer work as-is. Mapping accounts, cost centers, and segments requires weeks of workshops with management control.
On the Odoo side, certain version upgrades have overhauled field models: a single-value field in v13 becomes a Many2many relation in v17. A raw extraction isn’t enough; you need to reprocess.
User Training and Change Resistance
The upgrade changes ergonomics. Fiori is not SAP GUI. The Odoo v17 interface is not that of v13. Input habits, shortcuts, screen sequences are modified. An expert user who completed their daily work in 45 minutes will take 2 hours during the first weeks. This is where informal strikes play out: the salesperson who returns quotes in Excel, accounting that double-enters in a parallel dashboard.
Budget 3 to 5 days of training per key user, plus close support for 90 days post-cutover. Often forgotten in the initial quote.
Business KPI Regression for 3 to 6 Months
A CFO measures ERP cutover performance on one thing: monthly closing time. A well-managed upgrade loses 3 to 8 days of closing during the first quarter. A poorly prepared upgrade can paralyze closing for a semester. This cost doesn’t appear in a quote, but it mobilizes finance teams, feeds executive committee reports, and justifies a serious investment in the testing phase.
Three Major Upgrade Scenarios
SAP ECC to S/4HANA: Brownfield, Greenfield or Bluefield
SAP offers three transition approaches, each with very different trade-offs (SAP Community).
Brownfield (system conversion). The fastest approach: convert the existing system to S/4HANA preserving configuration, historical data, and compatible customizations. Suitable for customers with few customizations and recent configuration. Typical duration: 9 to 18 months for a mid-market company.
Greenfield (new implementation). Start from scratch with S/4HANA standard, redesign processes, migrate only strategic data. Suitable for organizations whose 2015 processes are no longer aligned with 2026 reality. Typical duration: 18 to 30 months, highest cost short-term but best 10-year trajectory.
Bluefield (Selective Data Transition). The hybrid approach: start a new S/4HANA, then selectively migrate what needs to be (historical data, configurations, customizations). Approach formalized by SAP in 2020 via the Selective Data Transition Engagement program (SAP Support). Relevant for multi-entity groups wanting to clean their configuration without losing their data.
The official tool for decision-making is SAP Readiness Check, complemented by Fiori App Recommendations and the SAP Signavio program for process analysis. These tools don’t replace a fit-gap audit, but they provide objective mapping of the delta between existing and standard.
Market context confirms the pressure. According to the DSAG Investment Report 2025 (German, Austrian and Swiss SAP user association), 51% of respondents still use SAP Business Suite, versus 42% already on S/4HANA On-Premises, 33% on Private Cloud and 13% on Public Cloud. Importantly, 68% are considering investing in S/4HANA Cloud in the coming months, the movement is accelerating, but a significant portion of customers are still planning the switch for end of 2030. The window is narrow.
Sage 200 to Sage X3: Disruption Rather Than Migration
Sage 200 customers planning functional scale-up (multi-entity, multi-currency, manufacturing MES) don’t upgrade versions. They change products. Sage 200 and Sage X3 are distinct platforms (Mysoft); the transition is classified by Sage and its partners as a new implementation, not an upgrade.
Two practical consequences. First, data doesn’t transfer automatically: a project for migrating master data, historical records, and work-in-progress must be scoped. Second, Sage 200 customizations (macros, Crystal reports, scripts) don’t port; everything must be redone.
For customers staying on Sage 200 and wanting to upgrade to version R2, the operation is lighter but remains sensitive to custom developments and third-party modules. The Sage 200 Manufacturing module is no longer supported since December 31, 2025 (Mysoft), mechanically pushing part of the installed base toward X3 or a market alternative.
Odoo v13-v16 to Odoo v17
Odoo publishes a major version annually. Odoo Online forces version upgrades within 2 years; Odoo Enterprise self-hosted gives more latitude but not indefinitely. Odoo’s official upgrade service goes through the upgrade.odoo.com portal and processes one version at a time: to go from v13 to v17, the database is first upgraded to v14, then v15, then v16, then v17.
Two consequences. First, each intermediate version is a complete integration test. Second, the upgrade service only covers Odoo core applications; custom modules and third-party apps (OCA, partners) remain the customer’s or integrator’s responsibility. Custom modules are marked as “to upgrade” in the resulting database, to be rewritten before go-live.
For community databases, OpenUpgrade (OCA project) offers an alternative but its scope is more limited. For an Enterprise customer with 30 custom modules developed since 2018, a v13 to v17 upgrade is clearly an integration project, not a simple technical update.
Methodology: 7 Steps to Avoid Failure
Step 1: Fit-Gap Audit With the New Version
Exhaustive inventory of used functionalities, compared against the target standard. The gap is the upgrade roadmap. Native tools: SAP Readiness Check for S/4HANA, modular code analysis for Odoo, manual review for Sage.
Step 2: Customization Inventory
How many lines of custom code? How many custom tables? Which modules modify standard behavior? Vendors provide analysis tools: SAP Custom Code Migration Worklist, Odoo l10n-community for OCA modules. The objective is to classify each customization into three categories: keep as-is, refactor to standard, abandon.
Step 3: Sandbox POC on Reduced Scope
Before committing a seven-figure budget, set up a target environment with 10 to 20% of the scope and run three or four critical business processes. Monthly accounting close, sales cycle, supplier order taking. This exercise reveals 80% of technical risks in 6 to 10 weeks.
Step 4: Data Migration Strategy
Decide what to migrate, to what depth, in what form. Customers systematically underestimate cleanup time: third-party deduplication, chart of accounts consistency, item master data normalization. Plan 2 to 4 dedicated business analysts for 3 to 6 months.
Step 5: Reconstruction or Migration of Critical Customizations
Customizations to keep are rewritten or recompiled in the target. Abandoned customizations are documented (audit trail for compliance). Any new customizations, imposed by the target, are scoped, costed, planned.
Step 6: Regression Testing and User UAT
The most under-budgeted phase, systematically. For a SAP or Sage X3 upgrade, plan an 8 to 16-week testing cycle covering end-to-end processes, with pilot business users. Don’t outsource this phase entirely: the integrator doesn’t have the business insight to validate a P&L statement or inventory report.
Step 7: Go-Live (Big Bang or Phased)
Classic arbitration between weekend cutover (big bang, short but risky) and cutover by sites or modules (phased, longer but safer). For a multi-site group with different time zones, phased cutover by site reduces risk. For a single site with strong inter-module dependencies, big bang often remains the only clean option. In both cases, a documented rollback plan is non-negotiable; otherwise, you depend on luck.
Upgrade or Re-implementation: 4 Decision Criteria
| Criteria | Upgrade Possible | Re-implement |
|---|---|---|
| Customization Ratio | < 20% of standard code | > 40% |
| Configuration Age | < 5 years | > 8 years |
| Business Alignment | 2020+ processes still relevant | Obsolete or disputed processes |
| Vendor Trajectory | Target modules still supported in vN+1 | Modules removed or deeply refactored |
A single criterion in the red zone doesn’t condemn an upgrade. Two or more force opening the debate: continuing with upgrade then amounts to doing degraded re-implementation, with all the constraints of the existing and few benefits of a clean overhaul.
TCO Upgrade Versus TCO New Project
Comparing an upgrade to a new project requires stacking items homogeneously. Here’s a comparison framework a CIO can present to their committee.
| Item | Upgrade (SAP ECC → S/4HANA brownfield) | New Project (S/4HANA greenfield) |
|---|---|---|
| Licenses | Conversion of existing licenses + supplements | Complete S/4HANA licenses |
| Integrator Services | Conversion + customization overhaul | Complete configuration + process design |
| Data Migration | Incremental migration, ACDOCA structure | Selective migration, frozen historical data |
| Regression Testing | High (cover existing) | Medium (cover new) |
| Training | Medium (UX changes) | High (new processes) |
| Duration | 9 to 18 months | 18 to 30 months |
| Business Risk | Medium (unchanged processes) | High short-term, low long-term |
Two possible readings of this table. If customization is moderate and configuration recent, brownfield upgrade remains the most economical option at 3 years. If custom code exceeds 40% and processes date from before 2017, a greenfield costs more in initial investment but avoids paying technical debt for ten years.
Governance Errors That Sink an Upgrade
Treating the upgrade as an IT project. This is the mother error. A major upgrade touches accounting, sales, purchasing, payroll, reporting. Without business management sponsorship and operational steering committee, the upgrade becomes IT affairs, and end users suffer it.
Under-budgeting testing. The temptation is strong: the project is behind schedule, we cut corners on testing. Result: bugs emerge in production with the user, and each bug costs ten times what it would have cost to detect in UAT. According to the Panorama Consulting Group 2025 ERP Report, the three dominant causes of budget overruns are understaffing (38%), scope expansion (35%), and technical or data problems (34%) - all three converge on the same blind spot: testing.
Keeping customizations “just in case.” An unused but migrated customization is technical debt you’ll pay at every subsequent version upgrade. The upgrade is the time to clean up. Refuse the logic “we keep it just in case.”
No rollback plan. If the cutover derails, what’s the procedure for returning to the old system? How many hours to restore? Until what time of the cutover can you rollback without loss? No project should start without these documented and tested answers.
Renewing the historical integrator without competitive bidding. The partner who implemented your ERP in 2017 knows your configuration, it’s a strength. They also know the historical compromises they themselves created, it’s a weakness. Competitive bidding, even symbolic, forces documenting the existing and comparing approaches. It also lowers prices by 10 to 25%.
Key Takeaways
A major upgrade is not an update. It touches architecture, data model, ergonomics, processes. It costs proportionally more than a new project when customization is high, and it’s often the right time to arbitrate the “upgrade or re-implementation” question rather than punt it.
The pressure is real for 2026. SAP ECC shuts down in 2027 with paid extension until 2030. S/4HANA on-premise Compatibility Packs close in May 2026. Sage 200 Manufacturing is no longer supported since end of 2025. Odoo pushes one version per year. CIOs starting their fit-gap audit today arrive in time to plan, budget and negotiate. Those waiting until June 2026 to start will arbitrate urgently, and urgency costs money.
Further Reading
If this article helped you, two complementary reads in the blog:
- ERP Migration: Complete Guide to System Change, the global method when not staying with the same vendor.
- SAP S/4HANA: Compatibility Packs Deadline May 2026, detailed contractual reading of the SAP window.
- ERP Total Cost of Ownership: The 8 Hidden Costs, to go beyond license price.
To validate your upgrade hypothesis before signing, start with a sandbox POC of 6 to 10 weeks on reduced scope (one entity, two or three critical processes). Typical budget: $40-80K. Deliverable: precise gap mapping, documented costing of customizations to redo, and factual Go/No-Go. It’s cheaper than a two-quarter derailment on a seven-figure project.
