Article

When to Modernize Instead of Rebuild

Rewrites are seductive and usually the wrong first move. How to assess existing systems and improve them without stopping the business.

When to Modernize Instead of Rebuild

Why rewrites are seductive

A rewrite promises a clean architecture, current technology, and none of the accumulated compromises of the existing system. The appeal is easy to understand, and the failure mode is well documented: the new system takes longer than planned, the old system keeps changing in the meantime, and the business carries two systems for far longer than expected.

The existing system, however imperfect, encodes years of business rules and edge cases. Those rules are rarely written down anywhere else.

Assessing the system you have

Modernization decisions benefit from a structured assessment: where the system creates risk, where it slows delivery, which parts are genuinely unmaintainable, and which parts simply look old. Age is not a defect. A stable module written years ago may be the least of a team's problems.

The output should be a prioritized picture rather than a verdict — the specific areas where change will produce the most value, and the risks that make those changes worth planning carefully.

Incremental modernization patterns

Most effective modernization happens in steps that are individually reversible. Extracting a service behind an interface, replacing a component while keeping the contract, introducing automated tests around behavior that must not change, or moving one workflow at a time to a new implementation all allow the business to keep operating while the landscape improves.

These steps are less dramatic than a rewrite, and they have a considerably better track record. They also produce working software continuously, which keeps stakeholders engaged and surfaces integration problems early.

When a rebuild is justified

There are situations where replacement is the right call: the technology is unsupported and cannot be secured, the architecture prevents any change, or the business process itself has changed so fundamentally that the original design no longer applies.

Even then, the sequencing matters. Building the new system alongside a still-operating one, migrating data deliberately, and keeping the door open to run both for a period is usually more expensive upfront and considerably cheaper in total.

What we're learning,
while we build it.

One email a month. Practical notes on software, cloud and production AI, written by the engineers doing the work. No filler.