Renovate and Dependabot solve the easy 80% of dependency management: they open the PR. What they don't solve is the hard 20%, the major version bumps with breaking changes, deprecated APIs, and migration guides that need an engineer to actually read the changelog and update calling code. That's the backlog that piles up in most repos: dozens of open Renovate PRs, most of them minor and safe to auto-merge, a stubborn handful sitting there for months because nobody wants to spend a day on a major-version migration. Every single one of those PRs sitting open and unreviewed is also a small, compounding security and compatibility risk, since the longer a major upgrade waits, the further behind the codebase drifts from what the rest of the ecosystem is testing against.
Why the backlog specifically stalls on major versions
Minor and patch bumps are usually safe enough to auto-merge on a passing test suite, and most teams already do that. Major version bumps are different: they often require code changes, not just a version number update, and the tests passing doesn't guarantee the migration was done correctly if the breaking change is in an area your test suite doesn't cover well. That uncertainty is exactly why these PRs sit open, because reviewing them properly takes real engineering time that's easy to deprioritise against feature work.
Read the changelog or migration guide for the version jump, not just the diff
Identify every call site in your codebase that touches the changed API
Propose the code changes needed to match the new API, with test coverage checked against each change
Flag anything genuinely ambiguous (behaviour changes without a clear migration path) for a human decision
How this works day to day
The pattern that works is treating each major-version Renovate PR as a task handed to Claude Code rather than a PR reviewed cold: point it at the PR branch, the changelog URL, and the affected files, and ask it to make the migration changes and run the test suite. It's not going to get every migration right unattended, particularly ones involving genuine behaviour changes rather than just renamed APIs, but it clears the mechanical rewrite work fast enough that an engineer's review time drops from a full day to about an hour of sanity-checking.
A Sydney logtech company had 34 open major-version Renovate PRs sitting untouched for an average of 95 days, several of them security-relevant. Running this pattern across a two-week sprint cleared 27 of the 34, with the remaining 7 flagged as needing genuine architectural decisions the team scheduled separately for the following sprint rather than rushed through unattended. They estimated the accumulated backlog had been carrying real security exposure, and put the risk-adjusted value of clearing it at conservatively $15,000 in avoided incident response cost, based on their own prior experience with an unpatched dependency vulnerability that had cost them a weekend of emergency patching the previous year.
Prioritising which PRs to tackle first
Not every stale major-version PR deserves the same urgency. The sensible triage order is security-relevant updates first (anything with a known CVE against the current pinned version), then dependencies close to end-of-life support, then everything else by how many other packages depend on the one being upgraded. Working through 34 PRs in whatever order they happened to open wastes the sprint on low-risk upgrades while the genuinely urgent ones wait their turn. A simple scoring pass before the sprint starts, even just a spreadsheet ranking each PR on those three factors, pays for itself many times over against just working top-to-bottom through whatever Renovate opened first. It also gives the team a defensible answer when someone asks why a particular upgrade got prioritised over another, which matters when the sprint's being reviewed after the fact.
Guardrails worth keeping
Never let this auto-merge a major version bump without a human review, even if the tests pass. Test coverage gaps are exactly where major-version breakage tends to hide, and a green test suite on a major bump is reassuring rather than conclusive. And budget real review time even for the migrations Claude Code handles cleanly, because a rubber-stamped review defeats the purpose of having one. The whole point of clearing a backlog like this is doing it safely enough that it doesn't just reopen as a fresh backlog of poorly-reviewed merges six months later.
Automata AI sets up this dependency-upgrade workflow for Australian engineering teams carrying a Renovate backlog. If your major-version PRs are stacking up faster than anyone's clearing them, /contact us for a scoped look.
