Articles

Blog section illustration

AI vs. Consulting for Legacy Modernization: An Honest CTO's Guide

Author img

By Claus Villumsen

17 April, 2026

Share this article

Legacy Modernization AI Strategy 11 min read    April 2026

You have a 15-year-old system holding your business hostage. Someone suggests bringing in a consulting firm. Someone else mentions AI. And you sit there wondering — which one will actually fix this, and which one will just cost you a fortune and leave you exactly where you started.

Let me be honest with you. I have been on both sides of this decision. I have signed the consulting contracts. Big ones. The kind where a partner flies in on Monday and the invoice arrives before the first deliverable does. I have also bet on AI tooling. Watched it hallucinate business logic that took three senior engineers six months to reconstruct. I have made expensive mistakes in both directions.

And I have also — eventually — gotten it right. Not because I found a magic vendor. Because I finally understood what each approach is actually good at, and stopped expecting either one to do the other's job.

This piece is for CTOs and engineering leaders wrestling with that exact question right now. Not the vendor-pitched version. The version you need before you walk into that board meeting and commit $2 million to a path you can't easily reverse.

I. The Consulting Firm's Actual Value Proposition

Here is what a good consulting firm genuinely brings: people who have done this exact thing before, in your exact industry, with your exact stack. Not AI. Not automation. Humans with scar tissue.

When your system has 400,000 lines of undocumented COBOL, and the three people who understood it retired in 2019, and your business logic is embedded in ways that violate every principle you learned in university — a senior consultant who has untangled exactly this kind of mess before is genuinely valuable. They bring judgment. They bring architectural intuition. They bring a playbook.

They also bring something subtler: organizational legitimacy. When a VP of Engineering tells the board "we hired McKinsey" or "Accenture is leading this," the risk perception in the room changes. That is not cynicism. That is how large organizations manage change. The consulting brand is part of the product.

But pause here for a moment. Ask yourself honestly — when was the last time you saw a large consulting engagement deliver what was promised, on time, at the quoted price? Not the sanitized case study version. The real version, with the change requests and the scope creep and the eighteen months that became thirty-six.

Did we do the right thing? Why did it take so long? What did we actually get for $8 million?

◯ Pause & reflect

The consulting model has a structural problem: it is optimized for billing hours, not delivering outcomes. By late 2025, clients were starting to revolt. A watershed moment came when Zimmer Biomet sued Deloitte for $172 million over a failed software implementation. That is not an outlier. That is the tip of a very large iceberg that most enterprises are too embarrassed to talk about publicly.

II. What AI Tooling Actually Does Well

AI-assisted modernization is not magic. It is also not hype, anymore. In 2026, agentic platforms that autonomously analyze, refactor, and generate tests have moved from research demonstrations into production. The economics have genuinely shifted. Programs that required 24 months and $10 million delivered manually can now be completed in 14 months and $4 million with properly governed AI-native delivery.

That is not marketing. That is structural. AI compresses the mechanical parts of modernization — the parts that are slow not because they are hard, but because humans are slow at pattern matching across millions of lines of code. AI is not slow at that. It is tireless, consistent, and it does not quit on a Friday afternoon because it has a flight to catch.

AI-assisted tools excel at four specific things. First, discovery at scale — mapping dependencies, identifying dead code, extracting undocumented business rules from systems that were never properly documented in the first place. Second, mechanical refactoring — the kind of repetitive, pattern-based transformation that takes a human engineer three months and takes a well-configured AI agent three days. Third, test generation — characterization tests that capture existing behavior, so you know when something breaks. Fourth, documentation — turning tribal knowledge trapped in code into something a new engineer can actually read.

Notice what is not on that list. Architectural judgment. Change management. Stakeholder alignment. Understanding why a piece of business logic exists, not just what it does. Those are human problems. AI does not solve them.

But here is the question that matters: is there a better solution where AI and humans grow together, each doing what they are actually best at?

◯ Pause & reflect

III. The Real Comparison: What Each Approach Costs You

Let us stop talking in abstractions and look at what these decisions actually cost — not the sticker price, but the full cost.

