ERP Customisation Services: Working With the System You Already Have

Replacing software that works is expensive, disruptive and very often unnecessary — and a vendor whose first answer is always “rebuild” is telling you about their business model, not about your system. ERP customisation services exist for the other answer: keep the core that has run your business for years, and extend, integrate or modernise it. This piece sets out how we judge whether existing code is a foundation or a liability, what taking over an orphaned system actually involves, what can usually be added and what cannot — and what happens to your source code while a stranger works on it.

Why “rebuild” is always on the quotation

There are honest reasons a developer prefers a rebuild. Writing new code is easier than reading someone else’s; a greenfield project carries no inherited bugs to be blamed for; and a rebuild is, simply, a much larger invoice. Notice that none of these reasons is about your system. Some rebuild recommendations are correct (we make them ourselves, and the second half of this piece describes when) but a rebuild should be the conclusion of an assessment you can read, not the opening position of a sales conversation. If the person recommending demolition has not yet inspected the building, you have learned nothing about the building.

There is also a quieter pattern worth naming: the developer who cannot say “no” gracefully says “rebuild” instead. Declining to touch unfamiliar code is a legitimate commercial choice, but it should be stated as one, “we only do greenfield work”, rather than dressed up as a verdict on software that may be perfectly sound.

Foundation or liability: the four questions

Whether an existing system can carry new work comes down to four questions, and most of them can be answered within days.

Do you hold the source code, and is it complete? Not “does the source exist somewhere” — do you hold it, current, with whatever build scripts and version history survive? If the code sits only with the original developer, settle who owns it before anything else, because every other option depends on that answer. Missing source narrows the road but does not always close it; the database usually survives even where the code did not.

Can it be built and deployed? From the code you hold to a running system in a fresh environment — can anyone actually do that today? A system nobody can build is a system nobody can safely change: every fix becomes an edit to the live installation, with no rehearsal and no way back. Restoring a lost build is unglamorous work, and it is often the first thing a takeover has to do.

Is the data model sane? The database schema is the system’s real skeleton, and it outlives every screen. We read it for the ordinary virtues: names a human can interpret, keys that enforce identity, each fact stored in one place rather than three. A dated interface over a sound schema is a foundation — interfaces are replaceable. A fashionable interface over a chaotic schema is a liability with good lighting.

Is the business logic recoverable? The rules that make the system yours (how prices are built, how commission is computed, what the month-end run actually does) must live somewhere reachable: in documentation, in code a developer can follow, or in the heads of staff who can explain it. Logic that exists only as observed behaviour (“it just comes out right”) has to be reconstructed before it can be preserved.

Score well on the last two and you have a foundation, even if the first two need repair before new work starts. Score badly on the data model and the honest conversation is about rebuilding — though even then, the rebuild applies to the code. The data, which is the accumulated history of your business and usually the most valuable thing in the system, migrates.

Taking over when the original developer is gone

The most common way this work arrives is not a strategy decision but an absence. The developer retired, moved abroad, wound the company down, or simply stopped replying; often it was one person, and the business has been quietly hoping nothing breaks since. Taking over such a system is a defined piece of work, not an act of faith, and it runs in a fixed order.

First, gather what exists: source code, database access, credentials, installers, and whatever documentation was written, however incomplete. Second, get the system building and deploying in a fresh environment — until that works, nothing else is safe to attempt. Third, read the schema against the live data, because the database tells the truth about how the system actually behaves in ways that memory and manuals do not. Fourth, make the first change small, reversible and tested against a copy — never experimented with on the installation your business is running on. And throughout, write down what is learned, so the takeover ends with a system that is easier to hand over than it was to find.

One thing we do not do is sneer at the inherited code. A system that has run a business for fifteen years has passed the only test that matters, whatever its age or fashion; existing-system support is the practice of respecting that while repairing what needs repair.

What ERP customisation services can usually add

Once a system passes assessment, the range of what can be added is wider than most owners expect.

New modules. Approvals, a store module, HR and payroll, a costing layer — built against the same database, in the existing system’s style, so users meet new capability inside software they already know. This is ordinary custom development with an inherited starting point rather than a blank one.

New reports. Often the cheapest win available, because reporting reads the schema without touching the workflows. The report that has been wrong for years, and the one nobody could ever get, are frequently small pieces of work rather than projects.

Integrations. The existing system connected to what it should have been talking to all along: a website, a bank file, a CRM, a mobile front end. The sharpest current example is compliance — sales-tax-registered businesses now have to report invoices to FBR electronically, and a compliant invoicing path can usually be built into the existing sales flow, or run alongside it, without disturbing anything else.

A modern interface over a working core. Desktop-era systems rebuilt for the browser (multi-user, remote, usable on a phone) while the database and the proven logic carry on underneath. We have walked this road with our own products since the Visual FoxPro era, which is why we argue for it with some confidence: the core that took years to get right is precisely the part not to throw away.

What usually cannot be added

Honesty requires the other list. Extension stops being the right answer when:

• The schema cannot represent the business you now are. A data model built for one company cannot be patched into serving a group of five; a stock model with no concept of batches cannot be coaxed into batch costing. That is surgery on the skeleton, and past a point, surgery costs more than a new skeleton.
• The platform is genuinely dead. When the tools that build the system can no longer be obtained or run, every change becomes a fight with extinct tooling, and the fights get worse each year.
• There is no source and no path to recreate it. A modern layer can sometimes be built around the database — reading and writing the same records the old core uses — but the core itself is frozen: nothing inside it can be fixed.
• Nobody can say what correct behaviour is. Years of contradictory patches can leave a system whose output no one can verify. Extending it extends the doubt.

When the assessment lands here, the conversation becomes the one we set out in custom ERP versus off-the-shelf — what to build or buy instead, and in what order. Even in the worst case, the history is rescued: a rebuild done properly begins by migrating the data, not by abandoning it.

Your source code in a stranger’s hands

Everything above requires you to hand your source code — and often your full database — to people you have just met. That is not a small thing. The system embodies your pricing, your margins, your processes and years of commercial history; it is intellectual property in the plainest sense, and it deserves more protection than a verbal assurance.

Our arrangement is specific: the work runs under NDA, the code is used only for the work you commissioned, and it is deleted from our systems once the requested work is delivered. The deletion matters as much as the NDA. It means the engagement ends cleanly — no copy of your business quietly living on a vendor’s machines, and no hold accumulating against the day you choose to work with someone else. A vendor should be retained by the quality of their last delivery, not by what they keep of yours.

The assessment is the promise

Bring us a system — whoever built it, however old — and what you get back is a reasoned answer: extend it, wrap it, or rebuild it, and why, in writing you can put in front of any other vendor. Quite often the answer is the smallest one: keep the core, add the two modules, fix the report. If you are looking at a rebuild quotation and wondering whether it is really necessary, that second opinion is a conversation away.