Legacy System Assessment
A structured evaluation of a system's business value, technical condition and risk, used to decide what to do with it rather than to describe it.
"Legacy" is not a technical property. A system is legacy when it resists change — when the cost or risk of modifying it exceeds what the business will accept. An old system that is stable, understood and rarely changed is not a problem; a three-year-old system nobody dares touch is.
What the assessment establishes, on evidence rather than reputation:
Business value — which capabilities it supports, how critical they are, how many users, what revenue depends on it.
Technical condition — technology support status, change lead time, change failure rate, incident frequency, test coverage, and the state of the build and deployment path.
Knowledge risk — how many people understand it, and whether documentation exists in any usable form. This is frequently the binding constraint and is rarely on the list.
Integration surface — what depends on it, discovered from evidence such as network flow logs and database audit rather than from documentation, which will be wrong.
Data — volume, quality, retention obligations, and what would have to happen to it in a migration.
Cost — licences, infrastructure and, critically, the engineering effort actually spent maintaining it.
The output is a disposition with a justification, not a report. The most common failure of these exercises is producing a thorough description that recommends nothing and is therefore acted on by nobody.