Fund update debt first when it blocks you from shipping a security fix, pushes a runtime past end of life, or makes every feature slower to build. Fund feature work first when the dependency gap is small and supported. The test is not which is bigger. It is which one limits your ability to respond.
Two kinds of debt
Feature debt is work customers asked for that you have not built. Update debt is the gap between the versions you run and the versions you could run. Feature debt is visible on a roadmap. Update debt is invisible until something forces it into view, which is why it loses most planning arguments.
A four question test
- Can we ship a security fix within days? If the honest answer is no because upgrades must come first, update debt is a response problem.
- Is anything past end of life? Python publishes an end of life date for each release, and Node.js lists release statuses including end of life. A runtime past its date will not receive fixes.
- Is the upgrade gap crossing majors? Each major is a separate project with breaking changes under semantic versioning.
- Is it slowing feature work now? If engineers keep working around old APIs, you are paying interest already.
Two or more yes answers usually mean the update work should go first, or at least run in parallel with a protected slice of capacity.
What to do when both compete
| Condition | Suggested split |
|---|---|
| Small gaps, all supported | Mostly features, steady small updates |
| One major behind on a core framework | Schedule it as a roadmap item with an owner |
| Runtime near end of life | Treat as a deadline, not a preference |
| Known exploited vulnerability unpatched | Interrupt everything and fix |
| Everything a year behind | Protect a fixed share of each sprint until the lag falls |
Make the trade explicit
Leaders often choose features by default because the trade is never shown. Put both on one page: the feature, the customer impact, and next to it the update item with its exposure in days and the number of majors involved. When the cost of waiting is stated plainly, decisions improve.
Do not make it all or nothing
A common failure is the "upgrade quarter" that freezes features, runs over, and teaches the organization never to do it again. Smaller, regular slices work better. They also keep engineers familiar with how the dependencies behave, which cuts the fear that causes delay.
What to measure
- Days since the oldest runtime release you run.
- Count of open advisories that have a fix available.
- Time from advisory to merged fix.
- Majors behind on core frameworks.
Reporting these four numbers monthly turns the argument from opinion into trend.
Safeguard's SBOM and dependency scanning lists direct and transitive packages with their versions, and reachability analysis shows which outdated or vulnerable ones your code actually calls. Autonomous remediation can open fix pull requests; it is off by default and every category starts on Manual. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is update debt the same as technical debt?
It is one kind of technical debt, with the difference that it has outside deadlines, such as vendor support dates and new advisories.
What if the board wants features only?
Show the exposure window and the support dates next to the feature list. A dated external deadline is easier to defend than a general plea for cleanup.
Sources
- Status of Python versions
- Node.js releases
- Semantic Versioning 2.0.0
- CISA Known Exploited Vulnerabilities Catalog
Last reviewed: 19 October 2026.
