Early in my career, I was asked to dissect a user exit that transformed deliveries into billing documents. The exit had clearly been enhanced multiple times over the years — but the documentation was ancient, incomplete, and mostly useless. At the time, my ABAP skills were still developing, but even I could spot something off. The code was trying to reflect business processes that didn’t seem to exist anymore. When I asked around, it turned out I had stumbled upon something every SAP consultant eventually meets: zombie code. Business logic that no one uses, but no one dares to remove. It’s too risky. It might be wired into something else. So it stays. Undead. Untouched. Slowly poisoning maintainability. That user exit taught me more about legacy risk than any training ever could.

Little did I know, that shambling chunk of zombie code was not the only monster lurking in the halls of our ERP. In fact, it was just one inhabitant of what I now fondly call my haunted SAP castle. (Don’t worry, I brought a flashlight and some sage.) Perhaps a better mascot for these unwieldy systems is Dr. Frankenstein’s famous creation — initially ingenious, now terrifying. Before we venture deeper into this spooky analogy, let’s set our compass with a few key lessons:

Key Takeaways

1. Not all custom code ages gracefully.
2. Clean Core is a cultural shift, not a technical one.
3. S/4HANA is a rare opportunity to rebuild right.
4. Testing Clean Core now can prevent pain later.
5. Frankenstein systems are a choice — not a fate.

Now, with these in mind, follow me into the depths. Cue thunder and lightning.

Frankenstein’s Monster in New Delhi (and in Your Data Center)

There is a bustling electronics market in Nehru Place, New Delhi, where “Refurbished Laptop” and “Laptop Repair” signs herald the creation of Frankenstein machines from spare parts.

These improvised laptops are cobbled together from scavenged motherboards, mismatched screens, and whatever batteries still hold a charge. It’s a daily ritual of resurrection: technicians stitching parts from multiple brands into one functional device. Initially, it’s a clever, resourceful solution that offers a lifeline to those who can’t afford the latest model. A student or a gig worker gets a “new” computer for a fraction of the price — a triumph of ingenuity over budget constraints.

But as any horror fan knows, every Frankenstein’s monster has a weakness. These hybrid laptops, for all their thrift and creativity, become fragile creatures. They aren’t backed by any manufacturer’s warranty or updates. Try to upgrade the operating system or replace a component, and you may find that the parts don’t quite fit together anymore. One loose wire and the whole thing might collapse in a puff of blue smoke. Sound familiar? Look over at that heavily customized SAP ERP system humming (ominously) in your data center. It’s not so different.

Over decades, many SAP systems have been stitched together from spare parts of code. Custom user exits, Z-programs, customer modifications, bespoke add-ons – you name it. In their youth, these custom enhancements were often brilliant, necessary workarounds. We built them because standard functionality didn’t exist or didn’t quite meet the business need at the time. Like the Frankenstein laptops, our SAP mods were the product of ingenuity and necessity. And for a while, they worked. Sometimes they still do… mostly. But years later, what do we have? A patchwork of ABAP limbs and bolts that’s technically alive, yet leaves everyone a bit nervous to touch it.

Initially Clever, Eventually Scary to Upgrade

Here’s the chilling part: the more patched-together your SAP system is, the more it starts to exhibit monster-like behavior. New integration project? The creature groans. Applying a support pack? It’s alive!!! – but your finance interface suddenly breaks. Upgrading to a shiny new version? Now you’re playing mad scientist, testing which custom appendages can safely be transplanted. Companies with highly bespoke SAP systems often find that an upgrade turns into a monster hunt, because moving years of custom code forward is a mammoth task often requiring significant rewrites. No wonder many CIOs have nightmares about the big S/4HANA migration – they fear waking the dormant monsters in the dark basement of their ERP.