The traditional consulting route: A mid-sized enterprise modernization with a tier-one SI typically runs 18 to 36 months and $5 million to $25 million depending on scope. The first six months are discovery. The next six are architecture and planning. You are twelve months in and nothing in production has changed. Your engineers are frustrated because they are attending workshops instead of building. Your legacy system is accumulating another year of technical debt while you wait. And the consultants — who are excellent, genuinely — rotate. The person who understood your system deepest gets moved to another engagement in month eight.

The pure AI tooling route: Fast. Cheap. And frequently disastrous when applied without governance. The danger of AI-only application modernization services is not that the AI writes bad code — it usually writes reasonable code. The danger is that it writes reasonable code that solves the wrong problem. Without someone who understands the domain, AI will faithfully refactor a piece of logic that should have been deleted. It will modernize a system and preserve a bug that turns out to be load-bearing. It optimizes the letter of the code and misses the spirit of the business.

The hybrid approach — AI automation paired with expert oversight — is where the math actually works. AI handles the mechanical volume. Humans handle judgment, domain knowledge, and governance. The result is the speed advantage of AI tooling without the risk of AI running unsupervised over your mission-critical systems.

"70% of mechanical refactors automated. 30% high-judgment design and review. That is not a number from a brochure. That is the ratio that makes the economics work while keeping humans in control of what actually matters."

IV. The Strangler Fig Still Works — AI Just Makes It Faster

The best pattern for modernizing large legacy systems has not changed. Martin Fowler described it two decades ago — the strangler fig. Build new behavior alongside the old system. Route traffic incrementally. Let the old system wither as the new one grows. Never do a big-bang rewrite. Never put all your risk on a single cutover date.

What has changed is how fast you can execute this pattern. The discovery phase — mapping the old system, identifying seams, understanding dependencies — used to take six months of senior engineer time. With AI-assisted portfolio analysis, you can do it in weeks. The pattern is the same. The timeline is different.

This is where engineering-led organizations have a genuine edge over those who outsource everything. When your own team is in control of the AI tooling — when they are the ones reviewing the diffs, approving the refactors, running the characterization tests — they build understanding as they go. The knowledge transfer is not a separate workstream that happens at the end of the engagement. It happens continuously, with every pull request.

Outsource the whole thing and you get a transformed codebase you do not fully understand. That is tomorrow's legacy problem. You have just deferred it by five years.

What should we have tried earlier? What would have happened if we had started with the strangler fig and AI-assisted discovery instead of the big consulting engagement?

◯ Pause & reflect

V. The Safety Question Is the Right Question

The number one concern CTOs raise about AI-assisted modernization is not speed and it is not cost. It is safety. What happens when the AI gets it wrong? How do I know what changed? How do I roll back? How do I explain to my regulator what the AI did to my codebase?

These are exactly the right questions. And the fact that they are being asked so consistently tells you something important: the market has moved past "can AI do this" and landed on "can I trust it enough to bet my business on it." That is a healthy place to be.

The answer is not "trust the AI." The answer is don't trust anything you cannot see, audit, and reverse. Every code change should produce a diff. Every transformation should have a change log. Every refactor should run against characterization tests that capture the existing behavior before the first line is touched. Shadow runs. Canary rollouts. The same governance disciplines that good engineering teams apply to their own code.

As InfoQ has documented extensively, the teams that succeed with AI-assisted legacy system modernization are not the ones with the most advanced AI tools. They are the ones with the strongest engineering governance around those tools.

AI is faster than consulting. But the best AI-driven modernization programs are more disciplined than the best consulting programs. That discipline is the moat. That is what separates a successful modernization from a faster way to make a bigger mess.

VI. What Genuinely Changes When AI Matures Further

We are not at the end of this curve. We are somewhere in the middle of it. The AI tools available in 2026 are genuinely good. The ones that will be available in 2028 will make today's look primitive. That means the decisions you make now about how to build your AI-governance muscle — how to structure your team to work alongside AI, how to build internal expertise in this tooling — will compound.

