1. What exact consequence are we preventing?
“The system is old” is not a business case. A decision needs a consequence: a regulator-visible outage, a client ready to leave, a platform leaving support, a key person retiring, or delivery economics that no longer work.
Name the consequence, its likely timing and what it costs if nothing changes. Without that, every proposed scope and deadline floats free of the reason for doing the work.
2. Do we know what the current system actually does?
The documented requirements are rarely the whole product. Years of exceptions live in code, stored procedures, operations runbooks and the heads of the people who reconcile failures by hand.
- Which business rules exist only in code?
- Which reports or integrations are treated as “temporary” but run the business?
- Which manual interventions keep apparently automated workflows alive?
If those answers are unknown, a rewrite estimate is partly an estimate of undiscovered behaviour.
3. Which dependencies make the boundary real?
A neat architecture diagram often stops exactly where the risk begins. Ask for the real dependency map: databases, batch jobs, identity, vendor APIs, spreadsheets, reporting, devices and downstream teams.
The rewrite boundary should follow replaceable seams, not the boxes that make the proposal slide easier to draw.
4. What must remain true while the change happens?
“Feature parity at launch” is too late. Define the behaviours, service levels, reconciliation totals and regulatory evidence that cannot regress during migration.
A characterisation test harness—tests around what the estate does today—often buys more safety than another month of design. It turns inherited behaviour into something every staged change can be checked against.
5. Can the highest risk be retired without replacing everything?
Separate the urgent exposure from the merely unpleasant code. An out-of-support database, six-hour batch, single-person deployment or fragile integration may be removable in weeks even if the wider estate takes years.
Ask for at least one staged alternative and the point at which each phase can stop safely. If the only viable plan releases value at the end, you are being asked to bet the year.
6. How will the board know the first phase worked?
Agree the measurements before work starts. Useful measures include:
- time and failure rate for the business-critical path;
- lead time for a safe change;
- supported components and key-person dependencies retired;
- reconciliation or defect rate;
- time for another developer to make a change without specialist rescue.
“The new platform exists” is an output. It is not evidence that the risk or delivery problem improved.
7. Who can operate and change it after the supplier leaves?
A modern architecture owned only by its implementer is new legacy software. The plan should name who shadows the work, how decisions are recorded, what lands in your repositories and when your team demonstrates that it can change and recover the system unaided.