The upgrade problem is the custom code
SAP ends mainstream maintenance for ECC at the end of 2027, and most ECC customers are planning a move to S/4HANA. Moving the standard system is a well-understood project. The hard part is everything that was built on top of it.
Over twenty or thirty years, most ECC shops have added custom transactions, reports, workflows and interfaces. When the move to S/4HANA starts, each of those becomes work: code to analyze, refactor, retest or rebuild.
SAP’s own guidance is to keep S/4HANA as close to standard as possible, which it calls a “clean core.” For an organization that depends on its custom processes, that leaves one hard question: where do those processes go?
Six things that stall S/4HANA migrations
Custom ABAP remediation
Custom programs have to be analyzed, refactored for S/4HANA or rewritten. Many call deprecated APIs or rely on data models that have no S/4HANA equivalent.
Process disruption
Custom transactions that people use every day often don’t survive the move. Teams lose time in the gap between switching off the old process and standing up the new one.
Broken integrations
Custom RFCs, BAPIs and middleware interfaces that connect SAP to other systems need to be redesigned. Each one is a place where cutover can fail.
The re-customization cycle
Once S/4HANA is live and clean, new business requirements arrive and teams start customizing again. That restarts the cycle that made the upgrade painful.
User adoption
Standard Fiori apps rarely match how a given team works. People who have used tailored screens for years tend to see the new interface as a step backward.
Scarce ABAP skills
The developers who wrote the original customizations have often retired or moved on, and experienced ABAP developers are hard to hire just when the migration needs them.
SAP is right that S/4HANA works best close to standard. The business still needs the processes that led it to customize ECC. So the decision is less about whether to customize and more about where the customization lives.
Two ways to keep SAP standard
The rule is short. If SAP does something well out of the box, let SAP do it. Business-specific processes, workflows that span several systems, and screens built around how a team works go in Kinetic.
Approach 1: SAP for the core, Kinetic for the rest
Some processes are pure SAP: GL postings, MRP runs, standard procurement. They stay in SAP. The processes shaped by your industry, your compliance rules or your org structure are the ones that become technical debt when they’re written in ABAP. Build those in Kinetic and SAP stays standard.
| Keep in SAP | Build in Kinetic |
|---|---|
| Financial postings, materials management, production planning, standard procurement and warehouse management: anywhere standard SAP covers the need without modification. | Custom approvals, organization-specific workflows, compliance checklists, onboarding that touches several systems, vendor portals and exception handling: anything that would otherwise need custom ABAP or a Z-transaction. |
Approach 2: one front end across several SAP systems
Many organizations run more than one SAP instance, split by business unit, region or acquisition. Kinetic can be the front end people use, with workflows that read from and write to each of those systems. Users see one set of screens, and Kinetic decides which system each step goes to.
Users
Employees, managers, approvers and external partners
Kinetic
Screens, workflows, business rules and approvals
Integration
APIs, OData, RFCs, IDocs, MuleSoft or other middleware
ERP systems
- S/4HANA instance A
- S/4HANA instance B
- ECC (legacy)
This matters most during the migration itself. ECC and S/4HANA can run in parallel behind Kinetic, and users keep working in the same Kinetic screens while the back end moves from one system to the other. There is no single cutover weekend for users, and no retraining when the switch happens.
The two approaches work together. Use the first during the migration: as you find custom processes, rebuild them in Kinetic instead of re-customizing S/4HANA. Use the second to run both systems side by side while the back end moves underneath.
Nine processes that belong outside SAP
These are processes organizations commonly build inside SAP with custom ABAP, and they are the source of much of the technical debt that makes upgrades hard. Each one fits Kinetic well: it’s quicker to change there, and it doesn’t stand in the way of the next SAP upgrade.
Approvals
Procurement approvals
Routing by cost center, amount threshold and org hierarchy, configured as a Kinetic workflow that writes the approved PO back through a standard BAPI.
Self-service
Employee self-service
Leave requests, address changes, benefits enrollment and pay stubs, in your own branded screens, backed by standard SAP HCM APIs.
Cross-system
New hire onboarding
One workflow across SAP HCM, Active Directory, facilities, IT equipment and training. Most of those systems sit outside SAP’s reach.
Exceptions
Invoice and payment exceptions
Three-way match failures, blocked invoices and payment run exceptions. Custom ABAP exception handlers are some of the hardest code to migrate.
External access
Vendor and partner portals
PO acknowledgment, ASN submission and invoice upload without giving third parties SAP access. Kinetic serves the portal; SAP supplies the data over OData.
Cross-system
Capital project requests
Business case, approvals across departments, a budget check against SAP CO and asset creation in SAP AM, as one process instead of custom PS/IM workflows.
Compliance
Audit and compliance checklists
SOX controls, segregation-of-duties reviews and periodic access certifications. The forms and approval chains change often, which is easy in Kinetic and slow in ABAP.
Field work
Plant maintenance
Mobile work orders, inspection checklists, parts requests and photo capture, with results written back to SAP PM through standard interfaces.
Data collection
Custom data entry and reports
Replace Z-transactions and custom ALV reports with forms that validate against SAP master data over OData, with no new ABAP.
A useful test: if a process touches SAP data but exists because the standard transaction didn’t fit how your organization works, it belongs in Kinetic. The data stays in SAP. The screens, rules and workflow move out, and SAP goes back to being the system of record.
Before and after
| Area | Customized SAP today | SAP with Kinetic |
|---|---|---|
| Custom code | Custom ABAP embedded in the SAP core, which makes every upgrade harder | Business-specific logic lives in Kinetic workflows instead of new ABAP |
| Upgrades | Multi-year projects with heavy regression testing | Fewer custom objects to retest; Kinetic workflows call SAP through standard interfaces |
| Process changes | Change requests wait in the ABAP development queue | Process owners and analysts change workflows in Kinetic’s low-code builder |
| User experience | Standard Fiori or custom SAP GUI screens | Your own branded screens, designed around how each team works |
| Skills | Specialized ABAP developers, who are hard to hire | A wider team can maintain processes through configuration |
| Other systems | Custom middleware and point-to-point integrations | Kinetic runs the workflow across systems; SAP is one of several endpoints |
| Risk | Each new customization adds to the next migration | SAP stays close to standard as requirements change |
Where to start
SAP’s clean core is the right goal. The practical way to reach it is to decide, process by process, what stays in SAP and what moves out. Start with the inventory of custom objects your migration team is already building: mark the ones that exist only because a standard transaction didn’t fit, and rebuild those in Kinetic first. SAP stays standard, and the processes your organization depends on keep working.