And just like those Delhi “Frankenstein” machines assembled from e-waste, our custom ERP solutions usually lack official support. Sure, SAP will help you with standard software issues, but if your home-brewed code is causing the trouble? That’s on you. When something breaks, your team scrambles to find the one person who might recall how that custom pricing routine was rigged up circa 2004. (If that person hasn’t already retired to a beach far, far away.) In short: the monster you created is yours to deal with. And each year it gets a little harder to find the spare parts (or people) to fix it.

Born from Necessity, Now Obsolete (The Evolution of Enhancements)

Many of our ERP “creatures” were born out of necessity. We wrote custom code because we had to. Two decades ago, SAP might not have had native support for a particular local tax, or a specific industry process, or that one crazy sales discount logic your business dreamed up. So IT got creative. We used user exits and enhancements as the duct tape and magic thread to weave new functionality into the standard SAP cloth. It wasn’t always pretty, but it kept the business running. In those days, we proudly showed off our monsters – they were proof of our resourcefulness.

However, time changes everything. SAP kept evolving its standard offerings. Year by year, release by release, the SAP core grew richer. Functions that were once gaps to be filled by custom code often gained standard solutions. The irony? By the time SAP delivers a standard feature that’s close to what you built, your business has already spent years relying on your custom version. And switching to SAP’s new standard isn’t as simple as flipping a switch. Why? Because it’s close – but not identical.

Imagine you custom-built a module for, say, advanced available-to-promise logic back in 2005. It’s tangled deeply into your sales process. Fast forward, SAP introduces a standard advanced ATP in a later release that almost does what your custom code does… but not exactly. Now you have two Frankensteins: one home-grown, one offered by Dr. SAPstein. Convincing the business to abandon the familiar custom solution for the new standard one is an uphill battle. After all, your version was tailored exactly to their whims. The standard might require gasp process changes or missing a beloved quirk. So the custom code remains, even though an officially supported (and likely more future-proof) option beckons.

This scenario has played out countless times. Customizations that made perfect sense in 1999 are outright liabilities in 2025, yet they persist. Why? It’s not because IT loves maintaining old code for nostalgia’s sake. It’s because of the next topic, a psychological trap as old as horror tales themselves.

The Sunk Cost Curse (and Other Reasons We Cling to the Undead)

Ever stayed in a bad movie till the end because you’d already paid for the ticket? Businesses do the same with legacy customizations. The sunk cost fallacy is strong in the corporate world. “We spent a fortune developing this solution, we can’t just throw it away!” they cry, as the shambling code base drags itself into another fiscal quarter. It’s understandable – no one wants to admit that yesterday’s investment is today’s technical debt. So instead of challenging the undead code, we add more garlic and crosses (aka more patches and manual workarounds) hoping to keep it tame.

Business users, too, have their comfort zones. They’ve used the custom transaction for years and developed entire Excel macros and training docs to work around its quirks. To them, that user exit logic is the way it’s always been. Suggest replacing it with a standard process and you might hear, “But what if the standard doesn’t cover this tiny exception we have?” or the classic, “If it isn’t broken (from their perspective), why fix it?” In a heavily customized environment, people often fear the unknown more than the devil they know. The result is an ERP haunted by ghosts of requirements past, still lingering because someone, somewhere, is afraid to send them into the light.

Let’s not forget the IT department’s own pride (and fear). Admitting that a decade’s worth of custom development was perhaps not ideal is like a monster creator owning up that they’ve lost control of the creation. I’ve sat in meetings where the accumulated custom code base is, in truth, unknowable – no single person grasps all of it anymore. But who’s eager to stand up and announce, “Actually, we have no idea what half of our Z-programs do”? Instead, everyone nods sagely that everything is under control, while praying nothing ancient wakes up to prove them wrong. It’s easier to keep shoveling coal into the boiler than to rebuild the engine. Thus, the zombie code shuffles on, release after release.

Clean Core: A New Philosophy (Exorcising the Demons)

