When is it 'too late' to modernize an ERP?

It's never too late, but it gets more expensive the longer you wait. The warning sign is when the only person who knows how to maintain it is close to retirement, when data is only read but never written, or when every change requires days of manual testing. At that point, the operational risk of not modernizing outweighs the risk of modernizing.

Should I migrate everything at once or in phases?

Almost always in phases. The 'strangler fig' pattern (wrapping the old system with new services that progressively replace it) lets you operate with the legacy in parallel and migrate module by module. A big bang only works for small systems or when there's a hard regulatory deadline.

How much does it cost to modernize an SMB's ERP?

It depends on the size of the system, but as a reference: a complete modernization of an SMB ERP (50-200 users, 5-10 modules) typically ranges from 40,000 to 200,000 EUR. The real figure depends much more on the state of the documentation and data quality than on the technology you choose.

What if the original vendor no longer exists?

It's one of the most common scenarios. If you have access to the source code, modernization is perfectly possible even if the vendor disappears. If you only have the executable, you need to consider reverse engineering the data model (legal if the data is yours), parallel rewriting, and assisted migration. Higher cost, but feasible.

Modernizing a legacy ERP: when to migrate and when not to

There are two kinds of legacy ERPs. One is the old system that works, invoices customers, causes no problems, and nobody wants to touch. The other is the old system that does cause problems, everyone knows the issues, and the question is when to modernize it.

What follows isn’t about the first one. If your ERP is stable, covers what you need, and you have no new features in the pipeline, leave it alone. We’re talking about the second one: when technical debt starts costing more than fixing it, the objective signals to watch before deciding, and the strategies that exist beyond the false dilemma of “throw it all away or grin and bear it”.

The 7 signs your ERP has outgrown its job

These decisions usually start with a vague intuition: “this is slow, there are things we can’t do”. Before investing in consulting, it’s worth translating that intuition into something measurable. The signs we see over and over in the audits we run:

There’s a parallel Excel for every ERP module. If the system can’t generate the report operations needs or can’t handle the correction the business asks for, the team moves to Excel. Each parallel Excel is a hole of unsynced data.
Any modification has to go through the original vendor. And the vendor takes weeks, charges by the hour, or, worse, no longer exists. What should be an operational tweak becomes a project.
Modern integrations aren’t possible. E-invoicing, banks via API, digital time-tracking, e-commerce. If every new connection is solved with a nightly CSV dump, technical debt grows on its own.
Data is read but no longer written. The ERP holds the historical record, but day-to-day decisions are made outside it. Clear sign the system has stopped being the system of record.
Endless onboarding. Learning a proprietary ERP without modern documentation takes months. When a new hire takes months to become productive doing what should take weeks, there’s a real opportunity cost.
Only one person knows how it works internally. And usually they’re three years from retirement. The bus factor is 1.
Business asks for features and the answer is “we can’t do that”. The system decides what’s feasible. When technical limitation dictates commercial strategy, the ERP runs the business instead of serving it.

If three or more apply, modernization is no longer optional: it’s a silent emergency. Silent because the system keeps working. The cost accumulates in the curve of inefficiency, not in a visible failure.

The 4 real modernization strategies

The most repeated false dilemma is “throw it all away or grin and bear it”. There are four real options, and each has its scenario where it wins.

Strategy 1: Total rewrite (big bang)

Rewrite the whole system in parallel and do cutover on a specific date.

Wins when: the system is small (under 5 modules, under 20 users), the data model is documented, the business domain is stable, or there’s a regulatory deadline forcing it (a new statute, e-invoicing with mandated format, etc.).

Loses when: the system is large and carries years of undocumented rules. The rewrite “rediscovers” them through production bugs. It also loses when the company can’t afford 6 to 18 months without new features.

Strategy 2: Strangler Fig

Martin Fowler’s pattern. You wrap the old system with a modern layer (API gateway, web façade) and migrate modules one at a time. The old system dies slowly; the new one progressively takes on responsibilities.

Wins when: the SMB has a mid-sized system (5-10 modules), wants to validate new architecture without full commitment, or has a small team that can’t maintain two systems in full parallel.

Loses when: the data model is so centralized you can’t break it into modules. Or when the business demands everything migrated now, without coexistence.

Strategy 3: Side-by-Side

Old and new coexist with bidirectional synchronization. Users work in whichever suits them. The old one is turned off when all critical flow has moved to the new one.

Wins when: the migration must have zero data-loss risk, the system is critical and a failure can’t stop operations, or the client wants to validate the new vendor in production before committing.

Loses when: it can get expensive. You’re maintaining two systems for months or years, and the team doubles up. Bidirectional sync adds complexity: any inconsistency replicates to the other side.

