Rebuild vs Modernise vs Patch: A Practical Guide

The three options

When you're dealing with ageing software, the options feel binary: suffer through it or spend a fortune replacing it. But there are actually three distinct approaches, each with different cost profiles, risk levels, and timelines.

Option 1: Rebuild from scratch

Throw away the old system, design and build a new one from the ground up.

When it works:

• The old technology is genuinely obsolete (no developers available, no vendor support)
• The system architecture is fundamentally broken, not just outdated, but wrong
• Business requirements have changed so dramatically that the old system can't adapt
• The old system is small enough that rebuilding is a bounded project

Risks:

• Expensive, typically 2-5x the cost of modernisation
• Long timeline, 6-18 months with no new functionality during the build
• High failure rate, re-implementing years of business logic is harder than it looks
• "Second system syndrome", the tendency to over-engineer the replacement

Option 2: Modernise incrementally

Replace the old system piece by piece while keeping it running. New features go in the new system; old features get migrated over time.

When it works:

• The system is mission-critical and can't be taken offline for months
• Some parts work fine and don't need replacing
• You want to spread cost over time rather than one large capital investment
• The business needs new capabilities while the migration happens

Risks:

• Temporary complexity, running two systems during the transition
• Requires clear boundaries between old and new
• Can stall if the old system's data model is deeply entangled

Option 3: Patch and extend

Keep the existing system, fix what's broken, add what's missing, accept its limitations.

When it works:

• The core system is still fundamentally sound
• The technology is still supported and has available developers
• Business requirements haven't changed dramatically
• Budget is constrained and the immediate needs are specific

Risks:

• Accumulating technical debt, each patch makes the next one harder
• May be throwing good money after bad if the system is fundamentally limited
• Can create a false economy, cheap now, very expensive later

Decision framework

The strangler fig pattern

The strangler fig pattern is the most reliable approach for modernising critical systems. Named after the strangler fig tree that gradually grows around its host, the pattern works like this:

1. Identify the boundary: Find a clear functional boundary in the old system (e.g., reporting, customer portal, order processing).
2. Build the replacement: Build the new version of that component in modern technology.
3. Route traffic: Redirect users to the new component while the old one continues running.
4. Migrate data: Move the data from the old component to the new one.
5. Decommission: Once the new component is proven, switch off the old one.
6. Repeat: Move to the next component.

This gives you the benefit of a rebuild with the safety of incremental delivery. At any point, if the project stalls, you still have a working system: partly old, partly new, but functional.