Technical debt and clean core have become closely linked in the ERP modernization conversation. As companies confront years of accumulated customizations, it's easy to understand why. But somewhere along the way, we've started treating customization itself as the problem.

In this article, we'll challenge that assumption and look at why customization isn't inherently technical debt, where the real problems with traditional ERP customization came from, and how clean core and side-by-side extensibility give us an opportunity to build differently going forward.

The Bill Comes Due

ERP modernization projects have a tendency of putting decades of process and technology decisions on trial. If you’re been running your ERP system for more than a handful of years, it probably looks pretty different from what was originally implemented. Over time, custom code, modifications, integrations, workarounds, and plenty of other changes have no doubt found their way into the system as the business evolved around it.

Looking back, most of those decisions probably made a lot of sense at the time. The business needed something the ERP didn't provide, so the IT team built it. A standard process didn't quite fit, so it was modified. An acquisition introduced another system, so someone created an interface to connect the two. Taken individually, none of these decisions were wrong. Still, after a couple of decades, they can add up to a surprisingly complex environment.

A major upgrade or migration brings all of that history back into focus. Suddenly, every customization has to be evaluated. Is it still being used? Does the new platform provide the capability out of the box? Can the code be carried forward? Does anyone still understand how it works? And how much is it going to cost to refactor or replace?

That last question can be particularly painful. We've seen many ERP modernization programs where simply understanding and dealing with years of accumulated customizations becomes a significant part of the overall effort. It's easy to look at that bill and conclude that customization was the mistake. That's also where the clean core argument starts to sound particularly compelling.

The Technical Debt Hangover

There's no question that years of ERP customization can leave behind a lot of technical debt. Code that once made sense gets harder to maintain as the people who wrote it move on and the standards around it shift. Eventually you can't touch even a small piece of it without tracing through years of dependencies to see what breaks.

But it's worth looking more closely at where that debt actually came from in the first place. For decades, ERP customers were widely encouraged to build extensions directly within their vendor's ecosystem using proprietary development tools and frameworks. If you were an SAP customer, you built enhancements using SAP’s proprietary ABAP and NetWeaver development environments. Oracle customers built on the Oracle Application Framework and PL/SQL, while Dynamics customers built on X++ and AL. You get the idea.

Looking back, one of the major problems with this approach was that it required you to make a long-term bet on more than just the ERP product itself. You were also betting that the vendor would continue investing in the proprietary development tools, frameworks, middleware, and runtime environments surrounding it. Considering that an ERP system might stick around for 20 years or more, that's a pretty big bet.

To put this concept into perspective, consider the shift to the web in the early 2000s and the aftershocks many companies are still feeling today. As browser-based applications took off, many software vendors cobbled together new web frameworks and middleware on top of their legacy platforms. Customers invested heavily in those technologies, only to watch some of them get replaced, deprecated, or abandoned as web technology advanced at a breakneck pace. Fast forward to today and there are still plenty of legacy web applications lying around that only work on specific versions of Internet Explorer and other technologies that should have disappeared years ago.

Figure 1: Working with Legacy Web Transactions

It's tempting to chalk all of this up to vendor lock-in, but I think the bigger issue is that most ERP vendors are fundamentally in the business of building business applications, not development tools. Over the years, many of them took on the additional responsibility of building their own programming languages, application frameworks, middleware, user interface technologies, and development environments. Keeping all of that competitive as the broader technology landscape changed turned out to be a much bigger job than anyone probably anticipated.

That's an important distinction when we talk about technical debt. A customization might continue delivering real business value long after the technology underneath it has become the liability. In that case, the debt wasn't necessarily created by the decision to customize. It came from tying that investment to a proprietary technology stack that couldn't evolve at the same pace as the rest of the industry.

The Clean Core Overcorrection

Given everything we just described, it's not hard to understand why clean core has become such a popular topic. After spending millions untangling decades of custom code during an ERP modernization project, the last thing anyone wants to do is start accumulating the same kind of debt all over again.

The basic idea behind clean core makes a lot of sense. Keep unnecessary modifications out of the ERP, use supported extension points, and create some separation between the core application and the capabilities you build around it. Done well, this makes upgrades easier and gives you more flexibility as the underlying ERP continues to evolve.

The problem is that the message sometimes gets taken to the extreme position of clean core = no customization. We've talked with customers who are so concerned about recreating the technical debt of the past that almost any custom development is immediately viewed as something to avoid. If the ERP doesn't provide a capability, the first instinct becomes finding another packaged product that does.

Of course, this is music to the ears of software vendors. If custom development is automatically considered technical debt, the safest answer is always to buy more software. Another module, another SaaS application, or another product in the vendor's portfolio becomes easier to justify when the alternative has already been labeled a bad architectural decision.

Clean core was never about giving up the ability to customize. It's an architectural philosophy about where those customizations take place, how they're built, and how tightly they're coupled to the underlying ERP platform. The whole point is to preserve the core while giving the business room to extend it without creating the same upgrade problems we're dealing with today.