Here’s where our story takes a hopeful turn. In the SAP world, there’s a concept gaining a lot of buzz: Clean Core. And no, it’s not a new monster-hunting toolkit or a code sanitizer (though that sounds nice). Clean Core is more of a philosophical shift in how we approach ERP customizations. It says: What if we didn’t bolt the extras onto the monster’s back? What if we kept the core system as untouched as possible? Radical, I know.

SAP itself is strongly advocating this approach. They recommend minimizing custom code and keeping the ERP core standard and uncluttered. The idea is that if you stop transforming your core system into Frankenstein, you’ll have smoother upgrades, better performance, and a more stable system overall. In other words, no more monsters in the basement – or at least fewer of them.

But Clean Core is easier said than done, precisely because it’s not just a technical change; it’s a cultural one. It requires IT leaders, business stakeholders, and developers to collectively break the habit of a lifetime. It means telling the business, “No, we won’t hard-code that niche process into SAP finance just because you asked. Let’s find a standard way or use an extension platform.” It means telling developers, “Put down the enhancement framework; try a side-by-side extension or a Cloud Platform app instead.” In essence, Clean Core is about restraint and governance. It’s about treating the core system like a sacred castle keep that must remain pristine, while all the custom knights and dragons roam outside its walls (on the SAP Business Technology Platform or as add-ons that don’t disturb the core).

Embracing Clean Core often forces an organization to confront long-buried truths. You have to inventory your existing custom code and face which pieces are truly providing unique business value and which are just undead weight. (That report nobody runs anymore? Maybe it’s time to let it finally die.) Many companies are discovering, to their horror, just how much “spaghetti” has accumulated: thousands of custom objects, millions of lines of code, built by who-knows-how-many developers over the years. No wonder the system feels like a maze with traps at every turn – it is one! Clean Core is about acknowledging this and deciding to do something about it.

The good news is that SAP is offering more tools and methods than ever to support a Clean Core approach. Modern extensibility (in-app extensions, side-by-side apps, APIs, events, etc.) lets you achieve business requirements without hacking up SAP’s standard. But none of those tools matter if the mindset doesn’t change. It takes courage (and perhaps a bit of a rebellious streak) to tell your organization: We’re not going to create any more monsters. We’ll fulfill needs, but in a cleaner way that doesn’t involve electrifying a corpse of custom code on the main ERP server. Clean Core is about prevention – making sure the next generation of solutions doesn’t turn into the next Frankenstein.

S/4HANA: A Rare Chance to Rebuild Right

Every 20 years or so, you get a chance to renovate the haunted castle from the ground up. For many SAP customers, that time is now, with the move to S/4HANA. It’s not just a technical upgrade; it’s more like moving to a new castle on a new foundation. S/4HANA brings a modernized core, new features, and requires a re-evaluation of custom code (since some won’t even run on the new system without adaptation). In other words, the perfect opportunity to slay or retire a few monsters. How often do we get a do-over like this? Pretty rarely.

Think about it: if you carry over all your old ECC customizations blindly into S/4HANA, you’re effectively packing all your ghosts into the moving van and unleashing them in the shiny new house. That’s one way to ensure your new system feels old and fragile from day one. Instead, smart teams are using the S/4 transition to scrutinize every enhancement and ask, “Do we really need this anymore? Is there a standard way now? Can we achieve this with a side extension instead of core mod?” It’s a chance to lift the curse that has been placed on your ERP by years of quick fixes.

Of course, the business still expects continuity – you can’t just drop critical functionality. But with planning, you can replace the custom with a standard or modern equivalent as you migrate. S/4HANA, in effect, forces the conversation that everyone has been avoiding. It gives IT a mandate to say, “This is our moment to rebuild right.” When else could you get away with months of testing and reworking processes? The board signed off on the big project; use it to its fullest. It’s much harder to justify such sweeping changes in the quiet times. S/4 is our once-in-a-generation chance to do some deep cleaning and emerge with a leaner, cleaner core.

