Every Customisation Is a Loan You Repay at Every Upgrade
You borrow capability today and pay interest on it for the life of the system. Good customisation is not a question of what can be built, because nearly anything can. It is a question of which loans are worth taking. We work down a four rung ladder with you, and most requests are settled a rung or two below code.
50+ ERP and software projects. Zero failed projects since 2021.
The build cost is the deposit, not the price
What a customisation really costs you shows up years later, in upgrade weekends, in regression testing and in the code nobody left alive understands.
You borrow capability now and repay it every release
A customisation is not a purchase that ends when the invoice is paid. It is a liability that sits on your system and asks for money again at every upgrade, every integration change and every time a new person has to understand it. That is fine when the capability earns more than the interest. It is a bad deal when the capability is a habit nobody has questioned since the last system. Before we quote anything, we ask the honest question: does this process actually win us business, or is it just how we have always done it. Long standing habit is the single most common justification we hear, and it is not a good one.
- Every request is priced with its recurring cost, not only its build cost.
- We name which rung of the ladder the request actually belongs on.
- Requests that fail the business test are written down and declined, with the reason.
Supported extension points survive. Core changes do not.
The difference between a cheap system and an expensive one is rarely how much was customised. It is where the customisation was put. Work built on published APIs, documented hooks and app level extensions usually comes through an upgrade with a short regression run. Work that edits core files does not, because the vendor moved the code underneath it. Someone has to reapply it, retest it and often rewrite it, every single release. Say it plainly: a core modification made once becomes a cost line in every upgrade budget for the life of the system. We will build one when it is genuinely the only route, and we will tell you the annual number first.
- Extension points first, core modification only as a last resort.
- A register of every customisation, so nothing is a surprise at upgrade time.
- Regression tests written with the change, not after the upgrade breaks.
Six kinds of change a customisation request turns out to be
Almost every request arriving as we need a customisation is one of these. Only the last one usually deserves the word.
How a request becomes a change, or does not
What good delivery actually looks like
Written specification
What the change does, what it does not do, and acceptance criteria your team can test against rather than argue about.
Version controlled code
Every change in a repository with a history, so you can see who changed what, when, and roll back if you need to.
Separate dev and test
Nothing is written in a live system. Build in development, prove it in test on a copy of your data, then release.
Documentation
Setup notes, the reason the change exists and how it works, so it is maintainable by someone other than whoever built it.
Regression tests
Automated or scripted checks that run before each upgrade, so you find out in test rather than on Monday morning.
Periodic debt review
An annual pass over the register to retire custom code nobody uses, because unused code still costs you at every upgrade.
What the discipline buys you
Already know which ERP you want?
The ladder is the same everywhere. What differs is how far each product lets you go before you are modifying something you should not.
SAP handles this differently again. Under the clean core model you do not modify S/4HANA at all, you build extensions on BTP against released APIs, which is the same idea as the third rung of our ladder enforced by the vendor. If that is your platform, start at our SAP implementation page.
Why teams bring customisation work to TCB Infotech
ERP customisation questions
When is a customisation actually justified?
Will our customisations break when we upgrade?
What does a typical customisation cost?
Why do you push back on customisation requests?
Will you maintain customisations somebody else wrote?
How do we tell a configuration from a customisation?
Bring Us Your Customisation List
Book a free consultation. Send the list of changes your team has been asking for and we will tell you which are settings, which are reports, which are worth building, and which we would decline and why.
Book a Free Consultation →No commitment. Expect us to talk you out of some of it.
What an ERP Customisation Engagement Covers
The work starts before any code is written and does not finish when it ships. Here is how a request is assessed, how a change is specified and built so it survives upgrades, and how we keep the pile of custom code from quietly growing into next year's problem.
From a request to a change you can still afford in five years
Every request is tested against the ladder first
We sit with the person who raised it and find the outcome behind the ask. Then we work down four rungs in order: can you adopt the standard process, can a supported setting do it, can a documented extension point do it, and only then does code in the core come up. Reporting requests are separated out early, because a large share of what arrives as a customisation is really a question about data that already exists.
- The outcome recovered from the request, not taken at face value.
- A written answer naming the rung and the reason.
- Report and dashboard requests met as reports, at a fraction of the cost.
Specified, built outside production, and tested
Anything approved gets a written specification with acceptance criteria, so sign-off is a test rather than an opinion. Development happens in a separate environment under version control, proved in a test environment on a copy of your data, then released. Where a supported extension point exists we use it, even when editing the core would be quicker, because the quicker route is the one that bills you again every release.
- Acceptance criteria agreed before the build starts.
- Version control, separate development and test environments.
- Regression tests written alongside the change.
Technical debt is counted, and some of it is retired
Every change goes into a register with what it does, why it exists, who asked for it and where it sits relative to the core. Once a year we walk the register with you and look for features nobody has used since they were built, because unused custom code is still retested, still ported and still paid for at every upgrade. Retiring it is usually the cheapest improvement available to you that year.
- A customisation register you own and can hand to anyone.
- An annual review that names candidates for retirement.
- Usage checked before a customisation is carried into the next version.
Everything the engagement hands over
Request assessment
Each request answered in writing with the rung it belongs on, the cost, and a plain reason where the answer is no.
Specification pack
Scope, behaviour, exclusions and acceptance criteria for every approved change, agreed before a line is written.
Upgrade-safe build
Delivered on supported extension points wherever they exist, with the core left alone unless there is no route around it.
Documentation
How it works, why it exists and how to change it, written for the next person rather than for the person who built it.
Test suite
Regression checks tied to the acceptance criteria, run before every upgrade so breakage is found in test, not in production.
Customisation register
One list of every change on your system, with its owner, its risk at upgrade and its annual carrying cost.