Migration backlog: years

A migration backlog measured in years is the state where an organization's known modernization work - framework upgrades, language version migrations, deprecated API replacements, library consolidations - has accumulated to the point where, at current capacity and velocity, it would take multiple years to complete. In practice, a multi-year migration backlog is a backlog that will never be completed by human effort alone, because new items are added faster than old ones are addressed.

This state is extremely common at L1. Organizations that have been operating for more than a few years almost always have a list of migrations that have been "planned" or "on the roadmap" for years without making meaningful progress. Java 8 to a current LTS version. AngularJS to a modern framework. A deprecated internal authentication library to the new standard. Spring Boot 2 to Spring Boot 3. Each of these migrations was placed on the roadmap when the end-of-life announcement was made, assigned to a future quarter, and then pushed back as feature priorities dominated every planning cycle.

The backlog creates compounding problems. Each year a migration is deferred, the gap between current and target increases. A Java 8 to Java 17 migration is harder than a Java 8 to Java 11 migration would have been, which was harder than staying current would have been. Deferred migrations also block other work: you cannot adopt a library that requires Java 17 until the Java migration is complete, which means the migration backlog is also a feature capability backlog.

At L1, organizations often respond to the size of the backlog with paralysis: the list is so long that prioritizing it feels arbitrary and starting feels futile. This paralysis is the primary reason backlogs grow rather than shrink. The shift from L1 to L2 is not primarily about velocity - it is about replacing paralysis with a systematic approach to prioritization and incremental progress.

• Security exposure - Unmigrated frameworks and libraries accumulate CVEs; a multi-year migration backlog means years of known vulnerabilities that cannot be patched without completing migrations that are themselves years away
• Talent acquisition friction - Developers interviewing at organizations with years-old migration backlogs ask "why are you still on Java 8?" and interpret the answer as a signal about organizational dysfunction and developer experience
• Feature capability gap - Modern libraries, frameworks, and language features that would accelerate development cannot be adopted until blocking migrations are complete; the backlog is a ceiling on technical capability
• Vendor support risk - Software running on end-of-life versions loses vendor support; when something breaks, there is no fix coming, and the organization must choose between emergency migration and permanent workaround
• AI agent leverage - The migration backlog is one of the highest-leverage areas for AI agents at L3 and above; organizations that understand this have a strong incentive to get to L3, and understanding the current backlog depth is the first step

1. Create a complete migration inventory - List every known migration that should be done: language versions, framework versions, deprecated library replacements, infrastructure upgrades. Do not filter by feasibility - capture everything. The goal is to see the full scope.
2. Estimate the age of each item - For each migration, note when it was first identified or when the end-of-life announcement was made. This shows the rate of backlog growth and the longest-deferred items.
3. Score by urgency, not complexity - Prioritize items with active security implications, active end-of-life status, or items that are blocking other work. A complex but low-urgency migration should not crowd out a simple high-urgency one.
4. Pick one migration to complete this quarter - Select the smallest, highest-urgency item on the list and commit to completing it this quarter. Not starting it - completing it. One completed migration demonstrates that the backlog is tractable and builds confidence for the next one.
5. Establish a "stay current" policy for new work - New projects should use current versions. New dependencies should be current. This stops the backlog from growing while the existing items are addressed.
6. Calculate the "AI-assisted velocity estimate" - For each major migration, research whether OpenRewrite recipes or AI agents can automate the mechanical parts of the migration. This estimate is not actionable at L1 but informs the business case for investing in higher maturity levels.

Treating the entire backlog as one project. A multi-year migration backlog is not one project - it is dozens of independent items that can be prioritized, sequenced, and executed separately. Treating it as a single monolithic effort is the fastest path to analysis paralysis.

Estimating the backlog in human-hours without considering AI acceleration. At L1, the backlog is estimated based on manual migration effort. At L3 and above, the same migrations can be 5-10x faster with AI agents. An organization that understands this should not be making long-term roadmap decisions based on human-only velocity estimates.

Deferring migrations until "after the feature rush." The feature rush never ends. Migrations that are perpetually deferred to after-the-rush never happen. The only migrations that get done are the ones that are explicitly scheduled and protected from displacement.

Starting multiple migrations simultaneously. Organizations that try to execute five migrations in parallel typically complete zero of them within the planned timeline. Migrations require sustained attention to the unexpected edge cases that emerge mid-execution. Focus on one at a time.

Ignoring the cost of staying on end-of-life versions. The risk of running on an end-of-life version is not theoretical - it is the cost of the next security incident that could have been prevented. Organizations that ignore end-of-life risk until an incident occurs pay far more than organizations that migrated proactively.