The organizations that outsource AI modernization entirely are not just paying for a transformation. They are paying to not learn how to do it themselves. And as the AI gets better, that becomes an increasingly expensive form of ignorance.

The future that is already visible: AI does the analysis. AI proposes the refactor. A human engineer reviews the diff, approves the change, and owns the outcome. Not because the AI cannot be trusted, but because the human review loop is what catches the 3% of cases where the AI misunderstood the intent — and in production systems, that 3% is everything.

Where are the limits? Regulatory compliance in highly controlled industries still requires human architects who can sign their name next to a decision. Organizational change management — getting 400 engineers to adopt new patterns — is still a human problem. The cultural side of modernization: AI cannot fix a team that does not believe the modernization is worth doing.

Is there a better future where AI and good engineering grow together? Yes. But only if we stop treating AI as a replacement and start treating it as the most powerful junior engineer who ever existed — one who needs good oversight, clear direction, and a senior engineer willing to review the work.

◯ Pause & reflect

VII. The Decision Framework: How to Actually Choose

Use a consulting firm when: Your codebase is genuinely unknown territory with no internal expertise. You are in a regulated industry where the consultant's brand provides meaningful risk cover with your board or regulator. You have a specific, bounded problem with a clear definition of done. You are willing to pay a premium for speed-to-start and don't have time to build internal AI capabilities first.

Use AI-assisted tooling when: You have a large, high-entropy codebase where the bottleneck is volume, not judgment. Your team has the engineering maturity to govern AI output — to review diffs, run tests, own the outcome. You want the knowledge to stay inside your organization, not walk out the door with the consultants. You are willing to invest in the governance discipline that makes AI safe.

Use both, sequenced correctly: Bring in consultants for the strategic assessment and architectural decisions. Use AI tooling for the execution. Let your own team own the tooling so they build expertise as they go. This is how the economics of modern application modernization services actually work when they are done well.

One thing the data is unambiguous about: pure consulting without AI tooling is getting slower and more expensive relative to alternatives every quarter. The consulting firms know this. The smart ones are building AI platforms of their own. The ones that are not are going to face exactly the pressure that every industry faces when a cheaper, faster alternative enters the market.

The Bottom Line

The question is not "AI or consulting." That is a false binary, and anyone trying to sell you on one side of it has something to gain from your confusion.

The real question is: what does your specific problem actually need? Volume of mechanical transformation? AI wins. Architectural judgment and domain expertise? Experienced humans win. Speed with safety, at scale, with your team building the capability as they go? A hybrid model where AI does the heavy lifting and humans govern the outcome wins.

The worst outcome is not choosing wrong between these two. The worst outcome is spending 18 months on a consulting engagement that transforms your code but not your organization, and leaving you exactly as dependent on external help as you were before.

Your legacy system is not your problem. Your approach to modernizing it is. Get that right, and the tools — whether AI or human — will follow.

Book a discovery call here

Loading
Loading
Loading

Claus Villumsen

Software development

Related articles

Blog section illustration

Cross-Platform Development

AI

We Use GitHub Copilot Every Day. Here's Why We Don't Use It to Modernize Legacy Code.
Every developer on our team has GitHub Copilot open. We use it every day. But when we pointed it at a 750,000-line VBA codebase from 1998, it was confident, fast, and wrong in ways that were hard to spot. Here is what we learned.
Author img
By  Claus Villumsen
30 April, 2026
Blog section illustration

AI

Gartner Wants Intelligent Applications. Here Is How Legacy Systems Get There.

Gartner published a clear message in 2025. Legacy applications cannot support AI capabilities without transformation. Here is what that actually means and how you close the gap without a big-bang rewrite.

Author img
By  Claus Villumsen
30 October, 2025
Blog section illustration

Work

How We Built Four AI Agents to Convert Legacy HTML Into a Strapi CMS

We had a mountain of legacy HTML that needed to become structured Strapi CMS content. Manual conversion would have taken months. We built four AI agents to do it instead. Here is how they work.

Author img
By  Claus Villumsen
01 May, 2025
Loading

AI + Human software Solution

Follow us
Loading

© 2026 Kodebaze. All Rights Reserved.