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
What happens to your SAP batch jobs in an S/4HANA migration?
Treat batch jobs as an inventory-and-validate problem, not a copy-and-hope problem. Start by extracting every scheduled and recently run job from the job tables (TBTCO for headers, TBTCP for steps, or transaction SM37), then check each step program against the simplification items and custom code findings for S/4HANA, because a job that references an obsolete transaction or report will fail silently on the first night. Group jobs by business process and dependency chain, retire the ones nobody consumes, and re-test the survivors in sequence in a non-production system. Finally, plan cutover so that jobs copied into test or sandbox systems are not released against live interfaces. Most batch-job surprises come from sequence and ownership, not from the code itself.
batch jobsS/4HANA migrationcutovercustom codeSAP basis5 minHow should you migrate data to S/4HANA with the SAP Migration Cockpit?
The SAP S/4HANA Migration Cockpit is SAP's standard tool for loading business data into a new S/4HANA system using predefined migration objects such as material, business partner, open purchase orders and balances. You choose a transfer approach (loading from files or staging tables, or pulling directly from a source SAP system, depending on your release), map and convert the data, simulate, and then migrate. It is usually enough for greenfield and selective-transition loads of standard objects, and it is not a substitute for data cleansing or for reconciliation. The tool moves what you give it; whether the result is correct is decided by your data-quality work before the load and your reconciliation after it.
data migrationMigration CockpitS/4HANAgreenfieldcutover6 minWhat should an SAP change board review before approving an AI-drafted transport?
An SAP change board should review an AI-drafted customizing transport exactly as it would one written by a consultant, plus a few checks specific to machine authorship. Confirm the business reason and the evidence behind it, read the transport contents object by object, check that the verified read-back matches the intended values, confirm it was applied in a development client only, and confirm the approval and audit record show who authorized the draft. Then decide on risk, not on novelty: a small, well-evidenced customizing change with a clean read-back deserves the same path through QA as any other. The agent proposes; your existing change process remains the control that decides whether anything moves toward production.
change managementcustomizing transportgoverned configurationagentic SAPsegregation of duties5 minHow do you write acceptance criteria for an S/4HANA migration before you migrate?
Write acceptance criteria as business outcomes you can check against your own ECC system before anything moves: which processes must still work, what documents and balances must reconcile, and how fast the critical transactions must run. Capture a baseline from ECC first, such as order-to-cash cycle times, open-item totals, and a sample of real documents with their expected results. Then keep a portion of those cases hidden from the team doing the conversion, so passing is not just the team confirming its own work. A migration is accepted when the baseline outcomes reproduce in S/4HANA within agreed tolerances and the business owner of each process signs off, not when the cutover rehearsal merely finishes without errors.
acceptance criteriaS/4HANA migrationvalidationspec-driventesting5 minIn-app or side-by-side: where should an S/4HANA extension live?
Use in-app (on-stack) extensibility when the change is small, tightly bound to one S/4HANA business object, and needs to run inside the same transaction, such as a custom field, a validation, or a released BAdI. Use side-by-side extensions on SAP BTP when the logic is larger, spans several systems, has its own lifecycle or user interface, or should not be able to slow down the ERP core. The deciding questions are transaction coupling, data gravity, and who owns the lifecycle. In both cases the clean core rule is the same: build only on released, upgrade-safe interfaces, and retire the custom code that merely duplicates standard before choosing where the rest should live.
clean coreextensibilitySAP BTPS/4HANAABAP Cloud5 minHow do you decide whether to retire, re-implement, or keep custom ABAP in an ECC to S/4HANA migration?
Decide object by object using three questions in order: is it used, does standard S/4HANA now do the same job, and if neither, can it be rebuilt on a released extension point. Unused code is retired. Code whose business rule is now covered by standard capability is retired after the rule is confirmed and mapped to configuration. Only what remains, the logic that genuinely differentiates the business, is re-implemented on released APIs, in-app extensibility, or side-by-side on SAP BTP, and a small remainder is kept as-is with a documented reason. Running the questions in that order matters, because most of the cost savings come from the first two answers, before anyone writes a line of new code.
custom codeclean coreABAPS/4HANA migrationfit-to-standard6 minWhat happens to MKPF and MSEG when you move inventory to S/4HANA (MATDOC)?
In S/4HANA, material documents are stored in a single table, MATDOC, which replaces the ECC header and item pair MKPF and MSEG. Many persisted stock aggregates and history tables from ECC, such as the period-end stock tables, are no longer maintained as stored data and are instead derived from MATDOC at read time. SAP keeps compatibility views under the old names so many standard and custom reads continue to work. Custom code that writes directly to the old tables, or that depends on the removed aggregates, is a conversion issue, and reads that still work can behave and perform differently against a view. The practical migration task is to find the custom inventory code that touches these structures, check it against the simplification items, and regression test the goods movement processes that actually changed.
MATDOCinventory managementS/4HANA simplificationcustom codeECC to S/4HANA5 minWhat does the Universal Journal (ACDOCA) change for finance in an S/4HANA migration?
The Universal Journal, stored in table ACDOCA, is the single line-item table in S/4HANA that holds financial accounting, controlling, asset accounting, material ledger, and account-based profitability postings together. In ECC those lived in separate tables (BSEG, COEP, ANEP, the material ledger tables, and CO-PA line items) and had to be reconciled between FI and CO. In S/4HANA they are one record, so the reconciliation step disappears and many aggregate tables become views. The migration impact is not the posting itself but everything built around the old tables: custom reports that read them, custom code that writes to them, reconciliation routines, and period-end processes. A brownfield conversion must therefore reconcile FI, CO, and asset totals before migration and then re-test finance code and reports afterward.
Universal JournalACDOCAS/4HANA financeECC to S/4HANAbrownfield migration5 minHow do you handle SAP authorizations and roles in an S/4HANA migration?
Treat authorizations as a redesign, not a copy. Most of your ECC roles will still technically work after conversion, but S/4HANA changes what users need: the Fiori launchpad replaces transaction menus, new apps carry their own authorization defaults, and simplification items such as Business Partner and FSCM introduce new authorization objects. The reliable approach is to derive the new role set from usage data rather than from the old role tree: find the transactions and apps people actually run, map them to Fiori catalogs and groups, regenerate authorization proposals through SU24 and SU25, and retire roles that grant access to processes you are no longer running. Segregation-of-duties testing then confirms the result before cutover.
SAP authorizationsS/4HANAFiorisegregation of dutiesmigration5 minWhat happens to SAP output management (NAST) in S/4HANA?
S/4HANA introduces a new output management framework, usually called output control, in which output determination is decided by BRF+ decision tables rather than by NAST condition records, and output is rendered from form templates with a data provider rather than by a print program (SAP Note 2228611). In an on-premise or private-cloud S/4HANA system the classic NAST-based mechanism is still available for compatibility, and each application object type such as billing document, sales document, or purchase order can be switched between the two, so a brownfield conversion does not force the change on day one. It does force a decision, because the two frameworks have different configuration, different form technologies, different logs, and different extension points, and the custom print programs, VOFM output routines, and NACE condition records built up over an ECC lifetime have no automatic equivalent in output control. Treat output as a scoped workstream with an inventory of live output types, a per-application switch decision, and a form-by-form retire, rebuild, or keep call.
output managementNASTBRF+ECC to S/4HANAorder-to-cash6 minWhat happens to SAP SD rebate processing in S/4HANA?
In S/4HANA, classic SD rebate processing is replaced by Settlement Management, where a rebate is modelled as a condition contract rather than a rebate agreement (SAP Note 2226380, simplification item for SD rebates). After a brownfield conversion you can no longer create new rebate agreements in VBO1; agreements that already exist can be processed until their validity ends and must then be closed with a final settlement, while every new rebate is created as a condition contract in WCOCO and settled through settlement documents instead of rebate credit memo requests. The rebate index (VBOX) and its retroactive rebuild disappear, because business volume is selected from posted billing documents when settlement runs. The same framework handles supplier rebates on the purchasing side, so a migration is also a chance to unify customer and vendor incentive programs. Treat this as a process redesign owned by sales and finance, not a data migration task, because accrual policy, settlement cadence, and the custom pricing logic built around condition types BO01 to BO06 all have to be decided again.
SD rebatesSettlement Managementcondition contractsECC to S/4HANAorder-to-cash6 minWhat is the SAP Simplification Item Check, and why does it stop an S/4HANA conversion?
The Simplification Item Check (SI-Check) is SAP's mandatory pre-conversion check for a brownfield move from ECC to S/4HANA. It runs in the source ECC system through report /SDF/RC_START_CHECK (delivered with SAP Notes 2399707 and 2502552 and the ST-PI add-on), and it does two things: a relevance check that determines which of the several hundred S/4HANA simplification items apply to your system based on the functions and data actually in use, and a consistency check that tests whether the data preconditions for each relevant item are met. The consistency results carry a severity, and every finding rated as an error must be resolved or formally exempted before the Software Update Manager (SUM) will proceed, because SUM re-runs the same checks during the conversion and hard-stops on unresolved errors. The most common blockers are unconverted customers and vendors (the Business Partner / CVI precondition), finance reconciliation differences that would corrupt the universal journal migration, classic asset accounting, and add-ons or business functions with no S/4HANA equivalent. Treat the SI-Check as a live inventory of the process changes your migration must absorb, not as a technical gate to clear the week before cutover.
Simplification Item Checksystem conversionSUMECC to S/4HANAbrownfield6 minHow do you find unused custom code in SAP ECC before an S/4HANA migration?
You find unused custom code in SAP ECC by combining three kinds of evidence from the live system rather than asking developers what they remember: runtime usage data from SAP's ABAP Call Monitor (SCMON, aggregated in SUSG) or the older Usage and Procedure Logging (UPL), which record which Z-programs, function modules, methods, and enhancement implementations actually executed over a representative period; a static where-used analysis that shows which objects are referenced by anything that itself runs; and the business rule each object implements, read from its source, so that a rarely executed object can still be judged on whether the rule it enforces is one the business needs in S/4HANA. Objects with no runtime hits across a full business cycle, no active callers, and a rule that S/4HANA delivers as standard are retirement candidates; objects with hits belong in the fit-to-standard workshop with their execution frequency attached. On a reference estate, a live ECC system used to validate this method rather than a specific customer's result, roughly 44% of 356 inventoried objects were assessed as retirable through this chain; a customer's numbers come from their own system.
custom codeSCMONfit-to-standardECC to S/4HANAclean core6 minHow do you run a fit-to-standard workshop for an S/4HANA migration?
A fit-to-standard workshop is a process-owner session in which the business walks through how S/4HANA performs a process as delivered and decides, per step, whether to adopt the standard or record a justified gap. It works when three things are in the room before anyone talks: an inventory of what the current ECC system actually does (custom objects, exits, enhancements, and configuration, drawn from the live system rather than from memory), the standard S/4HANA process shown end to end in a working sandbox, and a decision rule that puts the burden of proof on keeping a customization rather than on removing it. Run one workshop per end-to-end process (order-to-cash, procure-to-pay, record-to-report), keep it to the people who own the outcome, and leave with a written disposition for every customization touched: adopt standard, retire, re-implement as a clean-core extension, or defer with a named owner. The workshop is not a requirements-gathering exercise; it is a decision meeting, and it fails when it is run as either a demo or a wish list.
fit-to-standardworkshopECC to S/4HANAclean coreSAP Activate6 minWhat happens to SAP credit management (FI-AR-CR) in an S/4HANA migration?
Classic SAP credit management (FI-AR-CR, the FD32-style credit master with credit control areas and risk categories) is not available in S/4HANA; it is a mandatory simplification item and is replaced by SAP Credit Management in FSCM (FIN-FSCM-CR). Every ECC to S/4HANA migration that uses credit checks in sales must therefore migrate its credit configuration, credit master data, and open exposure into the FSCM model, where credit control areas become credit segments, risk categories become risk classes, and check logic runs through formulas and rules rather than fixed limits alone. The technical migration is a well-defined set of IMG steps; the real work is deciding the credit policy that the new model should enforce and retiring the custom code that ECC-era teams wrote around the old one. Treat it as a fit-to-standard decision owned by the credit and order-management process owners, started early, because it sits directly on the order-to-cash critical path.
credit managementFSCMorder-to-cashECC to S/4HANAsimplification items6 minWhat is the business partner conversion (CVI) in an ECC to S/4HANA migration?
The business partner conversion is the mandatory step in an ECC to S/4HANA migration that consolidates every customer and vendor master record into a single Business Partner object, using SAP's Customer/Vendor Integration (CVI) framework. In S/4HANA the Business Partner is the leading master-data object: the classic tables still exist, but they are populated through BP synchronization, and the classic create and change transactions redirect to the BP transaction. For a brownfield conversion, CVI must be activated, configured, and fully synchronized in the ECC production system before the technical conversion will proceed — the pre-checks stop the upgrade if any customer or vendor lacks a linked Business Partner. It is routinely the longest-lead preparation task in the program, because the real work is not the synchronization run but the master-data cleansing the synchronization exposes: inconsistent addresses, invalid tax numbers, duplicate contact persons, and number-range collisions between customer and vendor ranges. Start it in the first weeks, own it on the customer side, and treat every synchronization error as a data defect to fix at source rather than a technical fault to suppress.
business partnerCVImaster dataECC to S/4HANAbrownfield conversion6 minHow 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.