There is a moment, early in every ERP implementation, that decides more about the next decade than almost anything on the contract. Someone demonstrates the new system, and a manager says, reasonably, "that's not how we do it here." The platform is flexible, the vendor is eager, the budget is fresh, and so the decision gets made, quietly and many times over, to bend the new system until it works the way the old one did. Every one of those decisions feels like diligence. Together they are often the most expensive mistake in the project, and the mistake is not technical. It is a leadership mistake about what you were buying in the first place.

Because here is the uncomfortable reframe. When you buy a mature, standard platform, the thing of value is not that it can be shaped to mirror your existing process. It is that it embodies a standard, tested way of working that thousands of companies have already refined. The standardization is the asset. When you customize it heavily to reproduce how you already worked, you are not tailoring the asset. You are spending money to destroy the specific thing you paid for, and replacing it with a fragile, isolated version of the habits you already had.

What you actually bought

It helps to be precise about what a standard ERP is. It is not a blank tool waiting for your process. It is an opinion, an accumulated, battle-tested opinion about how finance, operations, and reporting should flow, shaped by the collective experience of everyone who came before you on the same platform. That opinion is worth more than most of the individual habits it replaces, because your habits were built to fit your old system's limitations, your old org chart, and constraints that may no longer exist.

So the reflex "that's not how we do it here" deserves a harder second question that rarely gets asked: is how we do it here actually better, or is it just what we are used to? Most of the time, on examination, the local process is not a source of advantage. It is an accident of history, a workaround for a limitation the new system does not have, or a preference that no one has ever tested against the alternative. Customizing to preserve it is preserving the accident. The leadership act, the genuinely harder one, is to let the standard process replace the habit and to spend your political capital getting the organization to adopt it, rather than spending your budget teaching a new system to imitate an old one.

Why the customization becomes a tax

This would be a matter of taste if customization were free. It is not, and its cost has a particular, compounding shape that makes it worse than it looks at signing.

The core problem is upgrades. A standard platform improves continuously, and each new version assumes you are running the standard. Every deep customization you have made must be re-tested against every upgrade, and some of it will break, so the upgrade that should have been routine becomes a project. Over enough cycles, the rational response to that pain is to stop upgrading, at which point you are frozen on an old version, cut off from the improvements and the security and compliance updates that were a large part of why you chose a maintained platform. You bought a living system and slowly turned it back into the legacy system you were trying to escape.

The dependencies compound too. Heavy customization tends to fall outside the boundary of standard vendor support, so when something breaks you are more alone than you expected. And the knowledge of how the customizations work concentrates in whoever built them, an internal expert or an outside consultant, which quietly recreates the single-point-of-failure risk the platform was supposed to remove. The system that was meant to be an owned, durable asset becomes dependent on a specific person remembering why a specific modification exists.

You do not have to take this from critics of customization. Take it from the platform vendors themselves, who have every commercial incentive to let you spend on customization and instead now actively warn against it. SAP has built an entire published strategy around the principle, its Clean Core approach, which urges customers to keep the core standard and push differentiation to the edges through governed extensions rather than modifications to the core, spanning processes, data, integration, and operations. When the company that profits from your implementation is telling you to customize the core less, the signal is worth hearing. And it sits alongside a sobering benchmark: Gartner predicts that by 2027, more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals, with as many as a quarter of those failing catastrophically, and complexity and technical debt recur among the causes.

The honest line: some customization is right

This is not an argument for a rigid, take-it-or-leave-it system, and the "never customize" version of the advice is as wrong as the "customize everything" instinct it corrects. Some customization is genuinely correct, and refusing all of it would be its own failure, forcing the business to abandon things that actually make it distinct.

