SAP S/4HANA Readiness: Score Every Custom Object Before You Commit

Budget owners approving S/4HANA migrations in 2026 face a hard deadline. SAP's mainstream maintenance for ECC ends in 2027, and most organisations still don't know exactly what their custom code will cost to fix. A sampled assessment gives you a percentage and a rough estimate. That's not enough to sign off on a multi-million-dollar programme. The organisations that move forward with confidence are the ones that scored every custom object before they committed to a budget.

The real problem is scope. Most SAP landscapes carry thousands of custom objects built over a decade or more. When a consulting team samples 10 to 15 percent of that code and extrapolates, the error margin on effort and cost can run into hundreds of thousands of dollars. SAP Erp Implementation Services delivered at that level of precision leave budget owners exposed. So the question isn't whether to assess your environment. It's whether your assessment method can actually see all of it.

What S/4HANA Readiness Scoring Actually Means

S/4HANA readiness scoring is the process of evaluating every custom object in your SAP system against S/4HANA compatibility rules, then assigning each object a status: compliant, remediate, or retire. A complete scored inventory tells you which objects need rework, which can be dropped, and which will migrate cleanly. Without object-level scoring, effort estimates are guesses, and programme timelines are built on assumptions that rarely survive first contact with the actual code.

Traditional assessments rely on consultants reviewing a sample of your custom repository. They check a representative slice of programs, function modules, BAdI implementations, and interface objects, then multiply the findings across the full environment. The method is fast and relatively cheap. But it treats your custom code as statistically uniform, and it almost never is.

Why Sampling Fails at Scale

A typical ECC system built over 10 or more years accumulates objects from multiple implementation waves, different development teams, and varying coding standards. Some objects are clean and S/4HANA-ready. Others reference deprecated tables or obsolete APIs. Sampling cannot reliably distinguish the distribution.

When the consultant's sample happens to land on cleaner code, the estimate comes in low. When it lands on legacy objects, the estimate spikes. Neither outcome gives a finance committee what it needs to approve a budget. According to SAP's own migration guidance, organisations with more than 5,000 custom objects consistently report that sampled assessments underestimate remediation effort by 30 to 50 percent. That gap is the difference between a programme that lands on budget and one that needs an emergency change request six months in.

There is also a timing problem. Sampled assessments are typically delivered as a point-in-time report. By the time the programme kicks off, developers have added new objects, modified existing ones, or retired others. The baseline is already stale. A scored inventory that runs against the live system at the start of each migration wave is far more reliable than a report produced three months before mobilisation.

How AI-Agent Scoring Changes the Assessment

An AI-agent assessment reads the entire custom repository, not a sample. Agents scan every program, enhancement, interface, data dictionary object, and runtime statistic in the system. They do not touch production business data. The analysis runs against the code and configuration layer only, so there is no risk to live transactions or sensitive records.

The output is a scored inventory at the object level. Each object gets a readiness classification, a named list of blockers if any exist, an effort estimate, a cost estimate, and a dependency map showing which objects call or are called by others. That dependency map matters because remediating one object in isolation, without understanding its upstream and downstream relationships, often creates new problems during testing.

Three Outputs That Budget Owners Actually Need

A complete AI-agent environment assessment delivers three things that sampled assessments cannot:

1. Object-level effort and cost: Every custom object carries its own estimate, not a blended average. Finance teams can model scenarios by object group, business area, or migration wave.
2. A dependency map: The map shows which objects are tightly coupled and which can be migrated independently. This directly shapes the sequencing of your programme.
3. A recommended migration path: Based on the scored inventory, the assessment recommends brownfield, greenfield, or selective data transition. That recommendation is grounded in what the code actually shows, not a consultant's preference.

This is the level of detail that SAP Integration Solutions planning requires before contracts are signed. Interfaces between SAP and third-party systems are among the most common sources of migration delay. Knowing exactly which interface objects need rework, and in what order, lets the integration workstream run in parallel with core remediation rather than waiting for it to finish.

What the Scoring Engine Actually Reads

It helps to be specific about what an AI-agent scoring engine analyses. The scope typically includes:

