Every SAP customer running ECC is being pushed toward the same deadline, and most are walking into it the same way: a multi-year program, a small army of consultants, and a backlog of custom ABAP nobody fully understands anymore. The migration to S/4HANA is sold as a technical upgrade. In practice it stalls because of everything that was bolted onto SAP over the last two decades — custom transactions, custom interfaces, custom approval flows, custom screens. The core was never the problem. The customization living inside it is.
There is a better-known answer to this than most teams act on. Kinetic Data is an enterprise workflow orchestration platform that acts as a modernization layer — software that sits on top of your existing systems of record, orchestrates work across them, and improves the experience for the people doing that work, without replacing the systems underneath. For SAP customers, that means the custom workflows, approvals, and portals that make migration painful don’t have to live inside SAP at all. They can live on a layer above it, connected through standard APIs, while S/4HANA stays standard. This is written for the IT, operations, and transformation leaders who own the migration and will be held accountable for the timeline.
This article names the six challenges that derail nearly every S/4HANA migration, explains what “clean core” actually means once you strip away the slogan, and lays out how to keep your custom logic off the core and on a modernization layer so the upgrade — and every upgrade after it — gets easier instead of harder.
The status quo: custom code and scope creep stalling S/4HANA
The honest starting point isn’t S/4HANA. It’s the ECC system you have now, and the thing that makes it valuable is also the thing making it immovable: years of accumulated customization. Custom programs encode how your business actually runs — the approval that routes differently for capital expenditure, the procurement step that checks an external system, the onboarding flow finance built because standard SAP didn’t fit. None of that documents itself. Much of it was written by people who have since retired or moved on.
When the migration project opens, that customization becomes scope. Every custom program has to be found, understood, judged compatible or not, and then refactored, rewritten, or retired. Each decision is a small negotiation between IT and a business owner who depends on the behavior. Multiply that across thousands of objects and the timeline stops being a function of SAP’s tooling and starts being a function of how much custom logic you embedded over twenty years. That is why these programs routinely run far longer and cost far more than the original estimate: the estimate priced the platform change, not the customization untangling underneath it.
The S/4HANA migration isn’t hard because of S/4HANA. It’s hard because of everything you built on top of the system you’re leaving.
The six challenges that derail migrations
These six problems show up on nearly every program. They look like separate workstreams. They are not — and the final section explains why that matters.
1. Custom ABAP remediation
Custom code has to be analyzed, refactored for S/4HANA compatibility, or rewritten outright. Many custom programs lean on deprecated APIs, obsolete data models, or SAP-specific patterns that have no clean S/4HANA equivalent. This is not a find-and-replace exercise. It is a re-engineering project hiding inside a migration project, and it is consistently the single largest consumer of time and budget.
2. Business process disruption
Custom transactions and workflow variants that employees rely on daily often don’t survive the move. Teams lose productivity in the gap between decommissioning the old process and standing up the new one. The business doesn’t pause while IT migrates, so every process that breaks during cutover becomes an operational fire, not just a project ticket.
3. Integration breakage
Custom RFCs, BAPIs, and middleware interfaces that wire SAP into the rest of the enterprise have to be re-architected. Every custom integration point is a potential failure during cutover, and the more connected your SAP environment is, the larger the blast radius. The systems SAP talks to — identity, finance, procurement, field tools — don’t care that you’re migrating.
4. The re-customization cycle
This is the one nobody wants to name. After spending years getting to a clean S/4HANA, business requirements immediately start pushing teams to customize the core again. The same pressure that made the upgrade painful is still there the day after go-live. If nothing changes about where customization is allowed to live, you have not solved the problem — you have rescheduled it. You don’t just need to migrate. You need to break the pattern.
5. User adoption friction
Standard S/4HANA delivers a standard experience, and standard rarely matches how a given team actually works. Users resist the change because the new interface feels like a downgrade from the custom screens they used for years. Technical success means nothing if the people who do the work won’t adopt what replaced their tools.
6. Talent scarcity
The developers who wrote the original customizations have largely retired or moved on. Organizations face a shrinking pool of deep ABAP expertise at the exact moment they need it most, which drives up cost and stretches timelines further. The institutional knowledge that would make remediation fast is often the first thing that left the building.
What all six have in common
Read them together and the root cause is obvious: customization lives inside SAP. Custom code, custom interfaces, custom workflows, custom screens — all embedded in the core, all standing directly in the upgrade path. Treat the six as six separate problems and you fight six separate fires forever. Treat them as one problem — where customization lives — and there is a single structural fix.
What clean core really means
“Clean core” has become a slogan, which is unfortunate, because the underlying engineering principle is correct. Clean core means keeping S/4HANA as close to standard as possible — resisting the urge to modify the core to fit every business-specific requirement, so that the system stays cleanly upgradeable.
The part that gets lost is the obvious follow-up question: if the customization can’t live in the core, where does it go? Your business requirements didn’t disappear because SAP published a guidance document. The capital-expenditure approval still has to route a certain way. The onboarding still has to touch four systems. The field team still needs a screen that fits their job. Clean core only works as a strategy if there is a deliberate home for all of that logic outside SAP — somewhere it can be built, changed, and governed without ever touching the core.
Without that home, “keep the core clean” is wishful thinking. The requirements come back, the pressure to customize returns, and you re-enter the cycle from challenge four. Clean core isn’t an act of restraint. It’s an architectural decision about where work belongs.
Keeping custom workflows off the core and on a modernization layer
This is where a modernization layer earns its keep. Instead of encoding business-specific behavior inside S/4HANA, you build it on a layer that sits above SAP and connects to it through standard, supported APIs. SAP handles what SAP is the system of record for. The orchestration layer handles the cross-system workflows, the approvals, and the user-facing experience that used to be jammed into custom transactions and ABAP.
That distinction is what makes Kinetic different from the obvious alternatives. A low-code platform invites you to rebuild logic in a new place and risks becoming a second system of record you now have to maintain. Custom apps are fast to start and brittle to live with. A modernization layer does neither — it does not try to replace SAP and it does not become the new place your data lives. It orchestrates work across the systems you already run and owns the experience on top of them. Concretely:
- Custom logic moves off the core. Approval routing, validation, and business rules that would have become custom ABAP get built on the layer instead, keeping S/4HANA standard and upgradeable.
- The core stays clean by design, not by discipline. Because the layer is the sanctioned home for customization, the pressure that drives the re-customization cycle has somewhere to go that isn’t the core.
- The experience is yours to shape. Teams get screens and self-service that fit how they actually work, which directly addresses the adoption friction that sinks technically successful migrations.
There are table-stakes capabilities underneath all of this — pre-built connectors, no-code configuration, self-service portals, forms. Treat them as the floor, not the pitch. Every workflow vendor claims them. The thing that matters for SAP is what those capabilities are pointed at: pulling customization out of the core and keeping it out.
Orchestrating across SAP and surrounding systems
SAP is rarely alone. The workflows that matter most reach across it — into identity and access, finance, procurement, ITSM, HR systems, and whatever else the business depends on. That cross-system reach is exactly where embedded SAP customization causes the most damage during migration (challenge three) and exactly where a workflow orchestration platform does its best work.
A modernization layer coordinates a process end to end across all of those systems while each remains its own source of truth. An onboarding workflow can provision access, create the SAP record, kick off the finance step, and notify the manager — as one orchestrated, auditable process — without that logic being hard-wired into any single system. When the underlying systems change, you adjust the orchestration, not a web of brittle point-to-point integrations buried in the core.
AI has a real role here, and a bounded one. Build with AI. Run with Kinetic. AI accelerates the design work — helping draft and shape workflows — and participates at runtime as discrete steps inside a workflow: classify an incoming request, extract data from a document, recommend a routing path, summarize a case for an approver. What AI does not do is execute the process. Execution stays deterministic — repeatable, governed, and auditable — which is non-negotiable when the workflow touches financial records and access rights. The rule is simple: AI advises. Humans decide. Workflows execute. Kinetic is not an AI platform and ships no models; it gives the models you already trust a well-scoped job inside a governed process.
Reducing risk and protecting time to value
The biggest risk in an S/4HANA migration is the cutover, and a modernization layer shrinks it. Because business-specific workflows live above SAP rather than inside it, they don’t have to be ripped out and rebuilt in lockstep with the core migration. The orchestration layer can connect to ECC today and to S/4HANA tomorrow, which lets you decouple the experience and workflow modernization from the platform migration instead of betting everything on a single high-stakes weekend.
That decoupling is what protects time to value. Teams can keep working through the transition. You can stand up improved workflows and portals before, during, or after the core move, on whatever sequence the business can absorb — incremental modernization rather than a multi-year freeze where nothing improves until everything changes at once.
Risk reduction is not only about timing. It is also about governance, and this is where Kinetic’s second differentiator matters for the buyers who are most exposed. Kinetic carries a government-grade security posture — IL5 authorization, CAC support, and more than twenty years in defense and intelligence environments. When a workflow provisions access or touches financial data, every action runs through a governed, auditable layer, so you can prove what happened, permission who can do it, and reverse it if needed. For regulated and public-sector organizations, that audit trail isn’t a nice-to-have. It’s the difference between a workflow you can deploy and one your auditors won’t let you run. The same posture that lets government and defense organizations trust Kinetic is what makes it safe to put in the path of your SAP processes.
Planning a clean-core migration path
You don’t need to solve all six challenges at once. You need to make one structural decision early and let it shape the rest of the program. A practical sequence:
- Inventory the customization, then sort it. Separate what’s genuinely core SAP behavior from what is business-specific workflow, approval, integration, or experience. The second category is the part that does not belong in S/4HANA.
- Pick a deliberate home for the second category. That home is the modernization layer. Decide it before remediation starts, so you’re moving custom logic out rather than refactoring it back into the core.
- Connect the layer to your current system first. Stand the orchestration layer up against ECC now, prove the cross-system workflows, and migrate the experience ahead of — or independently from — the platform.
- Migrate the core toward standard. With business-specific logic relocated, S/4HANA has far less reason to be customized, which directly attacks the remediation, disruption, and talent-scarcity challenges.
- Hold the line after go-live. Route new requirements to the layer by default. This is what finally breaks the re-customization cycle — the core stays clean because there is somewhere better for customization to go.
Done this way, the migration stops being a one-time event you survive and becomes a repeatable posture: a standard core that upgrades cleanly, and a modernization layer that absorbs change. That is the difference between buying yourself a few quiet years and never doing this the hard way again.
The custom-code problem that stalls S/4HANA migrations is, at bottom, a question of where customization lives. Move it off the core and onto a layer built to orchestrate work across SAP and everything around it, and the six challenges stop compounding. See how the Kinetic platform works, explore the cross-system workflows it orchestrates, or read the deeper architecture in The Customization Layer for SAP — including nine SAP processes that are better built outside the core. If a clean-core migration is on your roadmap, the most valuable decision you can make is the earliest one: decide where your customization is going to live before you start moving it.
Share this article