Dependency upgrades are the maintenance work most easily deferred, because nothing breaks when you skip them. The cost accrues invisibly and then arrives all at once, usually as a critical vulnerability in a library you cannot upgrade because it requires a framework version that requires a runtime version that breaks four other things. The urgent fix becomes a three-week project at the worst possible time.
The mechanism is compounding. Each version you fall behind adds a small migration, and the migrations interact. One minor version behind is an afternoon. Two years behind is a project with its own risk, and it is the state most teams discover themselves in when they finally look. The economics strongly favour small and frequent over large and occasional, which is unusual for maintenance work and is why automation matters here more than discipline.
Automate the mechanical part. Dependabot, Renovate or equivalent will open pull requests for updates continuously. Configure them to group patch and minor updates for development dependencies into one weekly pull request, and to raise major versions separately with their changelogs. If your test suite is trustworthy, most of these merge with a glance, and the ones that fail have told you something useful for free.
That does depend on the test suite being trustworthy, which is the honest catch. If your tests do not meaningfully cover the application, automated upgrades are automated risk, and the sensible order is to build enough coverage on the critical paths first. Teams without tests should still upgrade - just manually, on the paths that matter, with someone actually checking the behaviour.
Separate security updates from routine ones and treat them differently. A critical vulnerability in something you actually use should be assessed and shipped within days, not queued behind a monthly cadence. That requires knowing what you use: a dependency scan in the pipeline, and the discipline to check whether an advisory affects a code path you exercise, since many vulnerabilities are in features nobody calls and panicking about all of them equally is how the important ones get lost.
One habit reduces future pain more than any tooling: fewer dependencies. Every package added is a permanent maintenance obligation, an upgrade path to keep clear, and a supply-chain surface. A small utility library saving twenty lines of code is rarely worth that trade. The question worth asking at the point of adding one is not whether it works, but whether you would be willing to maintain it if it were abandoned - because sometimes you will have to.
