SAP Customisation in S/4HANA: What's Possible, What's Changed, and How to Do It Right

The 2027 ECC maintenance deadline is no longer an abstraction. For most large enterprises, it is now a hard countdown - and the most paralyzing question in the room is not whether to migrate, but what to do with twenty years of custom ABAP.

Here is the reality most migration conversations avoid: a significant portion of your legacy custom code is already dead. According to SAPinsider research, approximately 70% of organisations cite custom code adaptation as the single largest hurdle in S/4HANA migration - yet analysis of live ECC systems consistently shows that up to 60% of existing custom objects have had zero runtime activity in the past twelve months. You are not migrating a business-critical system. You are migrating a graveyard with a live core inside it.

The organisations that will finish migration cleanly - and stay clean - are not the ones that fought SAP's extensibility rules. They are the ones that used the deadline as leverage to make the architectural decisions they had been postponing for a decade: retire what is dead, refactor what is critical, and move what is differentiating to the extension layer.

This guide gives you the framework to do that.

The S/4HANA Customisation Paradigm Shift: What's Changed Since ECC

Bottom line: Core modification, the default posture in ECC for twenty years, is no longer viable in S/4HANA. The technical and commercial costs of maintaining it are now prohibitive.

In ECC, the architecture invited modification. Customers altered SAP standard tables, inserted custom logic directly into standard programs, and built Z-objects that sat inches from core SAP code. SAP tolerated this because the upgrade cadence was slow - every five to seven years - and the business logic was locked in on-premise with no competitive pressure to change it.

S/4HANA operates under different physics. SAP releases functional updates continuously. The Universal Journal restructures the financial data model at the foundation. Embedded analytics, SAP Fiori UX, and AI-powered processes like predictive MRP and working capital intelligence are built assuming a clean, unmodified data layer beneath them.

When you modify that layer, you break SAP's ability to ship enhancements to you. Every upgrade becomes a custom regression event. Every new SAP capability has to be tested against your modifications before it can go live. The cumulative cost of that technical drag - in both IT effort and delayed business value - is what SAP refers to as the Clean Core imperative.

The shift is not philosophical. It is structural. The extension layer now exists precisely so that your business logic has a sanctioned, supported home outside the core. The question is no longer whether to move there. It is how to do it without losing what makes your operations run.

The Clean Core Imperative: Why Standardisation Is Your Competitive Advantage

Bottom line: A clean S/4HANA core is not a constraint on your business. It is the precondition for every AI, analytics, and automation capability SAP is building for the next decade.

The phrase "clean core" generates resistance in most enterprise IT teams because it sounds like SAP asking you to give up competitive differentiation. That framing is backwards.

Standardisation of the core does not mean standardisation of your business processes. It means that the processes which SAP has already solved - financial close, procurement flows, materials management - run on SAP's validated, tested, continuously updated logic. Your IT and development capacity is freed to focus on the processes where your business actually differentiates: the custom pricing engine, the proprietary planning model, the integration with industry-specific third-party systems.

The True Cost of Core Modifications in 2026

The accounting on core modifications has changed. In ECC, the cost was diffuse - absorbed gradually across upgrade projects and support cycles. In S/4HANA, it is immediate and measurable.

Every modification to SAP standard code requires a modification key. SAP tracks these. More consequentially, every such modification must survive the next S/4HANA release update - tested, validated, and remediated if it conflicts with SAP's own changes. For organisations running S/4HANA Cloud (Public Edition), core modification is simply not permitted. For Private Cloud and on-premise deployments, it remains technically possible but commercially punishing.

Gartner projects that by 2027, 80% of SAP customers will be running side-by-side extensibility on SAP BTP rather than modifying the core directly. That is not a prediction about what organisations want. It is a prediction about what the economics of modification will force them to do.

The CIO calculus here is straightforward: the cost of maintaining core modifications compounds with every release cycle. The cost of moving business logic to the extension layer is a one-time re-architecture investment, after which your upgrade path is clear and your ability to consume SAP innovation is restored.

