Modernization vs. Replacement: How to Decide
You have an ERP system that has been running for ten or fifteen years. It works, but it hurts. People complain about the slow interface, integrations with new systems happen through CSV exports, and the last person who understood the code retired. Now what?
You have two basic paths: gradually modernize what you have, or replace it entirely with a new system. Both carry real risks. And sometimes the right answer is: do nothing yet.
When gradual modernization makes sense
Modernization is the right call when the core of the system is solid but the wrapper around it has aged. Specifically:
The data model still matches reality. Your tables and relationships describe how the business actually works. An invoice has line items, line items reference products, products have prices and warehouse locations. If that still holds, you have something to build on.
The architecture is separable. The system has some form of API, or at least a database you can connect to from the outside. It does not need to be a REST API — it is enough that you can read and write data without going through the user interface.
The problem is mostly UI and integrations. People hate how the system looks and how slow it responds. But the business logic inside does what it should. In that case, you can add a modern web interface on top of the existing database, connect new integration layers, and let the core keep running.
Real example: A manufacturing company had an ERP built on Oracle Forms from the late 1990s. The data model was solid — orders, materials, production processes, shipping. The problem was that the Oracle Forms client only ran on Windows XP and there was no e-commerce integration. Solution: new web interface on the same Oracle database, REST API for the online store, gradual migration screen by screen. It took 14 months, but the company never stopped operating.
When replacement is the only option
Sometimes modernization does not make sense. You will recognize it by these signals:
The technology is dead. The system runs on Visual FoxPro, Delphi 5/6, PowerBuilder, or old Clipper/dBase. You cannot find developers. The compiler does not run on a modern OS. Security patches do not exist. You cannot modernize this — you can only rewrite.
The data model is broken at its foundation. Everything lives in one table. A customer is also a supplier and an employee because "it was simpler back then." Prices are hardcoded. Multiple currencies do not exist. You cannot fix this by adding a new UI.
The system is monolithic with no interface whatsoever. The only way to get data out is a screenshot or manual export. No API, no database access, proprietary binary data format. Modernization would cost more than a new system.
The vendor no longer exists. The company that built the system went bankrupt. You do not have the source code, or you have it but nobody understands it. Documentation does not exist.
Real example: A distribution company with an ERP in Clipper/FoxPro. A 25-year-old application running on a single server with Windows Server 2003 (yes, in 2024). No API, no documentation, no source code. The only person who maintained the system left. There is no choice but to replace the entire system — and quickly, because the server could die any day.
5 questions to help you decide
Before you start anything, answer these five questions honestly:
1. Is the data model usable?
Look at the database schema. Do the tables and relationships make sense? Do they match how the business operates today? If yes, you have a foundation for modernization. If not, you are heading toward replacement.
2. Can you hire developers for this technology?
Try posting a job listing. If you are looking for a Delphi 6 programmer and nobody applies in a month, you have your answer. If the system is in Java, C#, or Python, you will find people.
3. How many integrations does the system have?
Count how many other systems are connected — accounting, e-commerce, CRM, warehouses, shipping providers, banks. Every integration you have to redo during a replacement increases risk and cost. Ten or more integrations = seriously consider gradual modernization.
4. How critical is continuous uptime?
If your ERP is the heart of the company and a one-day outage means millions in losses, a big migration is extremely risky. Gradual modernization lets you change the system while it is running.
5. What is the timeline pressure?
Is OS support ending? Is the last administrator leaving? Is a regulatory change approaching? Time pressure changes the equation — sometimes you have to go with replacement even if modernization would be cheaper, because there is no time for it.
Risks of each approach
Risks of modernization
- "The never-ending project" — modernizing piece by piece can drag on for years with no clear end
- Hidden complexity — you start changing one part and discover it is tangled with everything else
- Two systems at once — during the transition you have to maintain both old and new code
Risks of replacement
- Big bang failure — the new system launches and does not work, but the old one is already turned off
- Lost know-how — the old system contains years of encoded business rules that nobody documented
- Underestimated scope — "it will be done in six months" turns into two years and triple the budget
The Strangler Fig Pattern: best of both worlds
If you want neither a risky big bang nor an endless modernization, there is a third path: the strangler fig pattern.
Named after the fig tree that grows around a host tree and gradually replaces it. It works like this:
- Build new features in a new system
- The old system keeps running — you do not change anything on it
- Gradually move functionality from old to new, one piece at a time
- When the old system is empty, turn it off
The key is building an integration layer (API gateway, message bus, shared database) through which the old and new systems communicate. From the outside it looks like one system. Inside, you are swapping components.
This approach works well when you have time and want to minimize risk. It does not work when the old system is so closed that nothing can connect to it.
Sometimes the right answer is: do nothing yet
Honest advice that most vendors will not give you: if the system works, people know how to use it, and there is no external pressure (end of support, security risk, regulation), you do not have to change anything.
Modernization for the sake of modernization is wasted money. "The system looks old" is not a reason for a year-long project costing millions.
Make a change when:
- The system is holding back growth (you cannot add a new sales channel, enter a new market)
- A security or operational risk is forming (unsupported OS, no administrator)
- Regulation requires it (GDPR, accounting standards, industry-specific rules)
- Maintenance costs exceed replacement costs
Summary
| Situation | Recommendation |
|---|---|
| Good data model, bad UI | Modernization |
| Dead technology, no developers | Replacement |
| Many integrations, critical uptime | Strangler fig pattern |
| System works, no pressure | Do nothing yet |
| Time pressure + bad foundation | Replacement with parallel operation |
Every situation is different. If you are not sure, get an independent system audit — not from a company that wants to sell you a new ERP, but from someone who has no problem saying "leave it alone."