The distinction that matters is the reason for the customization. There is a real difference between customizing to preserve a habit and customizing to express a genuine differentiation. If a process is something your competitors also do, and you are only modifying the system because your version of that process is familiar, that is habit, and the standard is almost always the better choice. If a process is a true source of competitive advantage, something you do differently on purpose because it is part of why customers choose you, then customizing to protect it can be worth the tax, because you are spending to defend something real. The failure is not customization. It is customizing reflexively, to avoid the discomfort of change, on processes that were never advantages to begin with. Most of the customization that sinks implementations fails this test, which is why disciplined teams make the business justify each modification rather than making the system justify why it cannot mirror the past.

This is also why the decision compounds the way it does, and why it belongs in the same category as the platform choice itself, the kind of decision that gets much harder to reverse the longer you live with it. For that connected argument, how a platform grows less reversible every year you run on it, see the companion piece, The Systems Decision You Can't Easily Reverse.

The decision rule for a leader

Reduced to something usable, the discipline is a single reframe applied consistently. The default is the standard process, and the burden of proof sits on any request to deviate from it, not on the system to justify why it works the way it does. For each proposed customization, the question is not "can the platform be made to do it our way," because it usually can, at a price you will pay for years. The question is "is our way a real advantage worth defending, or a habit we have never examined." Answer that honestly, role by role and process by process, and most of the customization pressure resolves itself, because most of it turns out to be habit wearing the costume of requirement.

The leaders who get durable value from a major platform are not the ones who made it fit their company most precisely on day one. They are the ones who had the discipline to let a good standard change how the company worked, and reserved their customization budget for the few places where being different was actually the point. That is the harder path, because it asks the organization to change rather than asking the software to pretend nothing has. It is also the one that leaves you, years later, with an asset instead of a liability.

FAQs

Q1. Isn't the whole point of a flexible ERP that we can make it fit our business?
The point is that it can adapt where adaptation adds real value, not that it should replicate every existing habit. Flexibility is a tool to be used sparingly and deliberately. Treating it as a mandate to reproduce your old system spends the value of the standard platform and leaves you maintaining the same idiosyncrasies in a more expensive place.

Q2. How do we tell a habit from a genuine differentiator?
Ask whether the process is something your competitors also do or something you do differently on purpose as a source of advantage. If competitors do the same thing and you only want to customize because your version feels familiar, that is habit, and the standard is usually better. If the process is part of why customers choose you, it may be worth defending with customization.

Q3. What actually makes heavy customization so expensive over time?
Chiefly upgrades. Every deep customization must be re-tested against each new release and some will break, so routine upgrades become projects, and the temptation grows to stop upgrading altogether. On top of that, heavy customization can fall outside standard vendor support and concentrates maintenance knowledge in whoever built it, recreating the dependency risk the platform was meant to remove.

Q4. Don't the ERP vendors want us to customize more, since it's revenue?
That is what makes their guidance notable. SAP, for one, has published a formal Clean Core strategy urging customers to keep the core standard and push differentiation to governed extensions at the edges. When a party that profits from customization is advising restraint on the core, it is a strong signal that the long-term costs are real.

Q5. Is "never customize" the right rule then?
No, and that overcorrection causes its own damage by forcing the business to give up genuine advantages. The right rule is to make the standard process the default and require any deviation to justify itself as a real, tested advantage. Some customization passes that test. Most reflexive customization does not.

Q6. Our team is resisting the standard process. Isn't customizing the path of least resistance?
It is the path of least resistance now and the most expensive path later, because you carry the technical debt indefinitely and still have to manage the change eventually. The harder but cheaper path is to invest in adoption, helping the team move to the standard process, rather than encoding the resistance permanently into the system.

Q6. How does customization affect future acquisitions?
It makes them harder. Bringing an acquired company onto a heavily customized platform is significantly more complex than onboarding it onto a standard one, because the acquired operation has to be reconciled against your accumulated modifications. For an acquisitive company, customization discipline directly protects the ability to integrate what you buy.

Q7. What is the single most useful discipline to adopt?
Shift the burden of proof. Instead of asking whether the system can be made to match your process, require every proposed customization to demonstrate that your way is a genuine advantage rather than an unexamined habit. That one reframe, applied consistently, eliminates most of the customization that would otherwise become long-term technical debt.