Your ERP is forty years old, and that isn't the problem

"We've got a system that's forty years old, works well, and is rock solid." The director who told me that was almost apologizing. He had no reason to. His system was carrying twenty companies, several territories and three different lines of business without falling over. Plenty of ERPs installed three years ago don't manage that.

What an old system has that others don't#

Why does an old ERP have value?#

An ERP that has run for decades has a property no new project can buy: it contains your business rules, including the ones nobody can state any more.

The discount calculation by product category and customer category. The handling of the special case of the company acquired in 2011. The cost-allocation rule that applies to the three northern branches and not the others. None of that is documented. It's all in the code, and it all works.

A replacement is above all an exercise in archaeology: finding those rules, rewriting them, and discovering in production the ones you'd missed. That's where projects go wrong — never on the technology, always on the special cases nobody saw.

Three qualities people underrate#

A stable system has three: it surprises nobody, it's mastered by people who are in the building, and its annual cost is known.

The real problem isn't age, it's being sealed shut#

What irritates about an old ERP is almost never what it does. It's that you can't put anything next to it.

The symptoms, always the same#

• To get data out, you have to ask somebody to run an extract.
• That extract arrives as a flat file, dropped on a server, re-read overnight by another program.
• The figure consulted in the morning describes last night's situation.
• Each new tool adds another extract, and nobody has the full list.

That's an interface problem, not a core problem. And it can be fixed without touching the core.

An old core and a sealed core are not the same thing#

An old core does its job: it holds the rules, it absorbs the volumes, it does not fall over. A sealed core prevents you building around it. The two get confused in everyday conversation, and that is what launches replacements nobody needed.

Open it up rather than replace it#

How long does it take to open an ERP through APIs?#

The company I mentioned started that work around 2019. Today, roughly ninety percent of its flows go through programmatic interfaces: some in real time, some several times a day, some once a night, depending on what the data requires. The rest continues as flat files, because on those flows it's good enough.

That kind of work is slow — "it takes a while", he said, which in director-speak means two years — but it has a rare property: it's reversible and it happens in pieces. At no point was the business hanging on a cutover.

The order that works:

1. Reads first. Exposing data for reading presents no risk to the system. That's where eighty percent of the value is: dashboards, alerts, assistants, field applications.

2. Writes next, flow by flow. Starting with the one that costs most in re-keying, with a way back.

3. The rest never, if it's good enough. A purchasing flow that runs on a nightly extract and that nobody has ever found annoying doesn't need modernizing.

We stopped trying to replace it. We decided to build around it.

What you build around it#

Once the data is accessible, custom development becomes useful exactly where an ERP is weak by nature: at the point of contact with the field and with daily decisions.

The four bricks we put in that layer#

• A day's list per person, fed by what is actually happening in the system: the quote with no reply, the order awaiting approval, the blocked file.
• Mobile screens, for technicians and teams who will never sit at a terminal.
• Alerts that come and find people, rather than waiting for them to consult a report.
• An assistant that answers questions by searching the data, with the permissions of whoever is asking.

The ERP remains the system of record. There aren't two truths: there's one, and several ways of looking at it.

The four signs you really do have to replace#

There are cases where opening up isn't enough. Four signs, and one is enough on its own:

1. Nobody can modify it any more. Not "it's hard to recruit": nobody, and the vendor no longer exists.
2. The hardware or operating system is out of support, to the point where you can't apply a security patch.
3. A mandatory regulatory change is impossible to implement. That's what forces many businesses' hands, and it's a good reason.
4. The core business has changed. You were a wholesaler, you've become a service provider: that's no longer the same data model, and no interface will bridge it.

Outside those four cases, the question deserves at least to be postponed by a year, with the money it would have cost invested in the layer above.

How we open an ERP without replacing it#

An old ERP is rarely the problem: it keeps the accounts, and it keeps them well. What is missing is everything happening around it that is still done by hand.

So we build on top rather than instead: documents read and pushed into the ERP, follow-ups that go out on their own, alerts when something drifts. The ERP keeps its role as the record and does not move. See the automations page, and what can be plugged in without touching what exists.

Legacy ERP: what to remember#

An old ERP that runs isn't a debt: it's a repository of business rules that work, and it has value.

What costs you is not its age but its impermeability. Open it for reading first, flow by flow: it's the work with the best ratio of risk taken to value gained.

And keep replacement for the four situations where it really is unavoidable. In the others, the money is better spent on what you build around it.