Slide 01

AI Will Not Save Your Monolith. These Three Things Might.

CxO + Director + Board

Core claim

You want to hand someone a wand — a new AI tool, a modernization vendor — and have them point it at twenty years of accumulated decisions and say Reparo. There is no spell that does this.

The code is not the value. The code is the cost of delivering the value. Your monolith is not a technical problem that got out of hand. It is a product management problem that got encoded in software and left running for two decades.

Timing It is March 2026. You are late. Organizations that started in 2023 carry a two-year compounding advantage right now.

Slide 02

Every Company Has the Same Conversation. None of Them Have the Prerequisites.

Market signal

The monolith 1-50M lines

Somewhere between one and fifty million lines of code, maintained for fifteen to twenty years. Same story, different company.

The hope Reparo

Tell me there is a tool that does this. A wand you point at twenty years of accumulated decisions. There is not.

The real problem Signals

The value lives in the customer relationship, the market insight, the product decisions about what to build and what to cut.

If shipping software that compiled, ran, and didn't crash — software that simply worked — made someone a billionaire, I would not be writing this post. The code is the cost of delivering the value. The value lives somewhere else entirely.

The monolith is a product management problem encoded in software

Slide 03

Deletion Is the Most Powerful Modernization Tool That Exists

Signal one: customers

Four questions to ask customers

What do you use this product for?
What do you not use it for?
If we removed this feature, would you leave?
Are you the customer we want to build for in the next five years?

What most organizations do instead

Send a survey. Read the NPS score that Product emails once a quarter.
Skip the last question because the answer might be uncomfortable.
Refuse to consider that some of your oldest, most entrenched customers are most responsible for the monolith's complexity.
Never let themselves consider that walking away from certain customers is a real option.

Slide 04

If You Cannot Say Which Code Has Not Been Called in Two Years, You Are Flying Blind

Signal two: observability

The fear cycle

Fear is how you got here. Afraid to change things because you do not know what will break. The observability layer is how you replace that fear with data.

If your application does not have observable logging — logging that tells you which features are being used, which code paths are firing, which modules nobody has called in three years — then you are flying blind.

Prerequisite You need APM. Structured logs that surface user behavior. The ability to say with confidence: these thirty thousand lines have not been exercised in two years.

What observability unlocks

Unused modules become candidates for deletion rather than migration. You stop migrating code nobody uses. You stop preserving features nobody wants.

The honest answer for most teams in maintenance mode for a decade: they do not really know what their system is doing in there.

Decision Instrument first. Modernize second. Without data, every architectural choice is a guess wearing a suit.

Slide 05

Five Engineers Who Have Done This Before Will Outrun Fifty Figuring It Out

Signal three: teams

Legacy

Engineers who know the system

They understand your customers, your domain, your edge cases. Asking them to imagine a fundamentally different architecture is like asking someone to demo the neighborhood they grew up in. That is not a criticism — they are responding rationally to the incentives you built around them.

Modern

Engineers who build new systems

People who have built greenfield services, who have worked in distributed systems, who have applied domain-driven design to real problems at real scale. They exist now. Not everywhere. But findable.

Together

Hermione and Ron

The engineers who understand your customers and the engineers who can build new systems differently — that is your Hermione and your Ron. The spell book without the team is just a very dangerous paperweight.

Warning What stalls modernization is not budget, not timeline, not even the codebase. It is attachment. You are attached to the organization that grew up around the monolith, because the monolith and the org are the same thing in different form.

Slide 06

Build the Team First. The Spells Come After.

Decision close

The prerequisite test

Do you have the signals? Do you know what your customers actually need? Do you know what your application is actually doing? Do you have the people who can do something real with that information?

If the answer is no — to any of them — then the AI tooling conversation is premature. You are not ready for a wand. You need Hermione and Ron first.

Organizations that started this seriously in 2023 and 2024 — that built the product intuition, hired the right engineers, instrumented their systems, made the hard calls on customers — they carry a two-year compounding advantage right now.