Audit, Redesign, Modernise or Rebuild

Decide which intervention each part of your product actually needs.

The mistake this prevents

Rebuild arguments tend to be conducted about the whole product. That framing makes a good answer hard to reach, because products are rarely uniformly broken.

One module is genuinely beyond repair, three are fine, two need a different interface over the same logic, and one nobody has looked at in years.

Decide capability by capability. The answer is usually a mixture, and the mixture is cheaper than either extreme.

Step 1: List capabilities, not screens

Write what the product does for people, in their language: raise a quote, approve an order, reconcile a statement, onboard a customer. Aim for eight to fifteen.

If you find yourself listing screens, you are one level too low.

Step 2: Score each capability on four axes

For each capability, answer with high, medium or low.

01
Value
How much does the business or the customer depend on this? Dated and unloved is not the same as unimportant. The ugliest screen is often the one holding the revenue.
02
Product clarity
Do we know what this is supposed to do, and does it still match how the work happens?
03
Experience quality
Can people do it without training, workarounds or exports?
04
Technical cost
What does it cost to change this safely today?

Step 3: Read the pattern

Capability scoring patterns
Product clarity	Experience quality	Technical cost	Likely intervention
Clear	Poor	Low	Redesign. The logic is right, the interface is not.
Unclear	Poor	Low	Audit first. Do not redesign something nobody can define.
Clear	Good	High	Modernise underneath. Preserve the experience, change what is behind it.
Clear	Poor	High	Modernise and redesign together. Sequence carefully, one at a time is often cheaper.
Unclear	Poor	High	Rebuild is a candidate. The only combination where it usually earns its place.
Clear	Good	Low	Leave it alone. Deliberately. Write down that this was a decision.

The last row is a real answer and it is under-used. Leaving something alone on purpose is different from neglecting it.

Step 4: Test the rebuild candidates properly

Before accepting any rebuild, answer these:

What does this capability currently know that nobody has written down? Years of accumulated exceptions live in old software. A rebuild throws them away unless someone extracts them first.
Who still relies on the current behaviour, including the parts we consider bugs?
Can both versions run at once, or is this a single irreversible switch?
What happens to work in progress at the moment of migration?
If the rebuild takes twice as long as planned, what breaks in the meantime?

If those cannot be answered, the risk is not technical. It is that the organisation does not know what its own product does, which is a reason to assess before committing, not a reason to start coding.

Step 5: Sequence

Rank by value against cost, then apply two rules. Do the thing that unblocks other things first. And do not run redesign and replatforming on the same capability simultaneously unless someone can explain how you will tell which change caused which outcome.

What this does not tell you

It is a structured argument, not an assessment. It does not evaluate your architecture, estimate cost, or examine the code. It gets a room from "rebuild or not" to a specific, defensible list.

What to do next

Product Modernisation covers the full intervention set, Product Redesign the interface-led route, Legacy Software Modernisation the underlying structure, and Replatforming Product Design the platform move.

The Gold Image Printing case shows a legacy ERP interface modernised without discarding the operating knowledge inside it.

If the room disagrees about a capability, the Product Modernisation Assessment starts with a free audit on one of them.

Start with one capability