That's an important distinction because the lesson from decades of ERP technical debt isn't that we shouldn't customize. It's that we shouldn't keep building highly coupled customizations inside proprietary application stacks and expect those investments to age gracefully for the next 20 years. Modern extension patterns give us a better option: keep the core clean, move differentiated capabilities to the right platforms, and build them in a way that allows both the ERP and the extensions around it to evolve independently while growing with your business.

Customization Isn’t Technical Debt

This brings us back to the distinction at the heart of this article: customization and technical debt aren't the same thing. While poorly conceived customizations can certainly create technical debt, simply building something your ERP vendor didn't provide doesn't automatically put you in the hole.

Think about the custom applications that run some of the most important parts of your business. Maybe it's a quoting tool built around a unique sales process, an application that helps technicians perform specialized work in the field, or software that coordinates a manufacturing process competitors haven't figured out how to replicate. If those applications solve real problems, are actively maintained, and continue to evolve with the business, calling them "technical debt" simply because they were custom built doesn't make sense.

Technical debt starts to accumulate when those investments become difficult to change: the technology ages, dependencies grow brittle, and the skills needed to touch it get harder to find. What used to be a small change now means touching five other things just to get it done. Or, as we've seen with traditional ERP customization, the platform underneath shifts and forces you to rework business logic that was working just fine, simply to keep it running.

That's why where and how you customize matters so much. Side-by-side extensions allow you to separate differentiated business capabilities from the ERP platform underneath them. Instead of surgically embedding every workflow, user experience, and piece of business logic directly inside the ERP, you can safely innovate around the edges using APIs, events, integration services, low-code platforms, and modern cloud application services.

Figure 2: Understanding the Side-by-Side Extensibility Concept

Of course, moving to the cloud doesn’t magically eliminate technical debt. You can build a terrible application in Azure just as easily as you can build one in your legacy ERP system using proprietary toolsets. Architecture still matters. So do development standards. After all, someone still has to maintain what you build.

The difference is that you're no longer tying the useful life of that investment directly to the useful life of your ERP implementation. A well-designed extension can evolve as technology changes, connect to different systems, and potentially survive multiple generations of the ERP sitting behind it. That's a much better foundation for customization that is intended to grow with the business rather than become something you have to unwind during the next major upgrade.

Buying Doesn’t Eliminate Technical Debt

If custom development is treated as technical debt by default, buying another piece of software starts to look like the safer alternative. But buying software doesn't make complexity disappear. It just changes where that complexity lives.

Every new application introduces another technology to integrate, secure, support, and keep current. It may also bring another data model, user experience, subscription, and vendor roadmap you don't control. And if the product doesn't quite fit the business, you can still end up with workarounds and additional integrations just to close the gaps.

Sometimes buying is absolutely the right answer. But avoiding custom development shouldn't be the reason. Packaged software can become technical debt too, and buying more of it isn't automatically a cleaner architecture than building something well.

Build Where the Investment Can Grow

If you're going to invest significant time and money building something unique to your business, you should expect that investment to last. That's difficult when the useful life of your customization is tied directly to a particular version of an ERP product, proprietary development framework, or vendor-specific technology stack.

Side-by-side extensions give us a different model. By shifting customizations onto modern cloud platforms, you can separate the investment you're making in the business from the ERP system underneath it. The ERP can continue doing what it does well as the system of record, while custom applications, workflows, integrations, and other differentiated capabilities evolve around it.

And modern cloud platforms offer a lot more than a collection of PaaS services for professional developers. Platforms like Microsoft Azure increasingly span traditional application development, integration, data, low-code/no-code development, and AI. A relatively simple business application might be built quickly with Power Apps and Power Automate, while more complex requirements can be addressed with Azure services and traditional development frameworks. Increasingly, AI-powered development tools can help accelerate both approaches.

That's a very different proposition from the proprietary development environments many ERP customers invested in over the past few decades. Cloud providers have a strong incentive to keep improving the tools developers use to build on their platforms. Right now, that means substantial investment in low-code platforms, developer tooling, AI-assisted development, integration services, APIs, and new application patterns that didn't exist a few years ago.

None of this eliminates the need for good architecture or guarantees that today's technology choices will last forever. But it gives you a much broader set of tools and considerably more flexibility in how you build. You can choose the right development approach for the problem without forcing every customization through the lens of your ERP vendor's technology stack.

That's really the opportunity behind clean core. Don't stop customizing. Be much more deliberate about where you put those investments, how tightly you couple them to packaged software, and whether what you're building has room to grow with the business.

Closing Thoughts

As organizations work through years of accumulated ERP technical debt, it's understandable that nobody wants to repeat the mistakes of the past. Clean core gives us a useful framework for doing that, but only if we understand what we're actually trying to keep clean.

The lesson shouldn't be that customization is bad. Businesses have always needed to extend packaged software, and that's unlikely to change. The lesson is that we need to be much more deliberate about where those customizations live, how they're built, and how tightly they're coupled to the products around them.

Modern cloud platforms give us an opportunity to do this differently. We can keep the ERP focused on the transactional capabilities it does well while building differentiated experiences, workflows, automations, and applications alongside it using technologies designed to evolve independently.

Twenty years from now, we'll probably have our own set of technology decisions to explain. That's unavoidable. But hopefully we won't be paying another enormous bill simply because something valuable to the business was built in the wrong place.