Map the work it supports
Identify the people, workflows, integrations, and records that depend on the system. Include unofficial procedures and reports that may not be visible from the main interface.
Ask users to demonstrate important tasks and recurring difficulties. Distinguish a confusing interface from incorrect data, slow processing, or a missing capability. Those problems may have different remedies and should not automatically be grouped under “the old system is bad.”
Examine the ability to change it
Assess how the application is built, tested, deployed, and recovered. Find out whether the team can reproduce its environment and understand the boundaries around external services.
Identify areas where change is risky and explain the evidence. Missing tests may justify building a safety net around a workflow; a poorly isolated integration may justify creating a clearer boundary. Neither observation alone proves that the entire application must be replaced.
Compare bounded options
Consider targeted repairs, incremental replacement, and a broader rebuild against the same objectives. Include migration, parallel operation, training, and ongoing ownership in the comparison.
Choose an initial action that produces useful evidence. That might be improving one workflow, documenting a release process, or replacing a fragile interface while leaving the rest intact.
The result of a review should be a reasoned plan with explicit tradeoffs. A rewrite can be appropriate, but it should emerge from the application’s needs and constraints rather than from the unfamiliarity of its technology or the appeal of starting with an empty repository.
A practical example.
Begin a review by observing a few important workflows: creating a record, completing the main business action, correcting a mistake, and recovering from a failure. Pair those observations with the system’s operational records and the maintainer’s explanation of its constraints.
Classify findings by consequence and confidence. A demonstrated data-loss bug deserves a different response from a suspected performance issue or an unpopular visual style. Identify changes that improve the current service before assuming replacement is necessary. For each recommended action, state the supporting evidence, expected result, and a way to verify it. A useful review produces a sequence of defensible decisions, including what can remain as it is, rather than a general verdict that everything is outdated.
Put it into practice.
- Inspect representative workflows and operational recovery, not just the interface.
- Separate demonstrated faults, risks requiring investigation, and optional improvements.
- Tie recommendations to evidence, an owner, and an observable outcome.