Your Customisations Are Why You Cannot Upgrade

Someone in your organisation said "we're different" - and then paid a partner to prove it in code.

That customisation solved a real problem in 2017. Another one solved a pricing quirk in 2019. A warehouse exception followed in 2021, then a finance workaround that "would only take a few days." None of them felt existential at the time, but together they are why you are still running a version the vendor stopped smiling about two years ago. Your customisations are why you cannot upgrade - not the licence, not the IT team, not "change fatigue." The modifications.

What customisation debt looks like on a Tuesday

A customer needs a new commercial term. In a clean system, that is configuration and a process update. In yours, it becomes a development ticket, a regression test against six other bespoke scripts, a weekend deployment window, and a quiet prayer that month-end still closes on time.

Then an upgrade notice lands from the vendor. Your internal IT lead opens the impact assessment and goes quiet, because half the custom objects will break, the partner who wrote two of them no longer works there, and nobody has documentation that matches what is actually running in production. So the upgrade slips again, and the business tells itself it is being prudent. Prudent would have been saying no to the third "tiny" modification in the first place.

Config vs custom - and why the distinction matters

Configuration uses the product's intended levers - fields, workflows, roles, parameters, templates - and survives upgrades when it stays within supported bounds. Customisation rewrites behaviour the product never intended: core code changes, fragile scripts hooked into upgrade-sensitive points, shadow logic that quietly duplicates what an integration layer should own instead.

Mid-market businesses blur these two constantly, often because a partner calls everything "configuration" on the original quote. Three years later, your ERP renewal conversation is blocked because you cannot move without rewriting a private dialect of the system that only a handful of people ever understood. If a change requires a developer every single time the business tweaks a process, it was never configuration. It was a permanent tax on agility, dressed up as flexibility.

"We're different" is usually "we refuse to standardise"

Some specialisations are real - regulated traceability, unusual fulfilment models, multi-entity complexity the vanilla product genuinely cannot hold. Many are not. Many are historical preferences, quietly protected by the people who invented them a decade ago.

Before you fund another modification, it is worth asking whether this is a genuine competitive process or simply an internal habit that has never been challenged. If competitors in your sector run standard flows and still win, your "difference" may just be an expensive identity you have been paying to maintain. The honest escape route is not more uniqueness - it is deciding which exceptions genuinely deserve an extension or an external workflow, and which deserve a process change instead.

Prefer extensions and integration layers over core surgery

When you truly need behaviour the ERP does not provide, avoid cutting into the core wherever you can. Put logic in supported extension frameworks, put orchestration in a data and systems integration layer that sits beside the ERP, and automate exceptions outside the monolith where possible, so the system of record itself stays boring and upgradeable.

That architecture is far less glamorous than a partner demo promising "we can make it do anything," but it is also how you still own your upgrade path five years from now. Vendor sales narratives love deep customisation, because it locks you in and expands the services ledger over time. Practitioner tech consultancy should push the opposite instinct: minimise irreversible modifications, maximise reversible extensions, and force a genuine business case before any departure from standard.

How to start unwinding without boiling the ocean

You do not need a big-bang rewrite to begin, just a sequence that actually gets followed.

Start by inventorying the customisations that exist - what they do, who owns them, what business rule they encode, and what breaks on upgrade - because if you cannot list them, you are already flying blind. Rank what you find by upgrade risk and business value, and kill or replace the high-risk, low-value ones first; some "critical" scripts turn out to support a process nobody runs anymore anyway. Where custom logic can become configuration, a report, or an external workflow, convert it, and where it simply encodes a bad process, retire it along with that process rather than rebuilding it faithfully. Finally, change the approval gate itself: no new core customisation without an explicit decision that extension or integration genuinely cannot cover it, signed by someone who owns the upgrade roadmap, not only the department making the request.

The uncomfortable conclusion

You are not stuck on an old ERP because the product is ancient. You are stuck because years of modifications turned the product into a one-off machine that only a dwindling number of people still understand.

Replacing the ERP without confronting that habit simply restarts the clock. You will customise the new one for exactly the same reasons, and in five years you will be reading an article that sounds a lot like this one. Escape the customisations - do not escape into a new set of them. That is the upgrade path that actually works.