A few days ago, Sphere’s CEO Leon Ginsburg published a long-form article on Medium about a moment many leaders recognize all too well: the point where the core platform that once powered growth quietly starts limiting what the business can do next.
In that piece, he explored how to approach modernization in a world where leadership teams have both traditional tools and Generative AI at their disposal. This version is a shorter editorial adaptation for the Sphere blog. It keeps the core ideas, adds fresh context from the market, and gives you a practical path to AI-powered legacy system modernization in 2026.
One line from the original article captures the tension:
“There is a point where legacy stops being background plumbing and starts deciding your speed more than your org chart does.”
This article is about what to do when you realize you have reached that point.
Legacy systems are now a strategy problem
A recent Pegasystems study estimates enterprises lose about $370 million per year on average because of outdated technology and technical debt: failed modernization projects, expensive transformation programs, and the ongoing cost of keeping legacy systems alive.
AWS cites studies showing that organizations spend roughly 20% of their IT budget servicing technical debt instead of investing in new capabilities. IDC notes that technical debt now directly slows AI adoption, because older architectures cannot provide the clean data and flexible integration these systems need.
You do not need to read code to see the symptoms. You see them when roadmaps slip for reasons that sound vague but always trace back to “the platform can’t take it.” You see them when regulators worry about outages tied to complex legacy stacks and warn banks and insurers that modernization delays are now an explicit risk factor.
In that world, legacy and technical debt stop being internal housekeeping topics. They become constraints on growth, AI use, and risk. That is why modernization needs the same level of attention as product strategy and capital allocation.
What is AI-powered legacy system modernization?
Before jumping into patterns, it helps to define the thing you are actually trying to do.
AI-powered legacy system modernization means using Generative AI and related tools to accelerate and de-risk modernization while keeping humans in control of intent and decisions. It is not about pushing a button that “rewrites the monolith.” It is about combining:
- A clear target architecture (monolith, modular monolith, selective microservices).
- A staged, test-heavy modernization roadmap.
- AI assistance across discovery, refactoring, testing, and documentation.
McKinsey, Deloitte, Thoughtworks, and others now converge on a similar pattern: GenAI can compress modernization timelines and reduce manual toil, but only if you orchestrate it with strong guardrails and expert oversight.
That frame is the foundation for the rest of this article.
When Legacy Sets the Ceiling, Modernization Sets the Pace
Discover how modern architecture and GenAI turn outdated systems into a launchpad for 2026—faster delivery, safer change, and a platform you can finally build on.
What is a modular monolith, and when should you use it?
Architecture debates often turn into “monolith vs microservices” arguments. In practice, there is a third option that now shows up in many serious modernization programs: the modular monolith.
A modular monolith is a single deployable application that is internally split into strict, domain-aligned modules. Each module owns its own slice of the domain (billing, onboarding, pricing, reporting, and so on). Modules interact through clear interfaces instead of reaching into each other’s internals. The database is often still shared, but tables are grouped by module and cross-module leakage is actively reduced.
Why does this matter for a leadership team?
First, a modular monolith keeps operational simplicity. You still have one deployment pipeline, one runtime, and a much lower coordination cost than a fleet of services. That makes it realistic for organizations that do not have mature SRE, on-call, or observability yet.
Second, it exposes real domain boundaries before you start cutting services. As you enforce module boundaries inside the monolith, you see which modules change together, which ones carry hidden business rules, and where actual autonomy is needed.
Third, it gives you many of the benefits of microservices without the network complexity. Teams can own modules and reason about their impact in a contained way, but production operations do not explode in complexity.
This is why you now see a pattern in industry commentary: monolith first, then modular monolith, then selective microservices once there is a strong enough reason.
When should you move from a monolith to microservices?
There is a natural question behind every modernization conversation:
When should you move from a monolith to microservices?
Instead of treating this as a matter of taste, you can treat it as a decision based on three variables.
First, look at domain complexity and change rate. If you still have one relatively compact domain and modest change, a well-structured monolith or modular monolith can be more than enough. If you have multiple intersecting domains, each with different roadmaps and external dependencies, you start to feel pressure for separation.
Second, check your team topology. If you run one team that releases a few times a month, splitting into services is unlikely to deliver a return. If you already have several squads that need to move in parallel and own outcomes across a domain, separate deployables start to align architecture with how you work.
Third, assess operational maturity. Microservices introduce new failure modes: timeouts, partial outages, cascading failures, consistency issues. They demand robust CI/CD, observability, and incident management. Many big companies are now quietly consolidating or moving toward packaged microservices or modular monoliths because they underestimated that cost in early waves of “microservices-everywhere” programs.
When domain complexity is high, teams are already organized by domain, and operational maturity is strong, a targeted microservices strategy can unlock genuine benefits: independent scaling, independent releases, and tighter governance around high-risk flows. When those conditions are not met, modular monoliths give you structure without overreach.
How can Generative AI help with legacy code modernization?
Another practical question leaders and architects ask:
How can Generative AI help with legacy code modernization?
Over the last two years, several patterns have emerged from both vendors and early adopters. IBM’s Mono2Micro uses AI to propose partitions of Java monoliths into candidate microservices, based on static and dynamic analysis of code and runtime behavior. AWS, Pegasystems, and others now offer platforms that use AI to map systems, suggest refactors, and automate parts of code migration.
Thoughtworks, Martin Fowler, and multiple consultancies have experimented with GenAI tools that:
- read large legacy codebases and generate human-readable summaries,
- surface data flows and “shadow business rules” hidden in decades-old implementations,
- draft migration plans from older frameworks to modern stacks, and
- generate tests that freeze current behavior before any change.
Recent reports show real impact. Some researchers state that GenAI handled 69–75% of code edits during large-scale migrations, cutting project duration by around half. Fujitsu reports proof-of-concept trials where GenAI reduced modernization timelines by about 20%, and agentic AI cut them by up to 50%. Morgan Stanley’s internal DevGen.AI tool saved more than 280,000 developer hours by turning legacy code into plain-English specs for easier rewriting.
The pattern is consistent: AI becomes a multiplier for strong engineering. When experts define scope, constraints, and acceptance criteria, AI compresses discovery, refactoring, and testing. When those guardrails are missing, AI can amplify risk and create subtle, hard-to-find defects.
How do you modernize legacy systems with AI in 2026?
So what does an AI-assisted modernization program actually look like in practice?
You can think of it as a loop with five stages that repeats per domain or capability.
First, assessment and mapping.
You start by building an honest map of the current state: domains, integrations, data flows, runtime topology, incident patterns, and delivery bottlenecks. AI helps by reading code, inferring structure, and highlighting dependency clusters and fragile areas that do not match the official diagrams.
Second, architectural choices.
You decide whether the near-term target for that area is a better-structured monolith, a modular monolith, or a set of services. Context-driven guidance from practitioners now emphasizes starting with structure, then adding distribution when pressure justifies it.
From monolith to modular to microservices: choose the structure that matches your maturity.
Third, refactoring and modularization.
You use GenAI to propose refactors that enforce module boundaries, clean up tangled code, and group related behavior. The goal is to create cohesive modules with clear interfaces, even before any service extraction. AI assists, but architects decide which suggestions to accept, adapt, or reject.
Fourth, test scaffolding and safety nets.
You surround critical flows with tests, many of which start as AI-generated drafts. These tests capture current behavior so you can detect regressions caused by refactors. Vendors and early adopters consistently report that AI reduces the time required for this scaffolding work, which historically has been a bottleneck.
Fifth, selective extraction and hardening.
Once modules are stable and well-tested, you identify candidates for service extraction based on scaling needs, regulatory requirements, or the need for independent releases. Tools like Mono2Micro inform the partitioning, but human teams own the final model.
This loop repeats. Each cycle leaves the system a bit more modular, a bit better tested, and a bit easier to evolve.
The 5 Pillars of Implementing a Successful AI Strategy
Download our latest e-book to learn how AI and data strategies can drive smarter decisions, higher efficiency, and stronger customer relationships.
What does a practical modernization roadmap look like?
A roadmap turns that loop into a plan the organization can actually follow.
One realistic pattern for the next 18–36 months looks like this:
- Name the constraint. Quantify the cost of legacy and technical debt using your own numbers and external benchmarks, then explicitly treat modernization as a strategic initiative, not a background IT project.
- Choose a first domain. Pick an area that is painful but not existential. Apply the AI-assisted loop there first: mapping, modularization, test scaffolding, and selective extraction.
- Institutionalize the pattern. Turn the approach into a playbook and platform: standard tools, prompts, review practices, and metrics for modernization. Bring security, architecture, and product into the same conversation.
From there, the roadmap becomes a rolling program rather than a one-off project. Each cycle reduces technical debt, improves architecture, and builds institutional confidence in AI-assisted change.
Where should CIOs start with legacy modernization?
For many CIOs and COOs, the hardest part is simply deciding where to start. The landscape is noisy, and the risk of another expensive, failed transformation is real.
A pragmatic starting point combines three moves.
First, create a shared fact base. Use AI-powered discovery to map key systems and cross-check that map against incidents, outages, and delayed initiatives. Pair that with financial data: how much you spend on keeping legacy alive, how many projects are blocked by architecture, and how much AI work is forced into “pilot purgatory” because the core systems cannot support it.
Second, agree on a near-term architectural target. Decide whether the next two years are primarily about getting to a modular monolith, carving out a few critical services, consolidating scattered platforms, or all of the above. Document this target clearly enough that everyone from product to finance can see the connection between modernization work and business outcomes.
Third, launch one AI-assisted modernization slice with clear success criteria. Choose a system or domain where you can reasonably show progress in six to twelve months. Define what success looks like in terms of lead time, incident rate, AI integration capability, and cost of change. Use that slice to prove (or disprove) the value of the approach and refine your playbook before scaling.
This is how modernization shifts from a scary, multi-year bet to a sequence of controlled experiments with visible business value.
How do you reduce technical debt before scaling AI?
One last question matters for leadership teams planning serious AI initiatives:
How do you reduce technical debt before you scale AI across the business?
Vendors, analysts, and practitioners all arrive at a similar answer. You do not need to clear every legacy system before you deploy AI. You do need to make sure that:
- the systems feeding your AI have stable interfaces and acceptable data quality,
- the core transaction engines have clear domain boundaries and basic observability, and
- the worst pockets of technical debt are either refactored or isolated behind well-defined APIs.
In other words, modernization and AI adoption reinforce each other. Modernization clears enough space for AI to be effective and safe. AI then accelerates modernization by making code comprehension, refactoring, and testing faster and cheaper.
This is the loop that defines the next few years for many organizations. Those who invest in it intentionally will find that their “legacy” platforms stop setting the ceiling and start acting as launchpads again. Those who ignore it will find more and more of their strategy dictated by systems they no longer fully understand.
If this picture feels close to your current reality, now is the time to treat modernization as a core part of your 2026 planning, not a side project. Whether you choose to work with Sphere or follow your own internal path, the most expensive option is to let the architecture decide for you.
