Prepare legacy-system discovery before a replacement

An old application may frustrate users while quietly supporting exports, scheduled jobs, and exceptions that no current feature list describes. Replacement discovery must explain what the organization depends on, not just what the screens display. Otherwise, a simpler-looking product can remove an operating capability that somebody still needs.

Follow work beyond the visible application

Trace important tasks from their trigger to the final business outcome. Include files, email, manual checks, and downstream reporting. Ask who notices when a step fails and who knows how to recover. Look for workarounds that compensate for missing or unreliable system behavior.

GOV.UK discovery guidance includes legacy technology and existing processes among constraints to understand.[1] Record each dependency with an operational owner and a consequence of interruption. Do not assume that undocumented behavior is unnecessary simply because nobody included it in the initial replacement request.

Inspect data meaning and interface behavior

Identify authoritative records, identifiers, state definitions, and the rules behind calculated fields. Compare representative records with actual operational use. A field called closed may mean completed, cancelled, or merely removed from a work queue. Resolve those differences before designing a migration.

GOV.UK technology guidance recommends understanding existing systems and data sources, and checking that interfaces work as expected.[7] Use controlled investigations to verify important assumptions. Keep discovery read-only where possible, and obtain separate authorization for any test that changes an operational system.

Hypothetical example: replacing a booking tool

A hypothetical equipment rental business considers replacing its booking tool. Staff reveal that an exported file also tells a workshop which items need inspection before the next rental. The export is absent from the proposed feature comparison.

The team maps the file fields, its recipient, and the consequence of a missing run. It then decides whether the replacement should preserve the export temporarily or support a different agreed handoff. The example does not assume that moving booking records alone completes the transition.

Build a replacement-readiness checklist

Use evidence to define the first replacement boundary. Keep discoveries that affect business continuity visible to both the buyer and the delivery team.

• List critical tasks, hidden exports, scheduled work, and manual recovery steps.
• Name owners and consumers for each important interface.
• Check representative records for ambiguous meanings and missing relationships.
• Define what remains operational while the replacement is introduced.
• Identify acceptance evidence, reconciliation needs, and conditions for stopping transition.

Compare replacement with narrower interventions

A dependency inventory is never perfectly complete. Prioritize what can stop important work or corrupt decisions, and record confidence limits. Avoid requesting unrestricted copies of production data merely to make research easier.

Replacement may still be justified, but a narrower change can sometimes address the immediate problem with less transition work. Compare process improvement, an interface change, partial replacement, and full replacement. Choose based on the verified operating boundary rather than the age or appearance of the existing software.