Enterprise10 min read

Nine Plants. One Core. Zero Missed Shipments.

A 12-month ECC to S/4HANA conversion that never stopped the line.

Kiran Jupudi

Kiran Jupudi

Published 12 March 2025

S/4HANA migration case study

Nine manufacturing plants across four countries ran on a 15-year-old SAP ECC system that nobody dared touch. We, at Futluz, led a 12-month brownfield conversion to S/4HANA 2023—custom code remediation, Business Partner consolidation, Universal Journal migration, and four full dress rehearsals—delivered over a single 58-hour weekend. Not one customer shipment was missed.


TL;DR

Problem: ECC 6.0 EhP7 on Oracle, 9.2 TB, 4,380 custom objects, mainstream maintenance ending in 2027. Nine plants that cannot stop.

Approach: Brownfield system conversion using SUM with the Database Migration Option (DMO), preceded by aggressive archiving, usage-based custom code decommissioning, and Customer/Vendor Integration. Four mock conversions before the real one.

Scale & results: 11 company codes, 5 currencies, 143 interfaces, 186,400 business partners. Business downtime of 58 hours against a 72-hour plan. MRP from 11 hours to 35 minutes. Month-end close from 9 days to 5.

Why it worked: A single multi-disciplinary team—business analysts, program managers, developers and QA—held together for 12 months, plus the discipline to rehearse the cutover until it was boring.

We had been told for three years that this would take two years and break something. It took twelve months and broke nothing. On Monday morning the lines started and the trucks left. That is the whole review.

Ma***, *******

VP, Global Manufacturing Systems

The client challenge

Our client builds precision components in nine plants across the United States, Mexico, Germany and India. One SAP ECC 6.0 EhP7 instance on Oracle ran all of it: production planning, shop floor confirmations, warehouse movements, quality inspection lots, procurement, and the finance close for 11 company codes in 5 currencies under both IFRS and local GAAP.

The system worked. That was the problem. Fifteen years of accreted change had produced 4,380 custom objects, a 9.2 TB database that took eleven hours to run MRP, and a month-end close that consumed nine working days because FI and CO had to be reconciled by hand every period. Mainstream maintenance for ECC ends in 2027. Every year of delay made the eventual move larger.

Three constraints shaped everything that followed. The plants run 24/6, with a single maintenance window from Friday evening to Monday morning. The German and Indian entities carry statutory e-invoicing and reporting obligations that cannot lapse for a day. And nine MES systems, 62 EDI trading partners, and a third-party logistics provider all had live interfaces into the box we were about to replace.

Why brownfield conversion

We evaluated all three routes honestly. A greenfield re-implementation would have given the cleanest target but demanded a parallel design phase, full data migration, and a retraining programme across four countries—realistically 24 to 30 months, with the plants absorbing process change and system change at the same time. Selective data transition would have let us cherry-pick, but the tooling cost and the reconciliation burden were hard to justify when the client’s process design was, on inspection, sound.

We recommended a brownfield system conversion: keep the configuration, keep the history, keep the document numbers the auditors know, and change the platform. Process improvement was deliberately sequenced afterwards, as a second wave, so that go-live weekend had exactly one variable.

The preparation phase was where the real decisions got made:

  1. SAP Readiness Check: Produced the simplification item list, add-on and business function compatibility, sizing, and financial data quality findings. 217 simplification items were relevant; 34 required active remediation before conversion.
  2. Maintenance Planner: Confirmed every add-on had an S/4HANA-compatible successor and generated the stack definition. Two third-party add-ons did not—one was replaced with standard functionality, one with a small custom build.
  3. Usage-based code triage: We ran the ABAP Call Monitor (SCMON) for six months across production before deciding anything. Of 4,380 custom objects, 2,600 had never been executed. They were retired rather than remediated—the single largest saving in the programme.
  4. ATC remote analysis: The remaining 1,780 objects were checked against the S/4HANA readiness variant from a central ATC system. 6,900 findings, of which roughly 2,300 needed genuine engineering judgement rather than a mechanical fix.
  5. Archiving first: Six months of archiving and cleanup took the source database from 9.2 TB to 4.4 TB before the first mock even started. Every terabyte removed came straight off the downtime clock.