In-App vs. Side-by-Side: The New Extensibility Framework

Bottom line: SAP provides two sanctioned extensibility paths. Choosing between them is not a technical decision - it is a business logic classification exercise.

SAP's extensibility framework draws a clear line between two scenarios.

• In-app extensibility covers changes you make inside the S/4HANA system using SAP-provided, upgrade-stable tools: custom fields added through the Custom Fields and Logic app, business rules managed through the Business Rules Framework, custom business objects built with the RAP (RESTful ABAP Programming Model), and UI adaptations through SAP Fiori Elements. These are changes SAP explicitly supports and promises to carry forward through upgrades.
• Side-by-side extensibility covers business processes and integrations that need to live outside the S/4HANA core - on SAP Business Technology Platform (SAP BTP). These are built as independent applications or services that connect to S/4HANA through stable APIs, rather than embedding logic inside the core system.

The classification rule is simple: if SAP provides an upgrade-safe mechanism to do what you need inside the system, use it. If what you need cannot be achieved inside those boundaries without touching standard SAP code, move it to SAP BTP.

When to Use SAP BTP for Side-by-Side Development

Side-by-side on SAP BTP is the right architectural answer when your business logic is genuinely differentiating and complex enough that it warrants its own development, testing, and deployment lifecycle - separate from your SAP core upgrade cycle.

Concrete 2026 use cases where organisations are successfully executing side-by-side on SAP BTP include: custom credit scoring engines that integrate SAP Financial Supply Chain Management data with third-party risk models; trade compliance and sanctions screening workflows that need to update independently of SAP release schedules; industry-specific production optimisation logic in manufacturing that calls S/4HANA PP/DS data through OData APIs; and multi-system orchestration scenarios where S/4HANA is one node in a broader process that also touches Salesforce, Workday, or proprietary legacy platforms.

SAP BTP's Integration Suite, Extension Suite, and AI services - including SAP Build Process Automation - provide the platform primitives to build, host, and connect these extensions without creating core dependency.

Preserving Business Logic Without Touching the Core

The concern most CIOs raise at this point is legitimate: we have twenty years of business logic embedded in Z-programs and custom ABAP. Moving that logic to SAP BTP is not trivial.

The answer is that you do not move all of it. The custom code audit (covered in the next section) will reveal that a large portion of it does not need to move anywhere - it needs to be retired. Of what remains, in-app extensibility will absorb a significant share. Only the subset that is genuinely complex, differentiating, and architecturally independent warrants a side-by-side build on SAP BTP.

What organisations consistently underestimate is how much of their custom code was written to compensate for ECC limitations - batch jobs that replicate data SAP now provides natively, custom reports that duplicate standard S/4HANA analytics, workarounds for ECC's lack of embedded AI. In S/4HANA, that category of code is not just migratable - it is deletable.

Custom Code Adaptation: Audit, Refactor, or Retire?

Bottom line: Before you migrate a single line of custom ABAP, run a complete runtime usage analysis. The majority of your remediation budget should be spent retiring code, not rewriting it.

Custom code adaptation is where S/4HANA migrations stall. The volume of Z-objects in a mature ECC system - often ten thousand to fifty thousand objects in large enterprises - creates the impression that the migration is a multi-year, all-hands rewrite project. That impression is wrong, and it is expensive.

The audit-first approach changes the economics entirely. SAP provides the Custom Code Migration Worklist within SAP Landscape Transformation (SLT) and, more commonly, through SAP Readiness Check. These tools cross-reference your custom object inventory against SAP's S/4HANA simplification list and against the actual runtime usage log of your ECC system.

The output is a three-category classification:

• Retire: Objects with zero or negligible runtime usage. No business process depends on them. They can be decommissioned before migration begins, reducing scope and risk. This category typically accounts for between 40% and 60% of a large ECC landscape's custom object count.
• Adapt: Objects that are used but conflict with S/4HANA's data model changes - primarily programs that reference tables or function modules that have changed or been eliminated in S/4HANA. These require targeted remediation, not full rewrites. SAP's ABAP Test Cockpit (ATC) identifies exactly which lines of code trigger compatibility issues.
• Move: Objects that represent genuine business logic differentiation - pricing variants, planning heuristics, industry-specific processing logic - that need to survive migration and should be evaluated for re-architecture as side-by-side extensions on SAP BTP.

