Two teams inherit the same 14-year-old order system. One calls it legacy because it runs on a framework three major versions out of support; the other because nobody can change it without breaking something elsewhere. Which single measurement best predicts what the next change will actually cost?

What is being tested

Whether you can tell a property of the code from a property of the system-plus-team. Modernisation budgets are spent on the second, and almost every assessment measures the first.

The mechanism

The cost of a change is the cost of making it, proving it, and recovering when it is wrong. Lead time measures the first two end to end: how long from a decision to that decision being live. Change failure rate measures the third: what share of changes needs a fix, a rollback or a hotfix.

Together they capture the things that actually generate cost and that no static measure sees - the manual regression pack that takes nine days, the one person who must review every change to the pricing module, the test environment that is shared by four teams and booked a fortnight ahead, the deploy that can only run on a Saturday. Those are the reason a two-line change costs six weeks, and none of them appear in a line count. The four metrics popularised by the DORA research programme and the 2018 book Accelerate (deployment frequency, lead time, change failure rate, time to restore) exist because this gap is measurable and predictive.

The measurement has to be taken on a representative change, not a trivial one. A text change on a static page is not evidence. Pick something that touches a core entity, a database column and an integration, and time it from decision to production.

Why the other options fail

• Framework age is the most common proxy and it is only an input. A well-tested application on an old framework can be changed in a day; an untested one on last month's framework cannot. Age tells you about security exposure and hiring, which are real problems with different fixes - an upgrade programme, not a re-architecture.
• Lines of code and complexity correlate with change cost weakly and are easy to game. A 2 million-line system with a strong test suite and clean module boundaries is cheaper to change than a 200,000-line one with none. Complexity metrics also point at the wrong places: the hottest files by churn matter far more than the most complex ones.
• Open defect count measures the backlog grooming culture at least as much as the system. Teams that triage aggressively show low counts; teams that never close anything show thousands. It says nothing about what the next change costs.

When this measurement is the wrong one

When the driver is not change cost at all. If the system is being replaced because the vendor ends support in 11 months, because it cannot meet a new regulatory obligation, or because the last three people who understand it retire this year, then lead time is irrelevant and the deadline is the whole argument. Measure what the decision turns on. A system that is cheap to change and structurally unable to meet a mandate is still a replacement.