Contents
This is my favourite case study. A well-known Middle Eastern retailer in fashion and consumer goods moved from SAP ECC 6.0 to S/4HANA. It had about 18,000 employees, more than 1,200 outlets across seven countries and a growing e-commerce channel. It had run ECC for years, and 44 percent of its system objects were customised. We chose a brownfield conversion with selective redesign. Month-end close went from stretching into weekends to finishing before lunch, and custom code fell by nearly half.
If you run a heavily customised ECC system and wonder how much of it to carry forward, this is how one programme answered that question.
The customisation had built up slowly, one urgent fix at a time. By the time we started, even small updates carried risk. Integrations were fragile: a small change in finance could break something in retail operations. The business wanted flexibility and speed. IT was consumed by firefighting. Both sides admitted they were working at cross-purposes.
I remember a session where the supply chain team laughed a little when they admitted that dozens of their "critical" reports were barely touched anymore. Cutting them away was both practical and oddly freeing.
The end of ECC mainstream maintenance was the trigger. SAP ERP 6.0 on enhancement packages 6 to 8 leaves mainstream maintenance at the end of 2027 (SAP News). The real drivers were deeper. Finance ran manual extracts every month-end. Stores needed stock visibility that overnight batch jobs could not give. Most of IT's effort went into keeping custom code alive.
The SAP Readiness Check confirmed what we suspected: a heavily customised system with significant remediation ahead. The Simplification Item List showed where standard S/4HANA already did what custom ECC code had been doing. Finance discovered that some long-maintained custom reports were now redundant. The relief in that meeting was obvious.
A straight technical conversion would only have pushed the problems forward. A full greenfield rebuild would have thrown away a decade of working configuration. Brownfield with selective redesign was the balance: keep what was solid, clean what needed cleaning, rebuild only what was broken. My ECC to S/4HANA migration guide explains how to weigh those paths.
| Challenge | What we did |
|---|---|
| 44 percent customised objects | Business and IT tagged each object together: retire, replace or refit; quality gates per phase |
| Fragile integrations | Regression plan covering POS, WMS, finance, HR and vendor portals; point-to-point links moved to SAP Integration Suite patterns |
| Data quality | Data stewards per function with SLAs; daily defect tracking; cleansing finished before QA |
| Adoption across countries | Role-based job guides, floor-walks near go-live, training tied to real job tasks |
Custom code at scale
The readiness results worked as a filter. Business and IT sat together to tag every object. Some were clearly redundant, like reports nobody could remember running. Others supported genuinely unique retail processes and needed careful redesign. It forced teams to decide rather than postpone. SAP Signavio helped define the new processes against best practice, and smartShift handled automated code scans and low-value fixes, which kept senior time for redesign. My clean core guide covers how I classify custom code today.
Integrations
ECC connected to point-of-sale (POS) systems, the warehouse management system (WMS), finance, HR and several vendor portals. We built a regression plan across all of them and tested after every significant configuration change, not only at the end. Overnight batch jobs had to finish faster in S/4HANA, or the warehouse's morning reports would not be ready.
Data quality
Duplicate vendor records and outdated master data dragged out testing. The fix was structural: a data steward in each function, with SLAs for resolution. If data was not clean by the start of QA, it went back to the steward. As cutover approached, we rehearsed loads end to end and tracked defects daily. That simple routine worked better than any fancy dashboard, which still surprises me. My article on why SAP data migration fails covers the pattern.
Adoption
Training reached 26,000 employees. Finance and retail operations had different priorities, which surfaced in an early workshop and changed the training design. As pressure rose near go-live, we used role-based job guides and floor-walks. A store lead later said the two-page guide mattered more than any town hall. I believed her.
Phased delivery on SAP Activate. Core finance and supply chain moved first, with HR and vendor portals later, so support teams were never overloaded. Each environment had one job. Sandbox validated the path and locked scope. Development hardened transports. QA ran real business volumes and tuned jobs. Pre-production was a genuine dress rehearsal. Deployment dates were aligned to retail peak and low seasons.
Testing with the business. Finance and supply chain leads tested against real period-close and promotion cycles, with scripts written around business reality rather than system logic. Night runs exposed timing issues. I recall a warehouse lead smiling when the second run went through smoothly after weeks of frustration.
Cutover rehearsals. Every task was timed, trimmed or merged. The dry run alone saved hours that a spreadsheet never revealed. Recovery plans sat on one-page handouts, and people said that simple list reduced stress more than any dashboard. A store pilot proved POS and WMS stability before the wider rollout.
Hypercare. A shared war room for IT and business, clear SLAs and daily action logs. Weekend shifts were rotated and support handovers were scripted to the minute. People usually remember numbers. I remember the first quiet night most.
One finance lead joked that the system finally worked faster than the coffee machine.
Finance close. Teams said month-end now finished before lunch, where it once pushed into weekends. The CFO was most pleased that he had his reports much faster. One finance lead joked that the system finally worked "faster than the coffee machine". That kind of moment builds more confidence than any slide deck.
Custom code. Down by nearly half, which lowered the long-term support burden and the regression risk at every future upgrade.
Reporting and user experience. Store managers moved from old transaction screens to SAP Fiori apps. Training time fell because the apps worked the way people expected. One manager called it "refreshing".
Integrations. POS, WMS and finance connections became more stable, and overnight jobs finished earlier.
Not everything landed evenly. Some teams held on to old reports when better ones existed. Some felt the workshops were too long and the rehearsals repetitive. In hindsight, those steps were the safety net.
| Lesson | What happened | What I would do next time |
|---|---|---|
| Align early | In one workshop, store managers said their reporting needs were very different from finance. It surfaced early and we adjusted; later, it would have blown up at cutover | Schedule structured alignment sessions before design starts |
| Start the code review on day one | Several objects were reworked under pressure near go-live | Make retire, replace or refit decisions from kickoff |
| Make data a business job | Duplicate vendor records slowed testing | Name function-level data stewards with SLAs in week one |
| Rehearse more than feels necessary | A dry run revealed sequencing conflicts between POS and WMS that nobody had predicted | Plan extra rehearsals; the last one before go-live should feel boring |
If the same programme started today, three things would change. Most companies in this position would now look at S/4HANA Cloud Private Edition under RISE with SAP rather than staying on-premise. The retire, replace or refit decisions would be framed against SAP's clean core levels A to D. Change and deployment tracking would run in SAP Cloud ALM, because Solution Manager 7.2 leaves mainstream maintenance at the end of 2027. The data stewards, the rehearsals, the joint war room and the two-page guides would all stay exactly as they were. For the people side, see my guide to SAP training strategies.
Why do companies move from SAP ECC to S/4HANA?
The end of ECC mainstream maintenance in 2027 is the trigger. The stronger reasons are operational: real-time reporting, a faster close and less effort spent keeping custom code and fragile integrations alive. In this case the business wanted live retail analytics and a shorter month-end close.
What did the SAP Readiness Check show in this case?
It confirmed that 44 percent of the objects were customised and that many had not been used in years. That changed how the custom code work was structured: retire first, replace with standard where possible, and refit only what had real business value. The Simplification Item List also showed reports that standard S/4HANA made redundant.
Why choose brownfield with selective redesign?
A straight technical conversion would have carried every problem forward, and a full greenfield rebuild would have discarded a decade of working configuration. Selective redesign kept what was solid, used SAP Signavio to define new processes where standard could replace custom logic, and rebuilt only what was broken.
What happens if you leave data cleansing too late?
Testing drags, rehearsals fail and go-live slips. Here, duplicate vendor records and outdated master data caused weeks of friction in testing. The fix was data stewards in each function with SLAs, and cleansing tracked as a programme health measure.
How were integrations handled during the migration?
By mapping every connection first: POS, WMS, finance, HR and vendor portals. A regression plan covered all of them, tests ran after each significant configuration change, and a store pilot proved POS and WMS stability before the wider rollout. A dry run still found a sequencing conflict between POS and WMS that nobody had predicted.
What does good hypercare look like after an S/4HANA go-live?
A shared war room for IT and business with clear SLAs, daily action logs and issues closed quickly rather than parked in a backlog. Role-based guides and floor-walks reduce support calls faster than formal training. Rotate weekend shifts and script handovers so the team does not burn out.
Written by
