Legacy Assessment

Modernisation programmes fail more often from insufficient understanding of the current state than from poor design of the target. The system has been running for fifteen years, the people who built it have gone, the documentation describes an intended design rather than the current one, and the behaviour that matters is encoded in code and data.

What the assessment must establish. Actual functionality, derived from code analysis and from observed usage rather than from documents — including the substantial portion of features nobody uses, which need not be rebuilt. Dependencies in both directions, discovered from network traffic, database access and file transfers, because the list of consumers is always longer than the register says and the surprises are what derail cutovers. Data model and quality, since decades of accumulated data carries inconsistencies the new system's constraints will reject. Business rules, which are the genuinely valuable and genuinely undocumented asset. And true cost, including licences, infrastructure, support and the scarce skills required.

The output that makes the decision defensible is a per-capability disposition rather than a system-level verdict, since large legacy systems typically contain a core worth preserving and a periphery worth discarding.

The discipline to insist on: assess before committing to an approach. Programmes that pick rewrite or strangler first and then investigate discover constraints that invalidate the choice after the funding is approved.