Replacing an obsolete ERP or an abandoned proprietary application

Most projects to replace an abandoned proprietary application start with something trivial: a server that will not restart, a browser refusing a page, an employee leaving with the only working knowledge of the system. The pain is old; it has simply become visible from the top floor.

The sentences that open these files

They are strikingly similar from one company to the next, whatever the sector. They describe less an IT problem than a loss of control over a tool that daily operations depend on.

• "Our vendor has not answered in six months, and the maintenance contract is still running."
• "The developer who built the tool has left; nobody has ever seen the code."
• "It runs on a language version that is out of support, and our host is asking us to migrate."
• "The vendor was acquired and the new owners have announced end of life in eighteen months."
• "We pay an annual licence for software that has had no update since 2019."

None of these situations forces you to throw everything away. They only force you to stop deciding by default: doing nothing is a choice, it has a cost, and that cost rises every quarter. The first mistake is jumping straight to replacement without measuring what the current tool actually does.

Replacing an obsolete ERP: four exits, not one

There are four ways out of this situation. A development studio has every incentive to show you only one — the one it sells. Here are all four, with the cases where each is the right answer.

The choice does not turn on technology but on a single question: is your process a specificity that sets you apart, or a commodity everyone runs the same way? Payroll is a commodity. A year-end rebate engine built around your own group's rules is not.

Recovering source code and data when the vendor has gone quiet

This is the part nobody anticipates and the one that most often stalls the schedule. Work through it in this order, and start before announcing anything to your current supplier.

1. Reread the original contract: intellectual property clause, any source code escrow arrangement, reversibility and data restitution terms. What you can demand depends entirely on it.
2. Take stock of the technical access you already hold: hosting account, domain registrar, database access, administration accounts, certificates. Many companies discover at this point that everything is in the supplier's name.
3. Take a full copy of the database and files before any difficult conversation. A server switched off over an unpaid invoice does not come back on because you need it.
4. Formally request, in writing and with a deadline, a complete data export in a standard format together with the handover of the sources. A verbal request produces nothing, and the written trail matters if the matter reaches a lawyer.
5. If the sources stay out of reach, document the database schema by reverse engineering. In a management system most of the business logic can be read back from the data and the screens, even without the code.
6. Unplug nothing until a full backup has been restored on a machine you control and verified by actually opening it.

In the worst cases the code is never recovered, and that is not fatal: what carries value is the data history and the knowledge of the rules, not fifteen thousand lines written in a dead framework.

Auditing what exists, before deciding

1. 1

   Real functional inventory

   What the software does today, not what the 2011 specification anticipated. Usage is measured screen by screen: in a ten-year-old in-house tool a significant share of the functionality is no longer used by anyone, and rebuilding it would be paying for empty space.

2. 2

   Technical condition and exposure

   Language and database versions, unmaintained dependencies, internet exposure, backups tested rather than merely scheduled. This is the section that separates "urgent" from "merely uncomfortable".

3. 3

   Condition of the data

   Volume, duplicates, fields repurposed away from their original meaning, incomplete history. This is what drives migration cost, and it is the line most consistently underestimated in rebuild quotes.

4. 4

   A costed decision

   A short document applying the four exits to your situation, with a budget range, a sequence and the consequences of doing nothing. The decision is yours — including the decision not to work with us.

MEKANO is a Lyon-based development studio specialising in business management applications, particularly those of buying groups and member networks. We work at a fixed price, in batches delivered over two-week sprints, on a Go, React and PostgreSQL stack, and we hand over the source code. The usual entry point is a three-week scoping exercise with a prototype, between €6,000 and €10,000 excluding VAT: the cheapest way to find out whether a rebuild is justified at all.

When we are not the right answer

• Your need is standard accounting, payroll or sales administration: an off-the-shelf package will cost less and be better maintained than bespoke development.
• You are looking for contractors to reinforce an in-house team: we work at a fixed price on a defined scope, not on a staffing basis.
• The current system works and the only complaint is cosmetic. Rebuilding the screens of a healthy tool is rarely the best return available.
• Nobody on the business side can give the project half a day a week. Without an available owner, a rebuild reproduces the old system in new colours.
• You want a decision by tomorrow morning. A serious audit takes two to three weeks, and skipping it is the most common cause of rebuilds that go off the rails.