The ECC → S/4HANA guide
Everything a CIO needs to size, de-risk, and win the move to S/4HANA.
Moving off SAP ECC before the 2027 deadline is a when, not an if. The programs that go well start the same way: they measure the estate honestly, retire the custom code that duplicates S/4HANA standard, and keep the extensions that genuinely differentiate — a clean core. This guide collects straight answers to the questions that decide that program: what a fit-to-standard assessment costs, what a Clean Core Score is, how much custom code you can retire, whether to run on RISE with SAP or on AWS, and how an AI agent can change configuration safely.
Every article leads with a direct answer, cites real SAP objects, and labels reference figures as such. Start with the three cornerstones below, or jump to any question.
All articles
How do you inventory SAP interfaces before an S/4HANA migration?
You inventory SAP interfaces before an S/4HANA migration by deriving the list from the system itself — RFC destinations, IDoc partner profiles and message types, the ALE distribution model, released OData and SOAP services, file-based batch jobs, and the custom programs that call any of them — and then filtering that raw list down to the interfaces that actually carried traffic over a recent period. The step most programs skip is the second one: an aging ECC estate almost always declares far more integration points than it runs, and the gap between declared and executing is the difference between a defensible cutover plan and a spreadsheet nobody trusts. For each surviving interface, record five facts — technology, direction, counterparty system and its owner, the business process it serves, and its S/4HANA disposition (carries forward, needs rework, retires). That inventory is what sizes integration regression testing, sequences the cutover, and exposes the third-party dependencies that sit on somebody else's release calendar rather than yours. It is cheap to produce from a live system and expensive to reconstruct from memory halfway through the build.
SAP interfacesIDocRFCintegrationECC to S/4HANAcutover planning6 minHow do you scope regression testing for an ECC to S/4HANA migration?
You scope regression testing for an ECC to S/4HANA migration from the custom code and process paths that actually execute in the live system, not from a percentage of the project budget or a copy of the last program's test plan. The workable method has four steps: inventory the custom objects and interfaces in the source system, establish which of them still run, map those to the end-to-end process variants that carry real document volume, and build the test scope from that intersection plus the standard paths S/4HANA changes on its own — business partner, credit management, material valuation, output determination. Scope built this way is defensible line by line, because every test case traces to an object or a document flow that someone can go and check rather than to a workshop estimate. It also shrinks as retirement decisions are made: custom code you retire before the conversion is code you never regression test, which is why disposition decisions are a testing lever and not just a clean-core one. On a reference estate — a live ECC system used to validate this approach, not a specific customer result — roughly 44% of 356 inventoried custom objects were assessed as retirable because standard S/4HANA already delivers the capability, and each retired object takes its test cases with it.
regression testingECC to S/4HANAtest scopecustom codemigration planning6 minWhy do ECC to S/4HANA migrations run over budget?
ECC to S/4HANA migrations run over budget mostly because the estimate is built at the point of least knowledge — before anyone has actually read the system. The proposal prices a scope drawn from interviews, an aging blueprint, and a Readiness Check summary, and then the first months of the program discover what is really there: custom objects nobody can name or defend, an enterprise structure that drifted from its design document through acquisitions, master data that fails the S/4HANA business-partner and field-length rules, and a regression-test scope that scales with the customizations actually found rather than the ones assumed. Every one of those becomes a change request, and scope priced mid-program costs more than the same scope priced before signature — both in money and in the schedule slack it consumes. The overruns are therefore rarely execution failures; they are estimation failures caused by treating discovery as an assumption instead of as evidence. The unglamorous fix is to read the live system before the statement of work is signed, so the number is anchored in object counts, usage counts, and document counts rather than in workshop recollection.
ECC to S/4HANAmigration costestimationfit-to-standardcustom code6 minWhat is the SAP enterprise structure, and why does it decide your S/4HANA migration approach?
The SAP enterprise structure is the set of organizational units every transaction is posted against — company code, controlling area, plant, storage location, sales organization, distribution channel, division, purchasing organization — and it is the one design decision an S/4HANA migration cannot easily revisit after the fact. It matters more than most technical scope items because it determines which migration approach is even available to you: a brownfield system conversion carries the existing structure forward essentially intact, while any intent to consolidate company codes, re-cut sales organizations, or merge controlling areas pushes the program toward a greenfield or selective-transition path with a materially different cost, timeline, and data-migration burden. The structure is also the foundation every other customizing setting hangs off — account determination, pricing procedures, output determination, credit control areas all key off these units — so documenting it accurately is a prerequisite for any fit-to-standard work, not a parallel task. In most twenty-year-old ECC estates the as-built structure has drifted from the original design document through acquisitions, divestitures, and org changes nobody backported into the blueprint, which is why the reliable way to capture it is to read the configuration tables in the live system rather than trust a document. Get this right early and the fit-to-standard conversation stays about process design; get it wrong and the first six weeks of the program become org-unit archaeology.
enterprise structureECC to S/4HANASPROconfigurationmigration approach6 minWhat is SAP ATC (ABAP Test Cockpit), and how does it decide S/4HANA readiness?
SAP ATC — the ABAP Test Cockpit — is SAP's built-in static-analysis engine for custom code, and when you run it with the S/4HANA readiness check variant it scans every custom object against the specific language and data-model changes S/4HANA introduces, then returns each finding as an error, warning, or information message with the exact line and rule that triggered it. It answers one narrow but essential question: will this object compile and run correctly after conversion, or does it use a table, field, or syntax pattern S/4HANA removed or restructured. ATC does not tell you whether the object should exist at all — whether anyone still executes it, or whether the business rule inside it has since become standard S/4HANA configuration. That second judgment needs usage evidence and a read of the business logic, which is why ATC findings are best treated as the technical remediation gate, not the scope decision. On a reference estate (a live ECC system we analyze end to end; a customer's numbers come from their own system) roughly 44% of custom objects were re-implementations of standard S/4HANA capability — objects ATC would have correctly flagged as needing remediation, and evidence-based fit-to-standard analysis correctly reclassified as candidates for retirement instead.
ATCABAP Test Cockpitcustom codeS/4HANA readinessclean core6 minHow do you map your SAP business processes when nobody documented them?
You reconstruct them from the system's own evidence rather than from documents, because in a twenty-year-old estate the documents are either missing or describe a design that was changed three times after go-live. There are three routes, in increasing order of reliability: workshops, which are fast but capture what people believe happens; process mining over extracted event logs, which is accurate on timing and variant frequency but says little about the custom code sitting behind each step; and a direct read of the live system — the document flow that links a sales order to its delivery, goods issue and invoice, plus the configuration and the custom objects attached to each of those transactions. The system-evidence route is the only one that gives you both the shape of the process and the customization bolted onto it, and that pairing is what an ECC to S/4HANA scope decision actually requires. The discipline that makes the result trustworthy is attribution: assign an object to the stage where the evidence puts it, and keep everything unproven in a visible unattributed bucket rather than smearing it across stages to make the picture look complete.
process discoveryprocess miningECC to S/4HANAorder to cashcustom code6 minWhat is SAP Readiness Check for S/4HANA, and what does it actually tell you?
SAP Readiness Check is a free, SAP-provided self-service analysis that you run against your existing ECC system to find out what would technically block or complicate a conversion to S/4HANA. You install the current SAP Notes, run the data-collection reports in ECC, and upload the resulting archive to SAP for Me, which returns an interactive dashboard covering relevant simplification items, custom code affected by those simplifications, add-on and business-function compatibility, sizing, integration interfaces, financial data quality, and recommended Fiori apps. It is the right first move for any ECC estate and there is no good reason to skip it — but it is important to understand its question: Readiness Check tells you what will break on conversion, not what should exist afterward. It inventories your custom objects against SAP's simplification list; it does not read the business rule inside an object, does not tell you whether anyone still calls it, and does not tell you that the rule has since become standard configuration. Those are the judgments that decide scope, and they need evidence the Readiness Check does not collect.
SAP Readiness CheckECC to S/4HANAsimplification itemscustom codefit-to-standard6 minWhat is the difference between fit-to-standard and fit-gap analysis in SAP?
Fit-gap analysis starts from your requirements and asks what SAP cannot do; fit-to-standard starts from SAP standard and asks what you are willing to change about the way you work. The difference is the direction of the burden of proof — in a fit-gap the gap is presumed legitimate until someone argues it away, and the deliverable is a development backlog; in fit-to-standard the standard process is the default and every deviation has to earn its exception, and the deliverable is a decision log. That inversion matters in an ECC-to-S/4HANA move because most of the "gaps" in a twenty-year-old estate are not business requirements at all, they are historical workarounds for capability SAP has since delivered as standard. On a reference estate (a live ECC system we analyze end to end; a customer's numbers come from their own system) an evidence-weighted read found 44% of custom objects were re-implementations of standard S/4HANA capability — gaps a classic fit-gap workshop would have quietly re-approved. The practical difference in outcome is a clean core versus a modernized copy of the system you already had.
fit-to-standardfit-gap analysisclean coreECC to S/4HANAcustom code6 minHow do you measure order-to-cash cycle time in SAP?
You measure order-to-cash cycle time in SAP by reading the sales document flow table VBFA, which links every sales order to the deliveries, goods issues, and billing documents that descend from it, and then computing the elapsed time between the creation timestamps of each linked pair. That gives you four intervals rather than one number — order to delivery, delivery to goods issue, goods issue to invoice, and invoice to cash clearing — and each interval belongs to a different owner, which is why a single blended "O2C days" figure is almost never actionable. Report the median and the 90th percentile rather than the average, because order-to-cash distributions are long-tailed: a handful of disputed or blocked orders will drag a mean far away from what your business actually experiences. You do not need a dedicated process-mining platform to get a first credible baseline — the document flow is already in the system, and a governed read-only query over VBFA joined to VBAK, LIKP, and VBRK produces defensible numbers in hours instead of a procurement cycle. On a reference estate (a live ECC system we analyze end to end; a customer's numbers come from their own system) that read covers 8,360 sales orders and their downstream documents, and the same method runs unchanged against S/4HANA.
order-to-cashcycle timeprocess miningVBFAprocess maps6 minHow do you build a business case for an ECC to S/4HANA migration?
A credible ECC-to-S/4HANA business case is built from four quantities read out of your own system rather than borrowed from a benchmark deck: the annual carry cost of the custom code you can retire, the rebuild effort you avoid by mapping custom objects to standard S/4HANA capability, the cycle-time and working-capital value released by the processes you are actually changing, and the ownership-cost difference between the deployment options you are choosing among. Every one of those numbers has to trace to a specific read — an object count, a lead time computed from document flow, a license or infrastructure line — because finance will discount any figure whose only provenance is a slide. On a reference estate (a live ECC system we analyze end to end; a customer's numbers come from their own system) an evidence-weighted read found that 44% of custom objects were re-implementations of capability S/4HANA now delivers as standard, carrying roughly $1.9M a year in avoidable cost. The other half of the case is the cost of doing nothing: mainstream maintenance for ECC ends at the end of 2027, so the real comparison is never migrate versus stand still — it is migrate on your schedule versus migrate on someone else's. Build the case as arithmetic over auditable inputs and it survives the finance review; build it as a benchmark narrative and it stalls there.
business caseECC to S/4HANAmigration ROITCOfit-to-standard6 minHow do you know if your SAP data is ready for an S/4HANA migration?
Your SAP data is ready for S/4HANA when the objects S/4 treats as mandatory or merged are already consistent in ECC: customers and vendors reconcile cleanly to business partners, material and customer masters satisfy S/4's changed field rules, FI/CO open items reconcile to the general ledger under the Universal Journal's single-table model, and there are no duplicate or orphaned records that will block conversion. The honest test is not a workshop or a questionnaire — it is a set of counts read directly from your live system: how many customers have no business-partner counterpart, how many masters fail the extended-field rules, how many documents sit in states that will not convert. Those counts are computable before a project starts, and they are the real input to your timeline, because data defects — not custom code — are the most common reason a conversion cycle has to be repeated. Run the checks against your own system first, size the remediation, and only then commit to a go-live date; a readiness number derived from your data beats any industry benchmark derived from someone else's.
data readinessS/4HANA migrationbusiness partnerECC to S/4HANAdata migration6 minIs it safe to connect an AI agent to a live SAP system?
Yes, if the connection is read-only, deployed inside your own network, and scoped by SAP's own authorization model — and no, if it is a broadly-authorized bot reaching your system over the open internet. A safe design reads through SAP's supported ADT interface under a least-privilege role, enforces read-only in code (a write-keyword blocklist rejects any statement that could change data before it reaches SAP), and runs from a connector deployed inside your environment so your SAP is never exposed to the internet. Analysis never writes to the system it reads; any configuration change is a separate, human-approved path that drafts a governed transport in a development client. The right question for a vendor is not "does your AI touch SAP" but "through what interface, under whose authorizations, from where, and can it write" — and every answer should be one you can hand to your security team before a single call is made.
SAP securityread-onlyagentic SAPgovernancefit-to-standard6 minHow long does an SAP ECC to S/4HANA migration take?
A typical SAP ECC to S/4HANA migration runs twelve to twenty-four months end to end, though a lean brownfield conversion can finish in six to nine months and a large greenfield re-implementation can stretch past two years. The single biggest driver of the timeline is not the technical conversion — it is the discovery and fit-to-standard phase, where a traditional systems integrator spends six to ten weeks inventorying custom code and interviewing process owners before the real work even starts. That front-end analysis is exactly the part agents now compress: an agent-led fit-to-standard read produces the clean-core score, retirement list, and business case in days rather than weeks, which is why the honest answer to "how long" is "less than it used to be, if you shorten discovery instead of rushing the build."
S/4HANAmigration timelinefit-to-standardbrownfieldmigration strategy6 minBrownfield vs. greenfield vs. bluefield S/4HANA migration: which is right?
The three approaches differ in how much of your ECC system you carry forward. A brownfield migration is a technical conversion — it lifts your existing configuration, custom code, and data onto S/4HANA in place, fastest and cheapest but it carries your accumulated complexity with it. A greenfield migration rebuilds on a clean, standard S/4HANA and re-implements only what the business needs, giving the cleanest core but at the highest cost and disruption. Bluefield (selective data transition) is the middle path: a new S/4HANA build into which you migrate chosen configuration and data, keeping what earns its place and leaving the rest behind. The right choice is not a matter of taste — it depends on how much of your custom estate is genuine differentiation versus re-implementations of standard capability, which is a question you should answer with evidence before you pick a path.
brownfieldgreenfieldbluefieldS/4HANAmigration strategy6 minWhat does an SAP ECC to S/4HANA fit-to-standard assessment cost?
A traditional SAP fit-to-standard assessment runs from roughly $150,000 to $500,000 and takes six to ten weeks, because a systems integrator staffs a team to inventory custom code, interview process owners, and hand-build a findings deck. An agent-led assessment collapses that: a free scan gives a calibrated clean-core estimate in under a minute from a few inputs, and a fixed-price connected assessment reads your live system read-only and returns evidence-linked findings in days, not months. The cost that actually matters is not the assessment fee — it is the avoidable custom-code carry cost the assessment uncovers, which on a reference estate reached $1.9M a year. You are buying a decision, so price it against the migration it de-risks, not by the hour.
fit-to-standardS/4HANAmigration costassessmentclean core6 minWhat is a Clean Core Score, and how do you measure one?
A Clean Core Score is a single 0–100 benchmark for how close an SAP estate is to a clean, standard core — the lower your reliance on custom code and modifications, the higher the score. It factors three things: the volume of custom objects, the age of your release, and how broadly customization spans your modules. It gives a CIO one honest number to size an ECC-to-S/4HANA migration and to track progress from the first scan through go-live.
clean coreS/4HANAfit-to-standardmetrics5 minRISE with SAP vs. S/4HANA on AWS: a CIO's decision framework
Both roads lead to S/4HANA; they end in different places. RISE with SAP is a managed subscription on SAP's terms — SAP operates your ERP and it lives in SAP's cloud. S/4HANA on AWS keeps you in control: you run the same S/4HANA in your own AWS account, choose your hyperscaler, and keep ownership of your data and your exit options. The real decision isn't infrastructure — every cloud hosts S/4 — it's what you own when the migration is done. Agent-led tooling can now cut migration effort on either path, so the tie-breaker is ownership, not hosting.
RISE with SAPSAP on AWSS/4HANAmigration strategy6 minCan an AI agent safely change SAP configuration?
Yes — as long as it never changes production directly. A safely-governed agent does not write to your live system; it drafts the change as a customizing transport and hands it to the change process you already run. The pattern that makes it safe: a human issues a single-use, time-boxed approval token, the agent applies the change in a development client through SAP's own BC Set mechanism, it re-reads the changed rows to verify field by field, and every attempt is logged immutably. Your CTS, QA gate, and change board still decide whether anything reaches production — the agent does the analyst and consultant labor, but your governance stays exactly where it is.
governanceconfigurationSAP securityclean coreagentic SAP6 minHow much custom code can you retire moving from ECC to S/4HANA?
More than most teams expect — often a third to a half of the custom estate — because a large share of custom ABAP either re-implements capability S/4HANA now delivers as standard or is simply dead and unused. On a reference estate (a live ECC system, not a specific customer's result), an evidence-weighted read found that 44% of custom objects were retirement or standardization candidates. The key is reading the business rule inside the code, not just its syntax: an MV45AFZZ exit that enforces a static credit limit is a credit-check policy that S/4HANA FSCM performs as standard, so you retire the exit instead of converting it. Every object you retire with a documented reason is testing you never run and license and maintenance cost you stop carrying.
custom codeS/4HANAclean corefit-to-standardmigration6 minWhat is SAP's agent-led transformation from Sapphire 2026?
At Sapphire 2026, SAP announced agent-led transformation tooling that automates system analysis, code remediation, configuration, and testing to reduce ERP migration effort by more than 35% (attributed to SAP News, Sapphire 2026), with general availability starting in Q3 2026 and delivered inside RISE with SAP. It introduces named assistants across the SAP Activate lifecycle — system analysis, data management, custom code, configuration, and test management. The practical meaning for a CIO is that the market now assumes AI agents do migration work; the open question is no longer whether to use them, but whether to get that capability only inside RISE, or on your own estate with your data and ownership intact.
agent-led transformationRISE with SAPSapphire 2026S/4HANAmigration5 minWhat happens to SAP ECC after 2027, and how urgent is the migration?
SAP ECC mainstream maintenance ends in 2027, with optional extended maintenance available to 2030 at a premium. After maintenance ends you stop receiving standard support, legal and regulatory updates, and patches, which makes moving to S/4HANA a matter of when, not if. But the deadline is a planning constraint, not a reason to panic-migrate: the correct response is to size your estate now so the business case can close, then sequence the move deliberately rather than rushing a program you have not scoped. The most expensive mistake is not missing 2027 — it is committing to a multi-year migration you cannot size.
SAP ECC2027 deadlineS/4HANAmigration strategy5 minWhat is a clean core strategy for S/4HANA, and how do you achieve one?
A clean core strategy keeps the standard S/4HANA system standard and moves the extensions you genuinely need to a governed, upgrade-safe layer instead of modifying the core. The payoff is cheaper, faster upgrades, lower risk, and quicker adoption of new SAP capability. You achieve it in three moves: measure how far your estate is from clean (a Clean Core Score), retire or standardize the large share of custom code that duplicates standard capability, and re-platform the extensions worth keeping onto released APIs and extension points — side-by-side on SAP BTP, in-app with released enhancements, or with key-user tools. Clean core does not mean zero customization; it means customization that survives the next upgrade.
clean coreS/4HANASAP BTPextensibilityfit-to-standard6 minWhat happens to MV45AFZZ and SD user exits in S/4HANA?
MV45AFZZ and the classic SD user exits still technically function in S/4HANA, but clean core says stop relying on them. The better move is to read what each exit does and map it to standard capability: a static credit-limit check maps to S/4HANA FSCM (credit management), output logic maps to output management and BRF+, and pricing logic maps to the condition technique or a released BAdI. In practice many exits turn out to re-implement capability S/4 now delivers as standard and can be retired outright, while the few that encode genuine differentiation move to released extension points. The decision is not really technical — it is a business-logic question about what each exit is for.
MV45AFZZSD user exitsS/4HANAclean corecustom code6 minHow does governed agentic configuration write-back into SAP work?
Governed agentic write-back means an AI agent produces a real SAP configuration change through SAP's own mechanisms, under human control, with a full audit trail — not a raw database write. The chain is: a human issues a single-use, time-boxed approval token; the agent applies the change as a BC Set into a customizing transport in a development client; it re-reads the changed rows to verify field by field; and every attempt is recorded immutably. It has been proven live — an order type (ZWE2) was created with all 18 control fields and recorded in transport S4HK903527. The agent never touches production; whether a transport is released is decided by your existing change process.
governed configurationagentic SAPcustomizing transportBC Setclean core6 min
The short version
What is SAP fit-to-standard, and why does it matter for an S/4HANA migration?
Fit-to-standard is the analysis of how much of your custom SAP estate can move to standard S/4HANA versus what must be retired or rebuilt. It sizes the whole migration — budget, timeline, testing, and risk — so the business case can close. It is the first, cheapest, and most decisive step of an ECC-to-S/4HANA program.
What is a clean core, and do I need one for S/4HANA?
A clean core keeps the standard S/4HANA system standard and moves real extensions to a governed, upgrade-safe layer. It is strongly incentivized because the cost and risk of every upgrade scale with how heavily you have modified the core. It does not mean zero customization — it means customization that survives the next upgrade.
Should I run S/4HANA under RISE with SAP or on AWS?
Both host the same S/4HANA, so the infrastructure comparison is a tie. The real decision is ownership: RISE is a managed subscription where SAP operates your ERP and holds your data, while S/4HANA on AWS keeps you in control of your estate, your cloud, and your exit options. Agent-led migration is now available on either path, so the tie-breaker is ownership.
Can an AI agent safely change SAP configuration?
Yes, if it never touches production directly. A safely-governed agent drafts the change as a customizing transport that your existing change process approves; it applies in a development client, verifies field by field, and audits every attempt. The agent proposes; your change board disposes.