A year ago, if you asked me what a legacy modernization assessment should produce, I'd have described a thoughtful report outlining how to improve your legacy software. A narrative of the system, themes, recommendations. Today I'd tell you that kind of report is the wrong artifact. What leadership actually needs when they’re considering a legacy modernization initiative is a scored diagnosis: every finding rated on how bad it is and what kind of problem it is.
That shift, from narrative to legacy modernization diagnosis, is the biggest change in how I'd run the first 30 days of a modernization in 2026. It's not the only one. AI has compressed parts of legacy discovery that used to run in sequence, and it's changed the math on legacy software rewrites. But the move from "here's the story of the system" to "here's what's red and here's the intervention that makes sense for your situation" is what separates a useful first month from a readable one.
The first 30 days of a legacy initiative starts before day one
The most useful thing I can tell a leader about to kick off a legacy software modernization initiative: what you get out of the first 30 days depends almost entirely on what you set up before it starts. This includes:
- Goals documented somewhere other than in someone's head
- Direct access to legacy code and key systems
- KPIs leadership will actually measure the effort against
- Product analytics, or access to a read-only snapshot of production data
- Application performance metrics (APM)
- Org chart
- Any prior assessments
- Calendar access to the engineers and product people who carry context
- Agreement from your execs that their time is part of the deal
None of that is glamorous, but this is where projects quietly go off track early when it's missing. If you show up on day one still negotiating access to the people who know things, the clock has effectively already run.
Documented goals for your legacy rescue initiative are the easiest to underappreciate. Identifying and documenting specific business outcomes you’re trying to drive is the most important item on this list because it shapes every other decision. Legacy modernization efforts typically begin when users, engineers, and/or business owners start experiencing friction. But it’s crucial to be direct about the desired business outcomes. Just naming that friction is insufficient. Knowing how to measure success informs how to approach the work:
- Are you hoping to reduce churn or enter new markets?
- Do you need to reduce costs or accelerate delivery?
- Are you running from something like a platform/framework that will no longer be supported or are you sprinting to new technologies that better enable new capabilities like agentic workflows?
Answering those and similar questions has never been unimportant, but I’ve come to realize that strategic product thinking is just as crucial with legacy modernization as it is with greenfield development.
Early legacy codebase and team discovery happens in parallel
The earliest part of discovery runs on two tracks: talking to people and exploring the legacy software system through the code. Both have always been part of getting acclimated with a legacy codebase. What has changed is that code discovery can go much faster and deeper than before. An experienced engineer can review what the AI produces and walk into stakeholder conversations with real context, not just questions.
But more can be learned from the people who lived with the system than from the system itself. Talk to the engineers who built the software. Talk to the product managers who've been asking for features they never got. Talk to the executive sponsor who approved the budget to modernize the legacy software. Talk to end users and front line support people who can speak to the frustration the legacy system generates. Ask each of them what they think the problem is. They won't agree, but the gaps between their answers are some of the most useful data you'll get. To paraphrase Gerald Weinberg: software problems are people problems.
The code track is where AI changed things the most. Frontier models got meaningfully better over the last year at generating code and at producing useful analysis.
What that means on the ground is this:
- You can review thousands of files in a day
- Dependency maps that used to take somebody two days are easily generated
- Characterization tests can be captured systematically instead of opportunistically
- Inconsistent patterns and suboptimal practices are much easier to spot
- Security vulnerabilities or out-of-date package versions can be identified much more rapidly
These two tracks, the code and the conversations, feed each other. Something a product manager tells you about how billing has broken in the past becomes a specific question you hand to the agent. A dependency pattern the agent surfaces becomes a question for whoever built it. Running the tracks in parallel, with information flowing between them, is what makes the compressed timeline work.
Legacy codebase and team findings are scored, not narrated
Of everything in the first 30 days of a legacy modernization initiative, this is where my approach has shifted most over the last year.
The temptation at the end of discovery is to write a report. A narrative. Here's what we found, here's the story of the system, here are some themes. These reports are typically readable and often thoughtful. Unfortunately, they’re far too often insufficient if not useless for making decisions.
A better output: every finding gets two evaluations. How bad it is, and what kind of problem it is.
"How bad" is a severity judgment: red, yellow, green.
- Is this actively blocking the business?
- Creating compounding friction that will bite later?
- Functional for now?
"What kind of problem" is the more useful question, and it's the one I'd push every leader to force into the conversation.
- Is this something the team will resolve on its own?
- Something they could resolve but don't have the bandwidth for?
- Something they can't resolve without new skills, tools, or structures they don't currently have?
Capacity gaps and capability gaps look similar from the outside. The interventions are completely different. Misdiagnosing one for the other wastes whatever investment follows.
Scoring every finding this way forces the diagnosis to be specific enough to act on. It also gives the leadership conversation a structure that isn't "how bad is everything." It's "here's what's red, here's what kind of problem each red item is, and here's the intervention that matches."
The legacy rewrite decision has changed
At some point, every legacy modernization arrives at some version of the legacy rewrite-versus-refactor question. This is one where the capabilities of the new technology have swayed my view.
For the better part of two decades the conventional wisdom, well-earned, was don't do the big rewrite. Use the Strangler Fig pattern where you replace incrementally while the old system keeps running. The rationale was straightforward. Long rewrites compound risk, people leave, knowledge drifts, the old system changes while you're rebuilding it, organizational momentum fades, and the project quietly dies.
Every one of those risks weakens when AI compresses the writing, testing, and validation work. Shorter rewrite windows mean less knowledge drift, less team turnover, and less time for the old system to mutate underneath you. That's not just cheaper, it's an entirely different risk profile.
I'm not saying rewrites should now be the default. They shouldn't. Incremental replacement is still the right call most of the time. But the cases where a rewrite is credible are more numerous than they were a year ago. That means the decision framework needs an extra dimension now. “Can AI compress this enough to change the risk equation?” is a real question, not a hypothetical.
What you should have a month into a legacy software initiative
Once you are about 30 days into a legacy modernization effort, you should have a scored picture of the system across the things that actually matter:
- The platform itself
- The team's ability to ship
- The organization's ability to absorb change
- The system's effect on the customers it serves
You would also expect to have a set of artifacts that make the path forward clear:
- A short stack of recommendation briefs, each naming a specific problem, its severity, what kind of problem it is, and what to do about it
- A sequenced roadmap that turns those recommendations into a plan
- A business case that names the cost of doing this and the cost of not
- Prototypes and experiments that address the highest sources of risk
That's illustrative, not universal. Not every engagement lands in exactly this shape. But something in that neighborhood is what a serious first 30 days should produce. If what you have at the end is a narrative report and a “we recommend further investigation”, something went wrong earlier.
What AI doesn't change for legacy modernization
There are some questions where the insights AI can give are still far behind what humans can provide. Understanding why the last legacy modernization initiative didn't land. Reading the politics between engineering and product. Earning trust from a team that's been burned before. Translating the technical picture into language a board will act on. None of that is getting automated any time soon.
The best artifact I've seen come out of a first 30 days wasn't a technical report. It was a decision framework that gave a CIO the language to go to their board and ask for the commitment they needed. That came from the human work. We worked together to understand the business first. We translated the technical findings into language that spoke to the executive's needs. That earned trust. AI made the analysis faster and the artifacts sharper. It didn't shape the framework that came from paying attention to what the CIO actually needed to say.
What changed, and what didn’t
AI is having a profound impact on our industry. This is just as true for legacy modernization as it is for greenfield app development. But the fundamentals haven't changed. You still start with people. You still map reality instead of wishes. You still score what you find, decide what to do, and earn the right to recommend a path. The human and organizational work that decides whether a modernization succeeds or fails is the same work it's always been.
What's different is the range of options available once you've done that work. AI widens what's technically possible. More paths are viable and timelines are compressed. Execution models that weren't realistic a year ago are on the table now.
More options ask for better judgment. An engineering leader walking into the first months of a modernization in 2026 has more power at their disposal than ever before, and more ways to spend it on the wrong approach. AI amplifies good process and accelerates bad decisions in equal measure. The first 30 days are where you set up for the former.
The legacy software playbook got rewritten. The principles behind it didn't.
Mike Doel is an Engagement Partner at Test Double, where he leads legacy modernization engagements for enterprise clients. If your organization is facing a legacy modernization decision, we'd love to talk.