How AI-Assisted Code Remediation Is Changing the 2026 Migration

In 2023, the Adapt category was a largely manual exercise. ABAP developers reviewed ATC findings line by line, assessed impact, and wrote remediation code by hand. At scale, that was a labour-intensive bottleneck.

By 2026, AI-assisted code remediation has materially changed that equation. Forrester research projects that AI-assisted tooling reduces S/4HANA migration effort by an average of 30% - and that figure reflects tooling that is now production-grade, not experimental.

SAP itself has integrated generative AI into its Developer Experience toolchain. ABAP Cloud development in SAP BTP ABAP Environment now includes AI-assisted code generation via SAP Build Code. Third-party ABAP intelligence platforms can ingest ATC findings and generate remediation suggestions that developers review and approve rather than write from scratch.

ITChamps accelerates custom code remediation by up to 40% using automated SAP ALM frameworks - combining SAP Readiness Check, ATC-driven classification, and AI-augmented remediation workflows. For a large enterprise with ten thousand custom objects, the difference between a manual and an AI-assisted remediation track is measured in months, not marginal efficiency gains.

The point for CIO decision-making: AI-assisted remediation is not a future investment. It is a current capability that should be specified into your S/4HANA migration contract today.

Doing It Right: A CIO's Roadmap to S/4HANA Customisation

Bottom line: A successful customisation strategy is a three-phase programme - audit, architect, and deploy - executed in sequence, not in parallel.

Step 1: Comprehensive Code Audit

The programme begins before any S/4HANA architecture decisions are made. Run SAP Readiness Check against your live ECC system to generate the custom code impact report. Supplement it with the ABAP Test Cockpit for granular finding-level detail, and cross-reference against runtime usage logs from a trailing twelve-month window.

The output of this phase is a classified inventory of every custom object in your landscape, sorted into the Retire / Adapt / Move framework. This inventory drives every downstream decision - scope, timeline, resource allocation, and the SAP BTP architecture specification.

Do not shortcut this phase. Organisations that begin S/4HANA architecture planning without a completed code audit routinely discover mid-project that their technical scope was materially misjudged.

Step 2: SAP BTP Architecture Planning

Once you know what needs to move to the extension layer, design the target architecture before writing a line of code.

BTP architecture planning at this stage covers: which SAP BTP services are required (Integration Suite, Extension Suite, ABAP Environment, Build Apps, AI services); the API strategy - which S/4HANA OData or SOAP APIs will serve as the stable integration layer for side-by-side extensions; the identity and access model across the S/4HANA core and BTP tenant; and the data residency and compliance requirements for cloud-hosted extension services.

This is also the phase where organisations decide whether Public Cloud, Private Cloud Managed, or on-premise deployment of S/4HANA best fits their governance constraints - a decision that directly affects what extensibility options are technically available.

Step 3: Agile Extensibility Rollout

Extensibility development should not follow a traditional waterfall delivery model. The reason is practical: requirements for custom extensions often shift as business stakeholders engage with standard S/4HANA functionality during UAT. Processes they expected to customise are sometimes adequately served by SAP standard. Processes they assumed would be standard often require more extension logic than the audit indicated.

An agile delivery cadence - two to three week sprints, working functionality demonstrated to business owners at each sprint end - accommodates that discovery process without creating rework. It also provides the CIO with visible progress indicators rather than a binary pass/fail at project end.

ITChamps structures extensibility rollouts using SAP ALM's Change and Transport System integrated with agile sprint tracking, giving both IT leadership and business programme sponsors real-time visibility into which extensions are in development, which are complete, and which have outstanding business sign-off.

How ITChamps Accelerates Your S/4HANA Extensibility Strategy

