When would you re-architect rather than replatform, and how would you sequence it?

What is being tested

Whether you require a forcing reason for the most expensive strategy, and whether you sequence incrementally.

When re-architecting is justified

Only when the structure itself is the binding constraint:

• Change cost is high and rising, evidenced by lead time in that area.
• A component's resource profile is fundamentally incompatible with the rest.
• A regulatory or residency requirement cannot be satisfied by the current structure.
• The technology is at end of life with no upgrade path.

"It is old" and "it is not how we would build it now" are not justifications.

Why not a rewrite

Rewrites of long-lived systems fail at a well-documented rate for structural reasons:

• The requirements exist only in the code's behaviour, including behaviour nobody intended and some customer now depends on.
• The business does not stop changing, so the new system chases a moving target while the old must still be maintained.
• No value lands until the end, so the project is cancellable for its entire duration and gets no corrective feedback.

The sequence

1. Insert a routing facade, with everything still pointing at the existing system. A no-op release that proves routing, observability and rollback. Highest-value first step, and routinely skipped because it delivers no visible feature — which is exactly why it is safe.

2. Extract one capability, chosen for learnability rather than importance.

3. Run both and compare on read paths — serve the old result, log every difference. The only reliable way to discover undocumented behaviour, and it will find dozens of cases. Budget time to triage them: some are legacy bugs you should not replicate, and deciding which is a business conversation.

4. Decide the data direction explicitly per slice — legacy remains system of record, dual write with reconciliation, or migrate with the capability. Letting it be decided implicitly is how you end up with three systems believing they own the customer record.

5. Repeat, decommissioning as you go.

The characteristic failure

The migration that never finishes. The last 20% — rare capabilities, batch jobs, reports, partner integrations — is hardest, funding runs out, and the organisation permanently operates two systems.

Guard: budget decommissioning as explicit work, and track "capabilities remaining on legacy" as the primary metric rather than capabilities delivered.