Ask an ECC team how many custom objects they run and someone will produce a number within the hour. Ask which of those objects still earn their keep, and the meeting usually goes quiet.
That silence is where most S/4HANA timelines are lost. Converting a near-vanilla ECC system is a known quantity; SAP and its partners have done it thousands of times. The months nobody budgeted for come from custom code: Z-programs, user exits, modified standard objects and reports written for people who left the company a decade ago.
How custom code sets the schedule
In ECC, changing SAP’s standard code was an accepted way to fit the system to the business. S/4HANA Cloud does not allow it. Extensions have to sit on released, upgrade-stable interfaces, either inside the system through approved extensibility or outside it on SAP Business Technology Platform.
The data model shifts underneath as well. Financial postings consolidate into the Universal Journal, table ACDOCA. Inventory movements move into MATDOC. Any custom program that reads or writes the old structures directly will either fail outright or quietly return the wrong answer, which is worse.
So every custom object needs a verdict: retire it, replace it with standard functionality, or rebuild it the clean way. Reaching those verdicts and doing the rework is the critical path of a brownfield program. It also explains why IT teams running heavily modified ECC systems spend most of their week on upkeep. Every support pack and every enhancement package upgrade has to be regression-tested against code nobody fully understands.
Most of it was never a differentiator
When our team runs a structured assessment of an ECC custom estate, 60 to 70 percent of the objects typically turn out to be debt rather than advantage.
The reasons repeat. Some code patched a gap in an older SAP release that standard S/4HANA now covers. Some supported a process the business dropped years ago, and nobody deleted it. And some exists only because the first rollout, years back, skipped a configuration setting that would have done the job. SAP’s own usage logging makes the pattern visible quickly: switch it on for a few months and a large share of custom objects simply never run.
The remaining 30 to 40 percent matters a great deal. That is where your pricing logic, quality holds, customer-specific labeling or plant scheduling quirks actually live, and it has to come through the move rebuilt on stable ground.
Dead code is easy to delete once you can see it. What hurts is the handful of objects whose purpose no one on the current team can confidently describe. Those get carried forward out of caution, and they become the next decade’s debt.
Where the surviving code should go
Clean core is SAP’s term for keeping the ERP as close to standard as possible and placing your differentiation where upgrades cannot break it. Light changes become in-app extensions built on released APIs. Anything heavier moves side by side onto SAP BTP: SAP Build for custom apps and workflow, SAP Integration Suite for the connections to MES, PLM, EDI partners and the rest of the plant, and SAP Business Data Cloud (which now includes Datasphere) for the reporting and data work that used to be bolted onto ECC through custom tables.
The payoff is practical. When SAP ships an update, your extensions keep working, and your team stops spending each upgrade cycle re-testing old code paths.
The date your business case is missing
This is the part I rarely see in an S/4HANA business case, and it belongs on page one.
SAP’s AI agents and Joule assistants are built against standard processes and released interfaces. At Sapphire 2026, SAP said it had built 224 agents and 51 assistants across finance, spend, supply chain, HR and customer processes. An agent that reconciles intercompany postings or reprioritizes purchase requisitions expects the process to run the standard way. Where a custom program has replaced that process, the agent either cannot see it or cannot act on it without manual workarounds.
For a brownfield conversion carrying a large custom estate, that creates a lag. The system can go live on S/4HANA while remediation is still underway, and AI capabilities switch on only as each affected process is cleaned up. On a heavily modified estate, that lag can stretch a year or more past go-live. A company that starts on a clean core has the standard processes the agents expect from its first day in production.
Go-live and AI-ready are two separate dates. Most business cases show only the first.
Choosing between brownfield and greenfield
None of this makes brownfield the wrong answer. Plants with intricate production rules, tightly wired supplier and customer integrations, or audited compliance workflows often should convert, and RISE with SAP is built to carry that complexity. The business case simply has to be honest about how long remediation takes and when the AI layer becomes fully usable.
Greenfield deserves a harder look than it usually gets when the ECC instance is relatively young, when the custom estate is modest, or when a carve-out has left the business holding inherited customizations it never needed. In those situations, standard S/4HANA usually covers much more of today’s setup than the in-house team expects. KloudData’s greenfield RISE projects for mid-market manufacturers typically go live in 6 to 12 months, against a common 18 to 36 months for heavily customized brownfield programs.
Two moves before you pick a path
For the CIO: before committing to a conversion approach, get a usage-based inventory of your custom objects and force a keep, replace or retire decision on each one. The share you can retire will tell you more about the right path than any slide deck.
For the CFO: insist on two dates in the business case, the go-live date and the date the AI capabilities you are paying for become usable across finance and supply chain. Then put a value on the quarters between them.
Clean core used to be an argument architects had with each other. Now it decides how quickly the business sees the return it is paying for.
Frequently Asked Questions
What percentage of ECC custom code is usually unnecessary?
In KloudData's assessments, 60 to 70 percent of custom objects in a typical ECC estate are retirable or replaceable by standard S/4HANA functionality. The remaining 30 to 40 percent usually carries real business logic.
Why does custom code delay SAP's AI agents?
Joule agents and assistants are built on standard processes and released APIs. Where custom code replaces a standard process, the agent cannot act on it until that process is remediated.
Should we choose brownfield or greenfield for S/4HANA?
Brownfield suits complex, highly integrated or regulated operations. Greenfield deserves serious evaluation for younger ECC instances, modest custom estates and post-carve-out businesses.
