Replacing a plant system that still works: what forces the decision

It looks cheap because its costs are hidden

An old system carries no licence increase, no project, and no visible spend, so it appears free next to a proposal. Its real costs are concealed in other budgets: manual work that exists because the system cannot do something, a report rebuilt by hand every period, orders keyed twice, and the standing risk that a single individual's absence stops something important. Making those visible is the first honest step, and the exercise is worth doing even if the conclusion is to keep the system, because most of them can be reduced independently of any replacement.

The events that finally move a decision

Boards rarely act on gradual risk. They act when the vendor withdraws support, when the operating system or hardware reaches an end that security policy will not tolerate, when the person who maintained it retires or leaves, when a customer requires data the system cannot produce, when an acquisition forces consolidation, or when a growth step exceeds a limit the design cannot pass. Recognising which of these is approaching allows the replacement to be planned rather than executed in an emergency, which is the difference between a controlled project and an expensive one.

Undocumented behaviour is the real migration risk

Systems built over decades encode business rules nobody remembers agreeing: a pricing exception for one customer, a rounding convention, an automatic substitution, a report that quietly excludes a category. These surface after go-live as things that used to work. Recovering them takes deliberate archaeology — interviewing the people who use the outputs, comparing old and new results on the same inputs, and examining the data for patterns the documentation does not explain. Budget for the discovery, because the assumption that the current system does nothing surprising is always wrong.

Replacing wholesale or carving it up

A full cutover is shorter, riskier and forces every decision at once. Carving off functions — taking quality, then scheduling, then finance — spreads risk and creates interfaces between old and new that must be built, run and eventually thrown away. Partial replacement suits sites where the legacy system does one thing genuinely well and several things poorly. It fails where the old system's data model is so entangled that no clean boundary exists, which is common in software written for one company over a long period.

Decommissioning is a project in itself

The old system does not switch off at go-live. It holds history somebody will need, it may be the only place a retention obligation is satisfied, and its hardware may run other things nobody documented. Plan the archive before cutover: what is extracted, in what readable format, how it will be queried, and how long the original must stay available. Set a decommissioning date and hold it, because a legacy system kept running indefinitely as insurance continues to consume licences, infrastructure and the attention of the one person who understands it.

Frequently asked questions

How do we build a case when the current system works?

Not on features, because a feature comparison invites the answer that the plant has managed without them so far. Build it on quantified manual effort, on specific risks with named single points of failure, on business the company cannot take because of a data or capability limit, and on the cost of an emergency replacement compared with a planned one. Framing it as risk timing rather than as system quality tends to get a hearing from people who have heard the feature argument before.

Can we run the old and new systems in parallel?

For a short verification period on selected transactions, yes, and it is valuable. For full parallel operation across the plant, rarely, because it doubles transaction workload at the moment people are least able to absorb it, and the two systems will diverge within days, which then produces arguments about which is right. A better use of the same effort is thorough reconciliation of balances and a defined set of end-to-end tests before cutover.

What should we do about the customisations?

Catalogue them, then classify each as a genuine business requirement, an obsolete workaround for a constraint that no longer exists, or something nobody can now explain. Expect a substantial share to fall into the second and third groups. Reimplementing the first group in a supported way is legitimate; reimplementing the rest recreates the same trap in newer software. The cataloguing is also the most reliable route to recovering undocumented business rules before they are lost.