Senior leaders tend to call us when an estimate comes back that they can’t quite believe, and can’t quite dismiss.
In this case, the estimate was 60 years.
The carrier is one of the leading US wireless providers. They had hundreds of millions of lines of Java code across roughly 600 repositories stuck on Java 8 or earlier. A handful were still on Java 7. The board and C-suite were pressing hard on the security exposure. Internal leadership had done the math honestly: 5,500 engineers, fully allocated, working on nothing else, would take roughly 60 years to bring the estate current.
That is the kind of number that stops a conversation. It is technically an answer. It is not an answer anyone can act on.
A principal architect inside the carrier reached out to us. He had worked with us before and knew we handle situations like this. The ask was simple: come in and help us figure out whether this actually has to take 60 years.
600+ Java 8 Repos · 5,500 Engineers Required · 60-year Internal Estimate
Why stalled modernizations produce numbers like this
The carrier’s estimate was not wrong. It was the honest result of multiplying the right variables: lines of code, average engineer throughput, typical manual upgrade overhead, regression risk, and the reality that the engineers who originally wrote the code are mostly not at the company anymore. Every assumption that went into the 60-year number was defensible.
What the number told us, and what it tells us every time we see one like it, is that the organization had been thinking about modernization as a labor problem. How many people do we need, for how long, doing what work. That framing produces estimates in decades because the labor cost of manual code modernization at enterprise scale has always produced estimates in decades. It is why most enterprise Java estates never actually get modernized. The number comes back, the board accepts that it cannot happen, and the codebase stays stuck until a security incident forces a partial retreat.
When we come into these situations, the first question we ask is not “how do we do this faster with the same approach.” It is “what changes if the approach itself is different.” That is the question the carrier’s internal team was not structurally positioned to ask. It is the question senior leaders bring us in to answer.
What we actually built
We split the engagement. Half the team on the orchestration platform the carrier had originally hired us for. Half on modernization. What we built was a production-grade pipeline that combines deterministic test generation, deterministic code transformation, and AI-assisted modernization into a single automated flow. We proved it end-to-end on the carrier’s single hardest case: a Spring Boot Java 8 repository approaching two million lines of code.
On that repo, on representative submodules, DiffBlue produced 82 percent test coverage out of the box. OpenRewrite handled the version upgrade. Our AI-assisted pass brought the code to current idioms. The DiffBlue tests caught a silent OpenRewrite transformation that would have changed Spring REST controllers from JSON to XML in production, which a human reviewer would likely have missed. The pipeline worked. The 60-year math collapsed. The pipeline itself is public on our GitHub.
The 60-year estimate was not wrong about the old way. It was just wrong about whether the old way was still the only way.
What actually stopped the work
We proved the pipeline. It was ready to scale across the full 600-repo estate. It never did.
The carrier had two corporate AI councils, each with a different SVP sponsor, each with organic buy-in from different parts of the business, and neither with authority over the other. Every decision that required both councils to agree, including scaling a new AI tool across production code, sat in deadlock. Getting even routine ChatGPT licenses against the carrier’s existing enterprise account took the better part of a year.
The technology worked. The math worked. The organization could not let the work scale at the speed the work could go.
This is the part of the story that matters most to senior leaders reading this. The carrier’s outcome was not a technology problem. It was an organizational readiness problem. We see a version of it in roughly half the Fortune 500 organizations we work with. The other half have made a deliberate early decision to concentrate AI authority in a named executive owner, and every subsequent decision flows through that single point. Those organizations can absorb modernization at the pace modernization is now capable of. The others cannot, regardless of what tooling they buy or what vendors they hire.
What we tell senior leaders who recognize their organization in this
We get this conversation often. A CTO or SVP reads a story like this and reaches out. The message is almost always the same: we have the same problem — where do we start?
1. The political problem is not solved by better tooling.
Buying the right vendor does not fix an AI governance deadlock. If your organization cannot currently say yes to a new AI tool in under a quarter, no modernization timeline we propose will survive contact with your approval process. The first work has to be clarifying who owns the decision. If the answer is “it’s complicated,” that is the problem to solve first.
2. Do not plan your way out of this. Ship your way out.
The big integrators will want to spend six weeks planning an architecture before any code is written. We do the opposite. We identify a high-value, manageable piece of the estate, run a one- to two-week sprint zero, and produce a working architectural pattern using your existing tooling. Time to value is the only metric that matters, because the pattern either earns organizational buy-in quickly or gets thrown away quickly. Long-horizon planning is how modernizations stay theoretical for decades.
3. Wrap quality before you change anything.
Most enterprises we walk into have 20 to 40 percent test coverage on the code they are trying to modernize. The bugs sit in the uncovered code, the business logic rationale is lost, and the team that built it is gone. You cannot safely modernize what you cannot prove still works. This is where deterministic test generation changes the economics. It is not about being faster. It is about making modernization actually shippable instead of theoretical.
4. Every year the estimate gets worse.
The carrier’s 60-year number was anchored in the tooling of the moment it was calculated. Every year since, the AI-assisted baseline has gotten faster and the manual baseline has stayed roughly flat. The gap is widening. Organizations that start modernizing now are working against tooling that continues to improve. Organizations that wait are accumulating technical debt faster than their estimates can keep up with.
Why we are telling this story
Sirrus7 specializes in modernization recovery. When senior leaders are staring at numbers like 60 years, we are the call. Not because we have a proprietary secret the rest of the industry does not. Because we have done this kind of work, at this kind of scale, enough times that we know which parts of the problem are solvable with the right approach and which parts need the organization itself to change first. That distinction is often the most valuable thing we bring to the conversation.
If you are staring at your own version of a 60-year estimate, or a program that has been running for 18 months without production impact, or a modernization effort that every quarter gets pushed out another quarter, we would like to talk to you. No slides. Just a conversation about what is actually blocking progress, and what a path forward could look like.