Compare repair and replacement against the work that must survive

A replacement proposal often looks cleaner because it starts without the history, exceptions and informal knowledge carried by the existing system. A fair comparison puts those requirements back into view. The question is whether the organisation can achieve and maintain the needed behaviour through a bounded repair, a managed transition or a new system.

Establish what is failing and what still works

Choose a representative interruption and reproduce it within authorised access where possible. Identify the running revision, recent changes and relevant provider dependencies. Distinguish an observed cause from a hypothesis that still needs investigation.

Also list the working tasks. If customers reliably receive appointment information and staff can find historical records, those capabilities have value. A replacement must preserve or deliberately retire them; they do not disappear from scope because the new demonstration focuses on a dashboard.

Assess ownership separately from code quality

The organisation may have maintainable code but incomplete account access, or full access to a system whose essential dependencies are unsupported. Those conditions call for different action. Recovering ownership can be the first project even when a later rebuild is likely.

Identify who controls hosting, source, provider accounts and release instructions. Do not promise a repair that depends on unavailable materials. Make the missing access and its decision owner explicit.

Price the transition as part of the alternative

A replacement includes content and data migration, staff review, account setup and cutover work. Follow one active request and one corrected historical document into the proposed destination. A cleaner data model is not useful if staff cannot understand the relationships they need.

Consider whether part of the old system can remain in service during a staged move. That may reduce interruption, but it also creates a period in which record ownership and synchronisation need clear rules. The arrangement should be deliberate rather than an accidental permanent duplication.

Define an honest repair trial

For a narrow reproduced defect, agree a private correction and meaningful checks. Include the failed case, an ordinary control and adjacent behaviour at risk. Set a stopping condition if the investigation reveals a larger dependency or the evidence no longer supports the proposed repair.

A successful trial can justify an authorised release decision. It should not become a claim that every hidden fault has been removed or that the system needs no continuing maintenance.

Leave with a decision the owner can explain

Record the evidence, option chosen, exclusions and conditions that would change the recommendation. A decision to replace can be sound; so can keeping useful software while repairing one bounded part. Both need an operating and recovery plan.

Read application recovery for the investigation scope and migration for transition work. Contact Faith Forge Labs with the failing task and the access you control.