Software architecture

Modernize around the legacy system, not through it

A full replacement asks a hospital to change everything on one date. Moving one capability at a time removes that date.

2 min readSample article, shown until the final content is published.

A large rewrite is attractive because it promises a clean start. It also keeps the new system away from real users for a long time, while the old one keeps changing underneath it.

The alternative is known as the strangler fig pattern, a name Martin Fowler gave it after a vine that slowly grows around its host tree. New services grow around the old system and take over its work piece by piece, until little or nothing of it remains.

How the move works

  • Put a routing layer in front of the old system, so callers no longer depend on where a function lives.
  • Choose one capability with clear boundaries and build it as a new service.
  • Run both side by side and compare their results on real requests.
  • Move traffic gradually, keeping the route back to the old system ready.
  • Retire the old code, and only then start the next capability.

Choosing what moves first

Look for a capability that changes often, causes real pain and has few dependencies. An early move should prove the route works without putting a critical clinical workflow at risk.

What needs extra care in healthcare

Data is usually the hardest part. While two systems are live, one must be the clear source of truth for each record, and synchronization must be monitored. Downtime procedures, audit trails and access controls have to keep working in the middle of the move, not only at the end of it.

The risk to watch

This approach can stall halfway, leaving a team to run two systems indefinitely. Treat retiring old code as part of each step, and give the routing layer an owner. If nothing is being switched off, the program is adding to the estate rather than replacing it.

Next articleAccuracy is the wrong first question for clinical AI