Our solution

  1. Business Partner consolidation
    • Customer/Vendor Integration is a hard prerequisite in S/4HANA, and it is where brownfield programmes go to die. 214,000 customer and vendor master records, accumulated across four countries and two acquisitions, had to converge on a single Business Partner model with consistent number ranges, roles and groupings.
    • Business analysts spent eleven weeks on data quality alone: duplicate detection, address normalisation, tax number validation per jurisdiction, and adjudication of records where the same supplier existed three times with three payment terms. The final load produced 186,400 business partners and a documented exception list of 9,700 records with named owners.
  2. Finance: the Universal Journal
    • New Asset Accounting and the Material Ledger are mandatory in S/4HANA, and for a manufacturer the Material Ledger is not a formality—it changes how inventory is valued in every plant and every currency.
    • We ran the finance migration cockpit end to end: chart of accounts enrichment, merging primary and secondary cost elements into GL accounts, ledger and currency configuration, then migration of line items and balances into ACDOCA. Totals tables and the classic index tables are gone; reporting now reads one table.
    • Credit management moved from FI-AR-CR to FSCM. Reconciliation between FI and CO stopped being a task because the two are now the same record.
  3. Custom code remediation
    • Fourteen developers worked the ATC backlog in priority order: direct reads against removed tables, SELECT statements relying on implicit database ordering, native SQL, and access patterns that assumed the old inventory aggregate tables rather than the new material document model.
    • Two scope calls kept the programme honest. We kept material numbers at 18 characters rather than extending to 40, because the extension would have rippled into 62 EDI partners for no business benefit. And we deferred embedded EWM, keeping classic WM under its compatibility window, so that warehouse process redesign did not ride along with the technical conversion.
  4. Interfaces and the plant floor
    • All 143 interfaces were inventoried, owned and tested. 62 were rebuilt, mostly IDoc and RFC integrations whose payloads assumed the old data model. Nine MES connections were regression tested plant by plant, on plant hardware, with the plant’s own scanners.
  5. Fiori, roles and the people using it
    • Rather than deploying a catalogue nobody asked for, we mined a year of transaction usage data and shipped the apps that matched what people actually did—production operator confirmations, inventory lookups, buyer worklists, and the finance close cockpit—organised into spaces and pages by role.
    • Authorisations were rebuilt against the new catalogues rather than carried forward, which was slower and correct.
  6. Rehearse until it is boring
    • Four full mock conversions on production-sized copies. Mock 1 took 96 hours of technical runtime. By mock 4 it was 27, through R3load process tuning, table splitting, benchmarked sequencing, and the archiving already banked.
    • Mock 2 failed at 03:00 on hour 41 on a Business Partner data defect. The team recovered the system, root-caused it by that afternoon, and re-ran the mock the following weekend. That failure is the reason go-live worked.
    • The cutover runbook grew to 640 tasks with named owners, dependencies, elapsed-time estimates and go/no-go gates. It was executed four times before it mattered.

Twelve months, one team

Forty-one people at peak, and—unusually—largely the same forty-one from month one to month twelve. Nine business analysts, three program and workstream managers, fourteen developers, eight QA engineers, and a Basis and security core, working alongside the client’s own plant and finance SMEs.

The business analysts did the least glamorous and most decisive work. They sat on plant floors in Monterrey and Pune watching how confirmations were really entered, not how the process document said they were. They adjudicated tens of thousands of master data records one screen at a time. When the Material Ledger changed inventory valuation, they walked plant controllers through the new numbers until the controllers could explain it themselves.

QA ran four full regression cycles across 3,100 test scripts, 2,100 of them automated by go-live. They simulated the month-end close four separate times in a copy of production, because the first close after a conversion is where an unexamined assumption becomes a restatement. Three of those simulations found something.

The program managers held a line that is easy to describe and hard to keep: no scope additions after month five. Every good idea—and there were many—was logged for wave two rather than absorbed. That discipline, more than any tool, is why the timeline held.

And there were the weekends. Mock conversions run when plants do not, which meant seven weekends given up across the year, including the one after mock 2 failed, when nobody suggested slipping the date. The team went back in and ran it again.


The results

  • Downtime: 58 hours of business downtime against a 72-hour approved window. All nine plants resumed on schedule Monday morning.
  • Continuity: Zero missed customer shipments and zero statutory filing delays across four countries.
  • Planning: MRP from 11 hours to 35 minutes with MRP Live, moving planning from an overnight batch to something a planner can re-run before lunch.
  • Close: Month-end close from 9 days to 5, with FI/CO reconciliation eliminated by the Universal Journal.
  • Footprint: 9.2 TB on Oracle to 1.6 TB on HANA, after archiving and compression.
  • Custom code: 4,380 objects to 1,510 in production—a 66% reduction in the surface area anyone has to maintain.

What changed for the people using it

Planners re-run MRP when demand shifts instead of waiting for tomorrow. Plant controllers see inventory valuation without exporting to a spreadsheet. Operators confirm production on a tablet on the line rather than walking to a terminal. The finance team closes the books in a working week. None of these were the stated objectives of a technical conversion; all of them are why the client asked for wave two.

Business impact

Risk: Off a maintenance cliff, onto a supported platform with a defined innovation path.

Cost: Roughly 1,240 hours a year of manual reconciliation removed from the finance calendar, and two thirds of the custom estate decommissioned.

Speed: Planning and close cycles measured in minutes and days rather than nights and weeks.


An S/4HANA conversion is not really a database migration. It is twelve months of judgement calls about what to keep, what to retire, and what to defer—held together by a team that stays together. We bring the SAP depth and the programme discipline; the rehearsals are what turn both into a quiet Monday morning.

 

EnterpriseSAP S/4HANAManufacturing