Compare the change against the knowledge the old system still holds

An inherited application may be difficult to maintain while still expressing years of valuable business rules. A replacement should preserve the useful relationships deliberately, rather than discover them after migration.

Gather evidence before choosing the extent

List the affected task, reproducible failure, source access, dependencies and record structure. Demonstrate an ordinary example and an exception. A document access problem may be confined to a download endpoint; a missing ownership model may require a larger change.

Unavailable access should be recorded as an uncertainty. It does not prove that the current system cannot be repaired, but it can prevent a dependable estimate. A time-bounded assessment can answer a defined question without committing to a full rebuild.

Compare three practical options

A focused repair changes the understood boundary. A staged improvement moves one responsibility while the remaining application continues. A replacement changes the wider operating model and requires migration, reconciliation and a switch plan. Include the effort of running two systems and training operators in the comparison.

Review recovery with newer records

Suppose an import succeeds but staff create new requests before a later fault is found. Restoring yesterday's files alone may lose those requests. Agree where new work is recorded and how it is reconciled if recovery is needed.

The preferred option should explain preserved behaviour, removed constraints and remaining dependencies. Explore application modernisation or discuss an assessment using a redacted example.