Modernise the existing system or build a new one?

The age of a system is easy to discuss, but age alone rarely determines its future. What matters is whether the solution still supports the key process, allows safe change and creates less risk than rebuilding it would.

The replacement question often appears when every change takes too long, incidents return and knowledge of the solution is held by a few people. This does not automatically mean that everything should be rewritten. Product, architecture, data and delivery problems first need to be separated.

Modernisation makes sense when the core still creates value

If the system supports the right process, contains important business rules and allows its most problematic parts to be isolated, gradual modernisation usually limits risk. Tests, interfaces, security and architecture can improve while continuity is preserved.

A new solution is justified when the problem has changed

A rebuild becomes reasonable when the current system preserves an obsolete operating model, cannot meet security requirements or makes every subsequent change more expensive despite local repairs. It should still not be a single large leap. The organisation needs a plan for migrating data, functions and users, and a clear point at which the old solution can be retired safely.

A sound decision identifies the first scope rather than merely choosing between “old” and “new”. It may isolate one process, secure the highest-risk area or prototype a new part of the solution using real data.

From insight to action

Diagnosis should come before the technology decision

RedHex.AI combines process, product and architecture analysis to establish what should remain, what should change and how to make the transition without unnecessary risk. The first outcome may be a problem map and a justified modernisation or build plan.

Sources and further reading

  1. Strangler Fig Application Martin Fowler
  2. Strangler fig pattern AWS Prescriptive Guidance

Product Discovery

We help build products around real customer needs and justified business value. We structure decisions, validate the most important assumptions and define a first scope that supports learning before committing a larger implementation budget.

Software Development

We create and develop systems that improve processes, support users and help achieve business goals. We combine functionality with appropriate architecture, quality and security so the solution is useful today and ready for further development.

Would you like to apply this to a specific situation?

Describe the process, decision or problem. In the first conversation, we will establish whether a practical next step exists and what it should be.

Let’s talk