• ABAP programs, includes, and function modules
• BAdI and user exit implementations
• Custom tables and data dictionary objects
• RFC and BAPI interface definitions
• Workflow templates and custom business rules
• Report variants and custom transaction codes
• Enhancement spots and implicit enhancements

Each object type carries different remediation complexity. A custom report that reads from a deprecated table is usually straightforward to fix. A tightly coupled interface that calls multiple deprecated APIs and feeds a downstream system is a different matter entirely. The scoring engine weights these differences. That weighting is what makes the cost estimate credible rather than theoretical.

Choosing Between Brownfield, Greenfield, and Selective Data Transition

The migration path decision is one of the most consequential choices in any S/4HANA programme. It affects timeline, cost, business disruption, and the degree to which you can simplify your processes during the move. A scored custom object inventory is the primary input to that decision, but it's not the only one. SAP's S/4HANA readiness check guidance provides a useful framework for identifying technical risks before selecting a migration path.

Brownfield migration, also called a system conversion, keeps your existing processes and configuration and converts the ECC system in place. It's faster and less disruptive, but it carries your technical debt forward. If your scored inventory shows a high proportion of objects that reference deprecated tables or obsolete APIs, a brownfield approach means remediating all of them before go-live. That can be expensive.

Greenfield migration starts fresh on a new S/4HANA system. You rebuild processes using standard SAP best practices, which reduces custom code volume significantly. The trade-off is time and change management. Greenfield programmes typically run 18 to 36 months for a mid-sized organisation. They also require a clear decision about which custom objects to rebuild and which to retire entirely.

When Selective Data Transition Makes Sense

Selective data transition, sometimes called shell conversion or mix-and-match migration, lets you move specific business units, legal entities, or process areas to S/4HANA while leaving others on ECC temporarily. It's the most complex approach technically, but it gives large organisations the ability to phase the migration without a big-bang cutover.

The scored inventory is particularly valuable here. When you know exactly which custom objects belong to which business area, you can define migration waves with confidence. Objects that serve a business unit going live in wave one get remediated first. Objects that serve a unit going live in wave three stay on the backlog. That kind of sequencing is impossible without object-level scoring.

Organisations exploring RISE with SAP S/4HANA should note that the selective data transition path is fully supported under that programme. The cloud-based delivery model does not force a single cutover. But it does require a clean scored inventory before SAP's own migration factory can begin its work.

The Role of SAP Business Technology Platform in Custom Object Remediation

One of the most significant changes in the move to S/4HANA is the shift in where custom logic lives. In ECC, custom code typically sits inside the core system as ABAP modifications or enhancements. In S/4HANA, SAP's recommended approach is to move custom logic to the side-by-side extension model using SAP Business Technology Platform consulting principles.

This matters for your scored inventory. When the scoring engine flags an object as "remediate", the remediation path isn't always a rewrite inside S/4HANA. Sometimes the right answer is to lift that logic out of the core and rebuild it as a BTP extension. That approach keeps the S/4HANA core clean, which is a prerequisite for SAP S/4HANA Cloud deployments and for staying current on quarterly updates without regression testing every custom object.

Identifying Extension Candidates Early

Not every custom object is a good candidate for BTP extension. The scoring engine can flag likely candidates based on a few criteria:

• Objects that implement business rules specific to one country or legal entity
• Objects that integrate with external systems via custom RFC or web service calls
• Objects that replicate functionality available in standard SAP but modified for local requirements
• Workflow enhancements that could be rebuilt as process automation on BTP

Identifying these candidates early, during the assessment phase rather than during build, saves significant rework. A team that discovers mid-programme that 200 custom objects should have been BTP extensions faces a scope change. A team that knew this from the scored inventory can plan for it from day one.

According to Gartner's 2025 ERP Market Guide, organisations that separate custom logic from the S/4HANA core before go-live reduce their annual upgrade effort by an average of 40 percent compared to those that carry modifications into the new system. That figure alone justifies the investment in a thorough pre-migration assessment.

Running the Assessment Without Disrupting Production

One concern that comes up consistently is the impact of a environment assessment on production performance. Running analysis tools against a live ECC system raises legitimate questions about system load, data access, and security.

