Not every deprecation deserves the same urgency

Situation

Modernization work can generate a long list of deprecation messages from static analysis and runtime logs. The list is visually compelling, so it is tempting to turn the remaining count into a KPI. But a rarely executed admin helper and a service touched on every request do not represent the same risk.

Approach

I grouped items by execution frequency, approaching hard break, custom-code ownership and the impact of the fix. Mechanical replacements were separated from API migrations that required design work. Where a contrib module was expected to receive the upstream change, I avoided duplicating the same work in a local patch without a clear need.

Outcome

The upgrade backlog became smaller, but more importantly it became meaningful. The team removed deprecations that could actually stop the next core or PHP step first. The rest stayed documented as known debt instead of being mixed with true blockers.