Compare repair and replacement against the same service
An unfamiliar application can make replacement feel safer than investigation. A fresh design promises a cleaner start, while the old system carries every visible frustration. The comparison is unfair unless the replacement is asked to preserve the useful work the current system already performs.
Describe the failure without judging the whole application
In a fictional association, staff cannot correct the category on an older member record. New registrations work, member documents remain available and the finance export is still used every month. The failure is serious, but those working capabilities also have value.
A bounded investigation should establish which path fails, under what conditions and with what evidence. It should distinguish the application action from dependent messages or provider calls. If the failure cannot be reproduced, that limit belongs in the decision rather than being hidden behind a confident repair estimate.
Compare like with like
A repair estimate may cover one correction path and its neighbouring checks. A replacement estimate must also account for registration, documents, finance export, permissions, migration and the transition between systems. Comparing the repair with a bare new login screen understates the replacement.
Use a capability inventory to record what must continue, what can be retired and what is genuinely new. Ask the organisation's staff to review it; long-standing workarounds can contain important rules that were never documented elsewhere.
Examine constraints that affect both options
Source access, supported dependencies, data quality and provider capability can limit repair. They can also complicate replacement. If the organisation cannot export its records in a usable form, a new application does not make that problem disappear.
Some constraints may justify a different architecture or staged move. Others need a supplier decision, an access transfer or approved business rules before either technical option can be responsibly scoped. Record the source of the constraint and the evidence needed to resolve it.
Consider a staged boundary
The choice may be to retain a stable record system while replacing its public interface, or to isolate a failing integration before moving the wider application. A staged plan needs an explicit owner for each fact so that the old and new parts do not both claim authority.
The transition also needs a way to reconcile updates and recover from a failed cutover. “Keep the old system as a backup” is incomplete if it stops receiving new records. The organisation must understand which state would be restored and which work would require reconciliation.
Write the decision in terms of evidence
A recommendation should state the observed problem, the options considered, the capabilities preserved and the material uncertainty. It should explain why the chosen scope is proportionate. It need not claim that one approach will remain correct forever.
A repair can be a sensible investment in a useful system. Replacement can be justified when the required service cannot reasonably be maintained within its constraints. The purpose of the comparison is to make that conclusion reviewable.
Read the PHP repair service for a bounded investigation, and hidden costs for work that can sit outside the feature list. Describe your current application with a representative failure and the capabilities it must keep.