organizationL1 Ad-hocTech Debt & Modernization

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,

·Tech debt is growing with no systematic reduction plan
·Legacy systems are treated as "do not touch" zones

·Team acknowledges tech debt exists and can enumerate major items
·Migration backlog exists (even if years long with no progress)

Evidence

·Tech debt backlog with items older than 12 months and no progress
·Legacy system documentation (or lack thereof) showing avoidance patterns

What It Is

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.

Why It Matters

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

Getting Started

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.
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.
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.
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.
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.
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.

Tip

The most demoralizing thing about a multi-year backlog is that progress feels invisible. Keep a "completed migrations" log - a simple list of migrations that have been finished. Seeing the completed list grow is a more motivating signal than watching the remaining list shrink.

6 steps to get from here to the next level

Common Pitfalls

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.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's migration backlog is two pages long and grows by two or three items every quarter. He reviews it every year during roadmap planning, moves the top items to "planned" status, and watches them get pushed back to the following year as feature work consumes all available capacity. He knows this is unsustainable but has not found a way to make progress without blocking feature delivery.

Bob should separate the migration backlog problem into two questions. First, what can be done right now with existing capacity? The answer is: pick the one highest-urgency, lowest-complexity item and complete it this quarter, non-negotiably. Second, what would it take to address the backlog systematically? The answer involves AI agents at L3 - and Bob should be building the case now for the investment in reaching L3, using the migration backlog as the primary business justification. A multi-year migration backlog is a compelling argument for investing in automation.

SarahProductivity Lead

Sarah wants to measure developer productivity but struggles with baselines - every team's productivity is affected by its migration backlog, making cross-team comparisons misleading. The team with the most debt is not necessarily the least capable; they may be the most experienced team that inherited the oldest systems.

Sarah should add "migration backlog age and volume" as a context variable in her productivity metrics. Teams operating on outdated stacks should have their velocity measured in that context, with a separate metric for the cost of the backlog itself. She should also track "migrations completed per quarter" as a leading indicator of organizational health - this metric will show dramatic improvement when AI-assisted migration is introduced at L3, and the before/after comparison will be the clearest possible case study for the value of higher AI maturity.

VictorStaff Engineer - AI Champion

Victor has been on this team for four years and has watched the migration backlog grow. He has mentally estimated the effort required for each item and knows that the backlog represents approximately 18 months of dedicated engineering work if done manually. He also knows that most of the work is mechanical: updating import statements, replacing deprecated API calls, adjusting method signatures. It is exactly the kind of repetitive transformation that AI agents excel at.

Victor should build a proof of concept: take the smallest migration on the backlog - say, migrating from an internal logging library to the new standard - and run it through an AI agent with explicit instructions. The goal is not to complete the migration in production; it is to demonstrate that an agent can generate a migration PR that passes tests and requires only review, not manual coding. If successful, this proof of concept is the business case for L3 investment applied specifically to the migration backlog - and it will resonate with Bob more than any abstract argument about AI capability.