Strategy 4: Extend, don’t migrate

Sometimes the right answer is not to migrate. The old ERP works; what it lacks is openness. You build on top, without touching the core: REST API over the legacy data model, web and mobile consuming that API, modern integrations the old system was never going to have natively.

Wins when: the ERP covers 80% of what you need and only the modern layer is missing (web, mobile, integrations), the cost of migrating clearly exceeds ROI, or the vendor still supports the base system.

Loses when: the old system is genuinely a black box with no access to the data model. Or when the technology is so old there’s no stable way to put an API on top of it.

In practice, most SMBs that modernize well go through strategy 2 (strangler) or 4 (extend). Total rewrite has its place, but it’s the minority case.

How to decide: the monthly-cost matrix

The decision is rarely technical; it’s financial. And the right question isn’t “how much does modernizing cost?”, it’s this one: “how much is it costing me per month not to do it?”.

Monthly cost of not modernizing (honest estimate, no makeup):

Hours lost in parallel Excels × average team salary
IT team hours on manual patches
Transcription errors you catch (the ones you don’t catch are worse)
Business features that can’t ship (lost revenue)
Bus factor risk: probability × impact if the key person disappears
Manual work due to missing integrations: shipments, reconciliations, cross-validations

Monthly cost of modernizing (amortized over 5 years):

Total investment ÷ 60 months
Maintenance of the new system
Team learning curve

If the first exceeds the second, the decision is arithmetic. If they’re close, you have to weigh regulatory risk, talent flight, and strategic timing. Variables that don’t fit on a spreadsheet but matter just as much.

The factor almost nobody assesses: the state of the data

In the audits we run before starting a modernization, what the client most underestimates isn’t the technical complexity of the new system. It’s the state of the data in the old one. And that’s usually what triples timelines.

Questions to answer before touching code:

Are there duplicates in customers, suppliers, or products?
Are the accounting codes aligned with today’s fiscal reality, or with the one from eight years ago?
How many years of history actually need to be migrated, and how many can stay in read-only mode?
Are there orphan catalogs, records without cross-references, malformed IDs?
Does operations use free-text fields as if they were structured? (Spoiler: yes, almost always.)

Each one is a mini-project. A serious modernization starts with a 2-3 week data audit before touching anything.

What about compliance during migration?

If the old system covers regulatory obligations (time-tracking under your country’s law, e-invoicing, GDPR, fiscal retention of 4 years, etc.), modernization can’t break that compliance during the transition. Side-by-side and strangler make it easier for both systems to keep generating legally valid records. A poorly planned big bang leaves the company with undocumented periods, exposed to penalties.

When there’s a duty to track time or retain data during migration, what we recommend:

Keep the old system as the system of legal record until the new one is validated.
Generate the records in both during the overlap. It’s extra work, sure; less than defending three missing months before an inspector.
Turn off the old one only after you’ve cleared the critical phase (3 to 6 months) without incidents on the new one.

In the Spanish market we operate in, this means specifically respecting RD-Ley 8/2019 for time-tracking. In Germany, the BAG ruling on time tracking; in France, Article L3171-2 of the Code du travail. Different statutes, same principle: don’t break the registry during the transition.

Build vs Buy: custom or SaaS?

The parallel question is fair: since we’re going to spend money, why not buy a standard SaaS and move on? We cover it in depth in Custom software vs SaaS: when to choose each. The summary: if your inherited ERP exists precisely because your processes don’t fit a standard SaaS, the answer is still custom. If processes have standardized over the years and a vertical SaaS covers 90%, the decision changes.

How we approach a modernization

The steps we apply when a client asks us to modernize an inherited ERP:

Initial audit (2-3 weeks). Code review, data model, integrations, data quality, critical processes. Ends with a report defining real scope, not aspirational scope.
Strategy decision. We recommend rewrite, strangler, side-by-side, or extend, with documented justification and no ego attached to one option.
POC of the most critical module (4-6 weeks). Before committing to the full project, we validate viability with the module that hurts most if it fails. If the proof doesn’t convince, we stop.
Iterative roadmap. Deliveries every 2-3 weeks with joint review. No “I’ll come back in 6 months with this done”.
Phased migration. Users go to production with each module as soon as it’s ready. No big bang.
Controlled legacy shutdown. Only when critical flow has been in production for at least a quarter without incidents.

If you have an ERP you suspect has hit its limit, let’s talk. A 30-minute call usually is enough to tell whether you need serious modernization or just a layer of integrations on top.

Resources

Strangler Fig pattern (Martin Fowler, original)
Custom software vs SaaS: when to choose each: the parallel decision worth making before you start.
VisibleSoft services: what kind of modernization projects we take on.
Book a free diagnostic