You do not need to replace the system to fix the process

The case for replacing a core system is usually built from process complaints: it takes four days to onboard a customer, finance re-keys everything, nobody can get a report. Those complaints are real. They are also, more often than not, about the space between systems rather than the systems themselves.

Separate the two questions

Is the system failing at what it is for? Does the ERP post journals correctly, hold the ledger, close the period? Usually yes. Core systems that have run for fifteen years tend to be very good at their actual job.

Is the work around the system failing? Is data moved by hand, reformatted, reconciled, chased? That is where the four days live, and it is a different problem with a different price tag.

Conflating them is how a reconciliation issue becomes a three-year replacement programme.

What a bridge looks like

Between two systems you already own, sitting on top of both: extraction from whatever format the source actually produces, validation against rules you can read, orchestration with retries and an exception route, and a write path into the target through its API or, where there is none, through the interface a person would use.

That is weeks of work, not years. It is reversible. It does not require anybody to migrate history, retrain a department or freeze the roadmap.

When replacement genuinely is the answer

Three signals, and they are about the core's own job:

• The vendor's support ends on a date you cannot move.
• The data model cannot express something the business now needs - a second currency, a second legal entity, a product type it was never built for.
• Every change requires a specialist who is retiring, and the knowledge is not written down anywhere.

Those are structural. No bridge fixes them, and pretending otherwise just defers the cost at interest.

The order that saves money

Bridge first, measure for two quarters, then decide. Automation around a legacy core does two useful things even if you replace it later: it removes the immediate pain, and it documents - precisely, in code - what the process actually does. That specification is the most valuable input a migration can have, and it is the one most programmes start without.