Retrospective note. The original 6 January 2015 date is retained. This analysis discusses the later launch and subsequent developments, not facts known on that date.
The SAP S/4HANA launch was staged in New York on 3 February 2015, which tells you most of what you need to know about who the announcement was really for. SAP called it the next-generation business suite — Business Suite 4 SAP HANA — rebuilt on an in-memory database, with a simplified data model and a new user experience. Analysts heard a technology story. Anyone running SAP ECC heard something else: a clock had started. That reframing is the reason the launch still matters. S/4HANA was presented as innovation, and in engineering terms a great deal of it was. But for the installed base, the operative fact was that the platform they had spent fifteen years customising was now the previous generation, and the maintenance horizon for it would become the single most consequential line item in enterprise IT planning for the following decade.
What actually changed under the hood
The technical case was real and worth separating from the commercial one. The data model was simplified. Decades of aggregate and index tables existed for one reason: reading from a row-store disk database at scale was slow, so SAP pre-computed totals. An in-memory columnar store made many of those tables unnecessary. In finance, the change consolidated separate ledger and controlling tables into a single universal journal — one line-item table serving financial accounting, controlling, asset accounting and margin analysis. That is not a marketing simplification; it removes entire classes of reconciliation between modules that previously had to be kept in agreement. The user experience changed. Fiori replaced transaction-code navigation with role-based apps, which mattered less to power users and considerably more to occasional ones. And the deployment options multiplied. Cloud, on-premise and hybrid were offered from the start, with the first on-premise release arriving later in 2015. That optionality was genuinely new for a suite of this weight. A vendor customer announcement does not establish completed migrations or the share of an installed base migrated. No unverified October customer count or completed-migration inference is asserted here.
The migration deadline nobody wanted to discuss
The commercial mechanism sitting behind the announcement was end of mainstream maintenance for the previous suite. The date has been revised more than once — pushed out, then supplemented with an extended-maintenance option at additional cost, then reinforced by incentives to move earlier. The specifics matter less than the structure: a large installed base was given a finite horizon on a platform that runs their financials, and a single upgrade path presented as the answer. The result was a decade of deferred decisions. A great many organisations did the same three things in sequence: commissioned a readiness assessment, concluded that the business case was not compelling on its own merits, and waited. Then commissioned another assessment two years later. That behaviour is easy to mock and hard to fault. A migration of this type is not an upgrade. For most estates it is closer to a re-implementation: a new data model, a decision about whether to carry forward custom code written by people who left years ago, a reconsideration of every integration, and a testing programme that consumes the finance function for months. Asking a CFO to fund that on the basis of faster reporting, when the current system produces correct numbers, was never going to succeed. The projects that got funded were the ones bundled with something the business actually wanted — a merger integration, a new market entry, a shared services consolidation, a regulatory mandate.
Greenfield, brownfield, and the honest third option
The implementation debate settled quickly into two named approaches and one unnamed one. Greenfield means a new implementation with process redesign, migrating master data and open items but leaving the historical customisation behind. It produces the cleanest outcome and requires the most organisational appetite, because it forces the business to accept standard processes it previously paid to avoid. Brownfield means a technical conversion of the existing system in place. It preserves history and custom code, lands faster, and carries forward the accumulated complexity — including the complexity that made reporting slow in the first place. The third option, rarely named in a steering committee but common in practice, is selective transition: convert the entities or processes where the case is real, leave the rest, and run both for longer than anyone planned. This is messier than the slide deck versions and is frequently the correct answer for a group with heterogeneous subsidiaries. The decision that consistently predicts success is what happens to custom code. Organisations that used the migration as an excuse to delete unused developments, retire workarounds for problems that no longer exist, and push remaining extensions onto a side-by-side platform rather than into the core came out with a maintainable system. Organisations that ported everything got the new database and kept every old constraint.
| Approach | Decision to examine |
|---|---|
| Greenfield | How much process redesign and standardisation will the business accept? |
| Brownfield | Which sound processes, history and necessary customisations should remain? |
| Selective transition | Which entities or processes have a case for change, and how will coexistence be governed? |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
Practical Guidance for S/4HANA Readiness Assessment
- Start with a custom code inventory and usage telemetry. The single most useful input is knowing which of your developments actually executed in the last twelve months. In most estates a significant share has not run at all.
- Tie the migration to a business event, not to a maintenance date. Projects funded purely by end-of-support anxiety are under-scoped and under-sponsored. Projects attached to an acquisition, a market entry or a finance transformation get the attention they need.
- Decide the target operating model before the technical approach. Greenfield versus brownfield is a consequence of how much process change the organisation will accept, not an independent technical choice.
- Cost the testing honestly. Regression testing across finance, procurement, supply chain and every integration is typically the largest line in the plan and the first one compressed when dates slip.
- Extend outside the core. Put new logic on a side-by-side platform with clean interfaces so the next upgrade is not another archaeology project.
- Sequence entities deliberately in a multi-country group. Localisation, statutory reporting and tax requirements differ enough that a single big-bang cutover across jurisdictions is a risk concentration with no compensating benefit.
- Fix master data before the conversion, not during it. Duplicate vendors, inconsistent material masters and orphaned cost centres migrate perfectly well and remain problems afterwards.
- Negotiate the commercial terms as part of the readiness work. Licensing, cloud commitments and maintenance treatment are more negotiable during a migration decision than at any other point in the relationship.
The Regional Dimension
In the Gulf, the S/4HANA question arrived attached to a set of local requirements that changed the sequencing. The most significant is tax and e-invoicing. The introduction of VAT in the UAE and Saudi Arabia, followed by Saudi Arabia's phased e-invoicing regime under ZATCA with its clearance and reporting integration, turned finance system capability into a compliance question with regulator-set deadlines. For a number of regional groups, that — not the maintenance horizon — was the event that funded the ERP programme. Corporate tax in the UAE added another compliance driver more recently. Structure is the second factor. A typical regional group operates a mainland entity, one or more free-zone companies, a Saudi subsidiary and often branches across several other Gulf markets, with different ownership, different statutory reporting and different labour regimes. Assess statutory and management consolidation as separate requirements, including the exact product, edition, configuration and integrations. A universal journal alone does not establish group-consolidation coverage or a stronger regional business case. Payroll and workforce processes need local treatment regardless of platform: wage protection file submission in the UAE, end-of-service gratuity accrual, GOSI contributions and nationalisation ratio reporting in Saudi Arabia. Many groups keep these in a specialist local system and integrate, which is usually the right call. Two practical constraints round it out. Regional estates are often implemented and maintained by integrators, so the custom code inventory and the decision rights over it sit partly outside the organisation — get that on the table early. And bilingual master data, with Arabic names alongside inconsistent English transliterations, makes data cleansing a larger workstream than the plan usually assumes.
The objection worth taking seriously
There is a reasonable position that says the whole exercise is value destruction: a functioning system replaced at enormous cost because a vendor changed its architecture, with benefits that accrue mostly to the vendor. That critique has force, and the honest response is that it depends entirely on what the organisation does with the opportunity. A conversion that preserves every existing process and every existing extension delivers a faster database and a large invoice. There is no serious argument that this is good value. The defensible version is different: a finance function that removes reconciliation between subledgers, retires a thousand unused developments, standardises processes across entities that had drifted apart, and ends up with a system that a new subsidiary can be added to in weeks rather than quarters. That outcome is worth real money — but note that almost none of it comes from the in-memory database. It comes from the organisational discipline that the migration provided cover for. Teams that understood this bought a transformation and used a platform change to fund it. Teams that did not bought a platform change.
Common Questions
Is the migration really mandatory?
Functionally, no — systems do not stop working when mainstream maintenance ends, and third-party support providers exist and are used. Practically, the pressure is cumulative: regulatory changes stop being delivered, integrations with newer products become harder, auditors start asking questions, and the talent market for the old platform thins out. Most organisations conclude that the question is when rather than whether.
Greenfield or brownfield?
Brownfield when the existing processes are sound and the priority is speed with minimal disruption. Greenfield when the existing configuration reflects decisions nobody would repeat and the organisation has the appetite for process change. A useful tie-breaker: if more than a modest fraction of custom code would be carried forward without a clear owner willing to defend it, greenfield is probably being avoided for political rather than technical reasons.
How long should a readiness assessment take?
Weeks, not quarters. Its job is to produce a custom-code inventory with usage data, a data quality baseline, an integration map and a defensible cost range — enough to make a go or no-go call. Assessments that stretch into multi-month studies usually indicate that the organisation is using analysis to defer the decision.
Does AI change the migration calculus?
It sharpens the argument for a clean core. AI features and agents built on enterprise data depend on consistent, well-structured records and documented process semantics; they perform badly against a data model buried under a decade of workarounds. Code remediation tooling has also made custom-code analysis meaningfully cheaper than it was. Neither fact creates a business case on its own, but both raise the cost of continuing to defer.
S/4HANA Readiness Assessment — the migration only pays for itself if you use it to remove complexity you can no longer justify, because the database change alone will not show up in any number the business cares about.