Before modernising, a team must assess a legacy system. What should the assessment measure, and what is usually skipped?

What the assessment should measure

1. What it actually does, by usage. Which functions are exercised, how often, by whom. A large proportion of legacy functionality is typically unused, and measuring that before planning is the single largest scope reduction available — you do not migrate what nobody uses.

2. Who depends on it, derived from traffic and query logs rather than from self-declaration. Most fear of changing a legacy system is fear of unknown consumers, which is an information problem with a technical solution.

3. Where the business rules live, and whether they are recoverable. Rules in code are recoverable; rules in stored procedures, in configuration tables, in batch job sequencing, or in the heads of two people are progressively harder — and the last case is a schedule risk, not a technical one.

4. Data ownership and quality. Which entities this system is authoritative for, what state that data is in, and what other systems have diverged from it.

5. Change and incident history. Which parts change often, which parts break often. High-change areas are where modernisation returns most; stable areas may not need touching at all.

6. Operational cost, including licences, contractors, infrastructure and the engineering time consumed by workarounds.

What is usually skipped

Behaviour under edge conditions. The assessment documents the happy path and the intended rules, and misses the accumulated handling of real-world exceptions — the special case for one large customer, the rounding rule for one currency, the retry that exists because a partner's system was unreliable in 2014.

These are invisible in documentation, present in the code, and load-bearing. The only reliable way to find them is to run real traffic against both systems and compare, which is why traffic shadowing belongs in the assessment phase rather than in the migration phase.

The other common omission is what the system is not required to do. Explicitly bounding scope early is what prevents the second-system effect later.

The output that matters

Not a document describing the system. A prioritised set of slices, each with its usage, its consumers, its data ownership, its business sponsor and its estimated difficulty — which is what makes an incremental programme plannable rather than a rebuild.