ITChamps is an SAP Gold Partner with delivery experience across S/4HANA migration, Application Management, and SAP BTP advisory - operating across India, the UK, and global enterprise accounts.

Our S/4HANA Custom Code Remediation practice combines the SAP toolchain - Readiness Check, ATC, SLT - with automated ALM frameworks and AI-assisted ABAP remediation that reduces remediation effort by up to 40% against manual-only approaches.

For CIOs navigating the 2027 deadline, our engagement model is structured around a phased entry point: the S/4HANA Readiness Assessment, which delivers a classified custom code inventory, a Clean Core gap analysis, and a SAP BTP architecture blueprint in a fixed-scope, fixed-timeline engagement - giving leadership the information needed to make programme funding and resourcing decisions before committing to full migration delivery.

Our SAP BTP advisory practice covers the full side-by-side extensibility stack: Integration Suite implementation, Extension Suite development, BTP ABAP Environment provisioning, and AI service integration. We work with your existing ABAP development teams to transfer knowledge alongside delivery - not just build and hand over.

If your organisation is approaching the 2027 deadline without a validated custom code strategy, the time to close that gap is now. Every quarter spent without a classified code inventory is a quarter of migration runway consumed by uncertainty.

Frequently Asked Questions

1. What is the difference between in-app and side-by-side extensibility in S/4HANA?

In-app extensibility refers to changes made inside the S/4HANA system using SAP-provided, upgrade-safe tools - such as custom fields via the Custom Fields and Logic app, business rules via BRF+, and custom business objects built with the RAP model. Side-by-side extensibility refers to business logic and integrations built as independent applications on SAP Business Technology Platform (SAP BTP), connected to S/4HANA through stable APIs. The key distinction is upgrade safety: in-app extensions are carried forward by SAP; side-by-side extensions are managed independently of the S/4HANA release cycle.

2. How much of our legacy custom ABAP code will actually need to be migrated to S/4HANA?

Runtime usage analysis of live ECC systems consistently shows that between 40% and 60% of custom objects have had no production usage in the preceding twelve months. These objects can be retired before migration begins, materially reducing scope. Of the remaining active custom code, a portion will require targeted remediation for S/4HANA compatibility, and a smaller subset - genuinely differentiating business logic - warrants re-architecture as side-by-side extensions on SAP BTP. The precise split varies by organisation and requires a formal custom code audit using SAP Readiness Check and ABAP Test Cockpit.

3. Is it possible to modify SAP standard code in S/4HANA?

Technically, core modification is possible in S/4HANA Private Cloud and on-premise deployments using SAP modification keys. However, SAP strongly discourages it, and it is entirely prohibited in S/4HANA Cloud Public Edition. Each modification must survive every subsequent S/4HANA release update, creating compounding regression testing and remediation overhead. The Clean Core strategy - using in-app extensibility tools and SAP BTP for side-by-side extensions - is SAP's supported and recommended approach, and the one that preserves access to SAP's continuous functional enhancements and AI capabilities.

4. What role does SAP BTP play in S/4HANA extensibility?

SAP Business Technology Platform (SAP BTP) is SAP's designated platform for side-by-side extensibility - business logic and integrations that need to exist outside the S/4HANA core. SAP BTP provides Integration Suite for connecting S/4HANA to third-party systems, Extension Suite for building custom applications, BTP ABAP Environment for cloud-native ABAP development, and AI and automation services through SAP Build. By 2027, Gartner projects that 80% of SAP customers will use SAP BTP for extensibility rather than core modification.

5. How does AI-assisted code remediation work in the context of S/4HANA migration?

AI-assisted code remediation uses automated tooling to analyse ABAP Test Cockpit (ATC) findings - the compatibility issues flagged in legacy custom code - and generate remediation suggestions for developers to review and approve, rather than requiring developers to write corrected code from scratch. This approach reduces migration effort significantly; Forrester research projects an average reduction of 30% in migration effort through AI-assisted tooling. ITChamps combines SAP Readiness Check, ATC-driven classification, and AI-augmented remediation workflows to accelerate custom code remediation by up to 40% compared to manual-only approaches.