S/4HANA Migration: SMEs 2026 Before Decision
7 Min. read time
SAP is ending regular maintenance for Business Suite 7 on December 31, 2027. This is no longer a threat, but a date already marked in the calendars of many mid-sized companies. Those who don’t decide in 2026 will still decide. Only then with fewer options and a negotiating position that weakens every quarter.
Key Takeaways
- Three years remaining sounds like a lot, but it’s tight: An honest S/4HANA migration for mid-sized companies costs between eighteen and thirty months of project time. Those who start in early 2026 will finish with the usual buffer. Those who start in 2027 will be under pressure.
- The maintenance trap is more expensive than migration: SAP’s Extended Maintenance will cost two percent on top of the annual maintenance contract starting in 2028. Custom Code Support via third parties is even higher and offers no reliable regulatory guarantee.
- The management question is not technical: S/4HANA is a platform decision with implications for process standardization, data model, and sales channel. Those who delegate this lose control over subsequent costs.
Related:RevOps: AI in CRM ends data silos / Bitkom 2026: Mid-sized companies and ERP migration
What is the S/4HANA Maintenance Trap?
What is the S/4HANA Maintenance Trap? The maintenance trap describes the situation of a company whose SAP ERP landscape continues to operate without a clear migration path after the end of regular mainstream maintenance for Business Suite 7 (end of 2027). Consequence: Those who remain on the existing system pay Extended Maintenance with a surcharge, lose the right to new feature developments, bear the risk of regulatory changes without manufacturer updates, and reduce their negotiating leverage in future license or hosting discussions. The trap is not technical, but a gradual shift in the risk profile at the expense of management
Three Migration Paths, Three Trade-offs
The decision-making logic for mid-sized companies narrows down to three realistic paths. Each has a clear profile and a price that management needs to be aware of.
Path one: Brownfield conversion. The existing ECC is upgraded to S/4HANA, with the data model and custom code migrating along. Advantage: short project duration, averaging fourteen to eighteen months, less change management. Disadvantage: all legacy issues from the last twenty years remain in the system. Anyone with a mature ECC system featuring one hundred forty Z-reports and a proprietary materials management extension will carry that baggage.
Path two: Greenfield with S/4HANA Cloud Public Edition. Standardization on SAP’s cloud setup. Advantage: significantly lower Total Cost of Ownership over five years, as maintenance and updates are handled by the vendor. Disadvantage: less customizing allowed; the business model must align with SAP’s standard setup. We have seen engagements where this worked well. We have also seen two that reverted to on-premise after eighteen months.
Path three: Selective Data Transition. A deliberate selection of what is migrated and what is rebuilt in the new system. Advantage: pragmatic cut, legacy issues are left behind in a controlled manner. Disadvantage: high project effort, high demands on internal stakeholders who must actively support the trade-offs. This path requires a strong internal project team; otherwise, it risks devolving into an uncontrolled greenfield with customizing attachments.
What Management Must Decide in 2026
The path decision is not the first step. Prior to that are a series of management questions that many mid-sized companies haven’t honestly answered. We have organized them into four blocks.
First: Which processes are a competitive advantage today, and which are competitive standards? Everything that is standard belongs in the standard workflow of S/4HANA. Custom code at this point is an expensive legacy, not a differentiator.
Second: How robust is the current data model? A migration is the last realistic opportunity to clean up master data and material masters. Those who miss this will drag the old problems into the new system.
Third: Which individuals must support the project? Management decides, the CFO pays, the CIO builds. In mid-sized companies, however, a fourth person often determines success: the individual with the greatest process knowledge, who sometimes has been with the company for fifteen years and knows ECC inside out. Without them, there’s no clean data transfer.
Fourth: How does the company handle conflicts between standard and special cases? This question sounds soft, but it is the toughest of the four. It determines whether the project finds a standard path or spirals into customizing.
Platform Decision Instead of Software Update
An S/4HANA migration in mid-sized companies is rarely a pure software project. It shifts three things simultaneously. The data model is re-established. Processes are standardized. The contractual basis with SAP is renegotiated.
Anyone who treats this as a software update relinquishes control over the first two topics and loses negotiation leverage on the third. We often see managing directors who, at the project kickoff, only had a technical goal on the slide. The same managing directors eighteen months later find themselves discussing whether the implemented data model fits their own sales logic. This discussion belongs at the beginning, not the end.
One must be honest: not every migration is a success. The engagements we are familiar with ultimately ranged between plus twelve percent operational efficiency and zero change with significantly increased license costs. The difference was rarely due to technology. It almost always came down to how honestly management had grappled with its own process portfolio beforehand.
Migration Path Comparison: Brownfield vs. Greenfield
More from the MBF Media Network
- cloudmagazin: Platform or Facade: What Platform Engineering 2026 Must Deliver
- cloudmagazin: Compliance Costs: Architecture Decides
- Digital Chiefs: AI Governance 2026: System-Level Instead of Use-Case-Level
Source Cover Image: Wikimedia Commons / Vladislav Bezrukov (CC BY 2.0)
