Large enterprises are actually stuck in the same place for a very long time. Their important applications run on aging technology, but the business keeps asking for faster releases, better security, and quicker reactions to whatever the market does next. Modernization programs are supposed to fix this. In practice, they tend to run from months into years, which is often long enough that the technology has moved on again before the work is done. Debt piles up in the meantime. Maintenance gets more expensive. The gap everyone set out to close stays roughly where it was.
Artificial Intelligence was going to change all this. So far, giving developers an AI coding assistant has mostly made the existing project-by-project work go faster, which helps but doesn’t really alter the shape of the problem. The shift worth paying attention to is a different one. It moves the conversation from refactoring a single codebase toward re-platforming at scale, pointing AI at the modernization process itself and treating it as something repeatable, rather than at individual coding tasks one at a time.
Where the time actually goes
The work that eats up engineering teams is rarely the work anyone would point to as valuable. Most of it falls into a handful of recurring buckets:
- Reading legacy code nobody on the current team wrote
- Updating frameworks and libraries that have fallen out of date
- Maintaining documentation that goes stale almost immediately
- Enforcing security standards by hand, application by application
- Migrating workloads from one platform to another
A large enterprise might be running a few hundred applications, so all of that gets multiplied until the cost stops being incidental and becomes part of the structure.
Recurring, non-differentiating work consumes a large share of engineering effort.
You can see the results without looking hard. Onboarding drags because too much of what matters lives in people’s heads instead of anywhere you can read it. Teams lean on the two or three engineers who happen to remember how a given system behaves. Security fixes arrive late, because just finding every affected application turns into its own project. And the modernization that was meant to relieve some of this keeps getting pushed to next quarter.
Why manual refactoring runs out of road
The usual answer is refactoring. A team studies the system, redesigns the parts that need it, rewrites the code, checks that nothing broke, and ships in stages. It works. It’s also slow, costs a lot, and depends heavily on who’s doing it. If one engineer understands the legacy payments integration, that engineer becomes the bottleneck for modernizing it, and there isn’t much to be done about that.
The real trouble starts when the same transformation has to happen again and again. Migrating off one framework onto another. Updating how security is implemented. Standardizing deployment pipelines. Adopting some new architectural pattern across the board. Each time, engineers end up solving a problem they’ve already solved, just sitting in a different repository. The knowledge is there. It just can’t be picked up and reused.
So a better question than “how do we fix this application” turns out to be: can we define a transformation that fixes all of them?
What transformation-driven AI actually means
The idea is to stop generating code snippets and start defining transformations that can run repeatedly. Instead of re-platforming a system by hand, one project after another, an organization writes the rules down once. Architecture standards, coding conventions, security requirements, the mapping from old technology to new, what counts as a successful result. Then AI applies those rules across the whole portfolio.
Instead of fixing each application separately, a single recipe is applied across all of them.
What you’ve written becomes a reusable recipe. The expertise that used to sit in one senior engineer’s head turns into something the rest of the organization can run against. That’s the part that changes the economics. Modernization stops being a string of separate projects and starts behaving more like infrastructure you can rely on.
A few examples make the pattern concrete.
Take an organization re-platforming its integrations off MuleSoft and onto .NET services. By hand, every integration gets its own analysis, its own implementation, its own round of testing. As a transformation, the team defines the technology mappings, the target architecture, the logging conventions, and the service boundaries one time, then runs that across every integration. The consistency alone is hard to get any other way, because hand-migration always drifts a little from one engineer to the next.
Documentation is another. Legacy systems are famous for documentation that’s either missing or years out of date, and nobody wants to spend a quarter writing it. AI transformations can read the source, pull out the business logic and the dependencies tangled up in it, and produce documentation as a side effect of the modernization work instead of a separate slog.
Security tends to drift between teams, so the same control ends up implemented five different ways across five applications. Write secure coding patterns, audit-trail requirements, and access controls as a transformation, and you can enforce them as you go rather than catching the gaps later in a review, after the code is already out there.
Infrastructure follows the same logic. Containerizing applications, generating Infrastructure as Code, standardizing pipelines. Define the standard once, apply it repeatedly, and you’ve cut both the effort and the risk of everything being slightly different.
From hours billed to outcomes delivered
This reaches past engineering. Technology services have long been sold by the hour, priced on team size and how people get allocated, with the client carrying the risk that all those hours add up to the result they were actually after. Reusable transformations open up a different arrangement. You can price against outcomes, things like a faster migration or less technical debt or a measurable jump in quality, because the work is now repeatable enough to stand behind.
The incentives change in a real way. When delivery is repeatable instead of built from scratch each time, a provider can commit to the result rather than the effort that went in.
Seeing what static analysis misses
Static analysis is good at the things it was built for. Syntax errors, familiar code smells, the defects that sit on the surface. The problems that actually hurt enterprises usually aren’t on the surface, though. They have to do with intent. Financial transactions handled the wrong way, architectural anti-patterns, domain boundaries that have quietly eroded, resiliency that was never built in, a compliance requirement that’s being violated without anyone noticing.
A linter walks straight past all of that. AI that can reason about what the code is structured like and what it’s meant to do can actually surface these issues, and more and more it can suggest a fix rather than just raising a flag and leaving the rest to you.
The connection to DORA metrics
High-performing engineering teams tend to watch four things, and transformation-driven modernization moves all four in the right direction:
- Deployment frequency — how often you ship
- Lead time for changes — how long it takes an idea to reach production
- Change failure rate — how often a deploy breaks something
- Mean time to recovery — how fast you recover when it does
A security incident shows why most clearly. When a critical vulnerability surfaces in a dependency everyone uses, the response is simple to describe and tedious to carry out: find every affected application, apply the update, confirm nothing broke, deploy. Spread across dozens of repositories, that burns real engineering time, and the whole while the organization is sitting exposed. A reusable transformation folds that into one standardized workflow that runs at scale, so a multi-week scramble starts to look more like a routine job. Faster response, less exposure, better numbers across the board.
The real frontier
AI has already changed how software gets built. The bigger opportunity is in how software changes over time, and that comes down to capturing knowledge, not generating more text.
Organizations that figure out how to write their modernization expertise down as reusable transformations will adopt new technology faster, spend less keeping the lights on, hold a stronger security posture, and stop asking their engineers to solve the same problem twice. The goal was never to have AI write more code. It’s to have AI capture expertise that took years to build, automate the modernization work that’s always been a drag, and turn enterprise engineering from a backlog of one-offs into something that scales.
For enterprises picking their way through technology that only gets more tangled, that might be the most useful thing AI ends up doing. The move from refactoring to re-platforming isn’t about closing the gap between the code you have and the code you want — it’s about making that gap something you can actually manage.