If this sounds a bit like an exorcism, well, it can feel that way. You might discover that some custom programs haven’t been used in years – time to archive them. Some modifications can be turned off because S/4 has built-in support that covers the need. Other things might still require custom solutions, but maybe now you’ll design them as isolated extensions rather than invasive surgery into SAP’s heart. It’s a philosophical reset.

Testing the Clean Core Waters (Prevent Future Pain)

Now, you might be thinking, “All right, this sounds great in theory. But how do we actually do Clean Core without breaking our business?” Excellent question (you’re very astute). My advice: practice in a sandbox, early and often. Specifically, spin up a demo S/4HANA system – one that is as vanilla as possible – and see how far you can go replicating your company’s core business processes with zero custom code. Treat it like a laboratory experiment: What if we had to run our business on clean standard SAP? What works out-of-the-box? What doesn’t? Where do you feel the urge to reach for the ABAP toolkit?

Consider this a dress rehearsal for the real move. You’ll learn a ton about which processes are flexible and which are absolutely married to custom extensions. Perhaps you’ll find that the latest S/4HANA innovations cover 80% of what your bespoke code used to do. The remaining 20% might be achievable via configuration or new extension techniques without violating the core. Or maybe you’ll hit a wall and realize, “Nope, we really do need a custom solution for this scenario.” Even that knowledge is power – better to identify the truly unavoidable custom pieces now, rather than in the heat of an actual migration project. Plus, when you do build that necessary custom bit, you can architect it in a clean-core-compliant way from the start.

Think of it like a fire drill. You don’t want the first time you try living without your beloved custom enhancement to be during the actual go-live weekend of S/4. Test it out when the stakes are low. And here’s a secret: sometimes, by removing the crutch of custom code, you’ll uncover that the business process itself can be simplified. People might realize the standard SAP process isn’t so bad, or maybe the workaround isn’t needed given how far the software has come. These epiphanies are gold, and they only come from venturing into that “clean system” experience.

Recap: Facing the Monsters Head-On

We’ve journeyed through a haunted castle of metaphors and memories, so let’s re-center on the real-world lessons we’re taking home. In summary, here are the key points once more:

1. Not all custom code ages gracefully. (Your once-brilliant enhancements might now be the walking dead.)
2. Clean Core is a cultural shift, not a technical one. (It’s about changing mindsets as much as code.)
3. S/4HANA is a rare opportunity to rebuild right. (A chance to slay legacy demons during migration.)
4. Testing Clean Core now can prevent pain later. (Rehearse in a sandbox to avoid surprises.)
5. Frankenstein systems are a choice — not a fate. (We create the monsters; we can choose to retire them.)

Keep these in your toolkit like five magic talismans as you navigate your own ERP journey.

Daring the Demo: Your Clean Core Quest

So, what’s the practical next step?

I challenge you to take action. Rent an S/4HANA demo system (they’re easier to get these days — cloud appliance libraries, trial offerings, pick your flavour). Gather a small team and attempt to rebuild your core business processes using only standard, Clean Core-compliant tools. That means no Z-code, no sneaky modifications — just configuration, SAP Best Practices, and maybe a tasteful side extension if it truly earns its place.

Cover the fundamentals: Finance (FI/CO), Sales (SD), Materials Management and Logistics (MM/LE/WM), Production (PP) — the whole supply chain backbone, clean and simple.

Will you hit gaps? Almost certainly. But that’s the point. This exercise gives you priceless insight into:

• What works out-of-the-box
• What doesn’t
• Where you’ve added complexity you no longer need
• What the real blockers are to moving toward a Clean Core

Treat it like an adventure — a dry run for your future transformation. You’re speed-running a stripped-back, elegant SAP system to see just how far standard functionality can take you.

And if that sounds overwhelming — you’re not on your own.

I’ve trained myself to do exactly this:
quickly configure full demo environments based on Clean Core principles,
covering all traditional modules from FI to WM,
to mirror your real-world operations in a way that’s visual, testable, and honest.

If you’re struggling to do this exercise on your own, or if you’d like someone to facilitate this prototype with your team or executive stakeholders, that’s where I can step in.