A well-designed AI-agent assessment addresses these concerns directly. The scanning agents connect to the system using read-only access to the ABAP repository and system configuration. They do not execute custom programs, modify any objects, or access business data tables. The analysis is metadata-driven: it reads code structure, object attributes, and call hierarchies rather than transactional records.

Most assessments complete their initial scan within 24 to 72 hours for a system with 10,000 to 30,000 custom objects. The scan runs during off-peak hours to minimise any marginal load on the application server. Production users see no impact. The security team gets a read-only service account with defined scope, which is straightforward to audit and revoke after the assessment.

What to Prepare Before the Assessment Starts

Getting the most from a environment assessment requires some preparation on the client side. The following steps make the process faster and the output more useful:

1. Clean up your transport environment. Objects that were imported but never activated, or transports that were reversed, create noise in the repository. A quick housekeeping run before the assessment improves the accuracy of the object count.
2. Document your known interfaces. The scoring engine will find interface objects automatically, but knowing which interfaces are business-critical helps the team prioritise the dependency analysis.
3. Identify your development team leads. The scored inventory will raise questions about specific objects. Having the developers who built them available to review findings speeds up the remediation planning phase.
4. Align on your target architecture. If you know you're heading toward SAP HANA Cloud solutions or a cloud-first deployment, tell the assessment team upfront. The scoring criteria and remediation recommendations differ between on-premise and cloud targets.

These steps take a few days of internal effort. They pay back many times over when the scored inventory lands and the programme team can act on it immediately rather than spending weeks clarifying findings.

Frequently Asked Questions

Q. How long does a full custom object assessment take for a large ECC system?

A. For a system with 10,000 to 30,000 custom objects, the initial AI-agent scan typically completes within 24 to 72 hours. The full assessment report, including effort estimates, dependency maps, and migration path recommendations, is usually ready within two to three weeks of the scan completing.

Q. Does the assessment require downtime or affect production users?

A. No. The scanning agents use read-only access to the ABAP repository and system configuration. They do not execute programs or access business data, so production users see no impact. Most scans run during off-peak hours as a precaution.

Q. What is the difference between a brownfield and a greenfield S/4HANA migration?

A. Brownfield migration converts your existing ECC system in place, keeping current processes and configuration. Greenfield migration builds a new S/4HANA system from scratch using standard SAP best practices. The scored custom object inventory is the primary input to choosing between them, because it shows the true cost of carrying existing custom code forward.

Q. How does 2iSolutions use the scored inventory to plan a migration programme?

A. 2iSolutions uses the object-level scores, dependency maps, and effort estimates from the assessment to build a wave plan and a remediation backlog before the programme starts. This means the project team mobilises with a defined scope rather than discovering it during build, which significantly reduces mid-programme change requests.

Q. Can the assessment identify which custom objects should move to SAP Business Technology Platform instead of being rewritten in S/4HANA?

A. Yes. The scoring engine flags objects that implement standalone business rules, external integrations, or country-specific logic as BTP extension candidates. Identifying these early, during assessment rather than during build, prevents costly scope changes and keeps the S/4HANA core clean for ongoing updates.

What a Scored Inventory Means for Your Programme Budget

A complete scored inventory changes the nature of the conversation between the programme team and the finance committee. Instead of presenting a range with wide confidence intervals, the team can present object-level estimates that add up to a total with a defined basis. Contingency is still appropriate, but it's sized against known unknowns rather than unknown unknowns.

2iSolutions has seen this shift play out consistently across S/4HANA programmes of varying scale. Organisations that enter the build phase with a scored inventory spend less time in scope debates and more time remediating. Their change request volumes are lower. Their testing cycles are shorter because the dependency maps guided the remediation sequence. And their go-live dates hold more often because the original estimate was grounded in the full picture, not a sample.

The organisations that struggle are the ones that treated the assessment as a checkbox rather than a planning tool. They approved budgets based on sampled estimates, discovered the true scope during build, and spent months managing the fallout. A thorough pre-migration assessment is not an overhead cost. It's the foundation that every other workstream in the programme depends on.