We’ll work through your business processes together — lean, focused, and brutally honest — and find out what really needs to be customised… and what doesn’t.

You can message me directly on LinkedIn if you want help kicking off the process, sense-checking your results, or just want someone to sit beside you while the torch flickers and the monsters start growling in the config.

Final Thought: Don’t Feed the Monsters

Frankenstein systems are a choice, not a fate.

You have the power to rewrite the ending — not with magic, but with clarity, courage, and a clean sandbox. The monsters won’t clear themselves out, but they’ll start retreating the moment you shine a light on them.

So light that torch. Gather your team. And step into the darkness.

Let’s build the system you always wanted — one that doesn’t come back to bite you in the next release.

Good hunting.

---

How This Fits the Fast Implementation Track

You might be wondering, “Okay, fascinating metaphor — Frankenstein laptops and zombie code — but what’s this got to do with the Fast Implementation Track?” A fair question. And the answer is: everything.

Because F.I.T. isn’t about theory. It’s about fixing what’s broken without accidentally reanimating the monster.

This article was written for every project manager, solution architect, or business lead standing in front of a heavily customised ECC system, wondering how they’re supposed to turn that into a clean, scalable S/4HANA setup — on time, within budget, and without losing their mind (or credibility).

So let’s plug it directly into the five F.I.T. pillars:

1: Focus

The Frankenstein article is a plea to get real about your core business processes. Which ones truly drive value? Which ones are propped up by legacy code no one understands anymore?

When you rebuild in S/4, don’t start with what the old system did. Start with what your business actually needs to do. What makes the business tick today — not ten years ago. The article’s story about zombie code is a case study in what happens when you lose sight of that.

2: Communicate

Talking about “clean core” is easy. Persuading your business stakeholders to give up their beloved workarounds and Z-reports? That’s a battle of trust, timing, and clarity. This article hands you a metaphor to help — use the Frankenstein image to start the conversation.

“Look, we stitched this together over years. It worked. But it’s not stable. We can do better.”
It’s not about blame. It’s about moving forward together — eyes wide open.

3: Simplify

This article is a torchlight into the rabbit warren of over-customisation. It challenges you to strip the system back to its essentials, even just as a test.

F.I.T. is about simplifying without compromising. Renting a clean S/4 system and recreating your core processes without touching the codebase? That’s simplification in action. It helps you identify what’s non-negotiable — and what was just legacy baggage all along.

4: Commit

Let’s be honest: many companies talk about clean core but flinch when it’s time to make the hard choices. The article’s warning about the sunk cost fallacy and “customisation pride” is aimed straight at leadership.

Use this as your wake-up call: if you want a clean, future-proof ERP, you need the top-down will to build it that way. That’s where F.I.T. helps — by giving you the language and framing to secure real executive buy-in.

5: Educate

What better way to teach the dangers of excessive customisation than with a story? This article isn’t just information — it’s a tool. Use it to educate your team, your business leads, even your sponsors.

Show them what zombie code looks like. Explain what Frankenstein systems cost in terms of time, updates, and morale. Let them see the alternative: a clean, understandable, human-friendly SAP system that grows with the business, not against it.

Bringing It All Together

This article isn’t a side quest — it’s part of your Fast Implementation Track arsenal.

It helps people understand why Clean Core matters in the first place.
It shows the consequences of avoiding simplification.
It arms you with metaphors that stick and stories that teach.
And it plants the seed: maybe it’s time to test how far you can get with just the standard system.

I built F.I.T. because after 25 years in SAP projects, I know what it looks like when people cut through the noise and take charge. You don’t need a perfect blueprint. You need the courage to lead with clarity — and the wisdom to leave the monster in the lab.

And if setting up that clean demo system sounds daunting?
Well… that just happens to be something I do best.

Let’s make your implementation the one they talk about for all the right reasons.

Send me a message on LinkedIn.
Cape optional — flashlight recommended.