12 min read
I keep getting pulled into the same meeting.
Different companies. Different industries. Different faces on the video call. Same conversation. Someone senior — usually a CTO or a VP of Engineering — opens with a variation of the same line: “We have a monolith. Somewhere between one and fifty million lines of code. We’ve been maintaining it for fifteen to twenty years. We want to use AI to modernize it.”
Then comes the pause. The slightly hopeful pause. The pause that says: tell me there’s a tool that does this.
There isn’t.
I understand why you want there to be. The codebase is old. The engineers who understood it are gone or coping. The documentation, assuming any exists, is a monument to decisions made under pressure in quarters that have since been forgotten. And now every board conversation, every investor update, every analyst briefing is about AI. Someone upstairs has decided that the answer to twenty years of compounding technical debt is a very expensive model and a sprint or two.
It is not.
Harry Potter Cannot Save You Either
Most people remember the wrong thing about Harry Potter.
Harry doesn’t win because he finds the perfect spell. He wins because he has Hermione, who read every book in the library before she was twelve. He wins because he has Ron, who knows the terrain, knows the people, knows which shortcuts are traps. He wins because he has Dumbledore’s Army — people who practiced under pressure, made real mistakes in a safe environment, and built actual capability out of it. He wins because Neville Longbottom, of all people, shows up at exactly the right moment with exactly the right knowledge.
The spell book matters. But the spell book without the team is just a very dangerous paperweight.
That’s your modernization problem. You want to hand someone a wand — a new AI tool, a new platform, a modernization vendor — and have them point it at twenty years of accumulated decisions and say Reparo. The codebase reassembles itself. Clean, tested, cloud-native, ready for the next decade.
That’s not how this works. It was never going to be. And you already know that.
Let’s Talk About What Your Code Is Actually Worth
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. I’d be richer than Elon Musk. So would every senior developer I know who has spent twenty years shipping working software.
We are not richer than Elon Musk.
The code is not the value. The code is the cost of delivering the value. The value lives somewhere else entirely — in the customer relationship, in the market insight, in the product decisions about what to build and what to cut and who you are actually trying to serve.
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. You don’t have a modernization challenge. You have a signal problem.
You don’t know what the thing is actually for anymore. And no amount of AI tooling will tell you.
Signal One: Your Customers
This one sounds obvious. It almost never happens.
Go talk to customers. Not in a survey. Not through the account management team. Not via the NPS score that Product emails you once a quarter. Actually talk to them. The ones who have been paying you for ten years. The ones who have been paying you for two years. The ones who are paying you right now but are six months from churning.
Ask them four questions:
What do you use this product for? Not the intended use case. Not what it says on the pricing page. What are they actually doing with it on a Tuesday morning when there’s work to be done?
What do you not use it for? Half your codebase may be features nobody has touched since 2019. This is the conversation where you find that out.
If we removed this feature, would you leave? Ask it feature by feature, capability by capability. You need to know what is load-bearing and what is scar tissue.
Are you the customer we want to build for in the next five years?
That last question is the one executives skip. They skip it because the answer might be uncomfortable. Some of your oldest, most entrenched customers might be the ones whose requirements are most responsible for the monolith’s complexity. They demanded the features nobody else uses. They got custom workflows built for their business model in 2008. They are paying you, and that payment has become a hostage situation — you can’t change anything because they’ll complain, and you can’t grow because every sprint is maintaining what you built for them a decade ago.
Walking away from certain customers is a real option. Most organizations never let themselves consider it — not because the math doesn’t work, but because nobody wants to be the person who made that call. You can’t make it if you never ask the question.
The signal from customers tells you what to build. It also tells you what to delete. And deletion — aggressive, intentional reduction of scope — is the most powerful modernization tool that exists. No AI required.
Signal Two: What Your Application Is Actually Doing
You have been running this application in production for fifteen to twenty years.
Do you know what it’s doing in there?
For most teams that have been in maintenance mode for a decade, the honest answer is: not really, no.
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. You have been flying blind. You are attempting to modernize a system you cannot actually see, which is the engineering equivalent of performing surgery in the dark.
It’s fixable. But you have to start by admitting you can’t see the thing you’re trying to fix.
You need Application Performance Monitoring. You need structured logs that actually surface user behavior. You need the ability to look at your production system and say — with confidence — “these thirty thousand lines of code have not been exercised in two years.” Because if you can say that, you can delete them. Not refactor them. Not migrate them. Delete them. That is a modernization win that costs nothing except the courage to do it.
Shipping a version of your application whose primary purpose is instrumenting what already exists is a legitimate, valuable engineering sprint. It is not glamorous. It does not get the board excited. But it generates the signal you need to make every subsequent decision with confidence rather than fear.
Fear is how you got here. Afraid to change things because you don’t know what will break. Afraid to delete things because someone, somewhere, might be using them. The observability layer is how you replace that fear with data.
Signal Three: The People Who Will Actually Do the Work
To modernize a legacy system, you need engineers who know how to build modern systems. That sounds obvious — look at the room. The engineers who know your codebase best are usually the engineers who learned their craft maintaining it. They’re good at it. They’re experts in the specific survival skills the system requires. They have optimized, rationally, for the environment they were rewarded for operating in.
Asking those engineers to imagine a fundamentally different architecture — to rewrite a system they’ve spent a decade stitching together — is like asking someone to demo the neighborhood they grew up in. Technically possible. Emotionally almost impossible. And practically, they often don’t have a mental model for what the new thing looks like, because they’ve never built one.
None of that is a criticism. They are responding rationally to the incentives you built around them. That’s on you.
But you need people who have built greenfield services, who have worked in distributed systems, who have applied domain-driven design to real problems at real scale — and who can work alongside the people who know where the bodies are buried. That combination is the actual team you need. Not a vendor. Not an AI tool. A team with complementary depth.
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 is the architecture documentation that does not yet exist. Harry is probably you. Neville shows up later, when you least expect it, and saves the day in a way nobody planned for.
What If You Don’t Have a Dumbledore’s Army — And Can’t Train One Fast Enough?
This is the question nobody asks out loud in these meetings, but everyone is thinking.
What if the team you have genuinely cannot get there in the time you have? Not won’t — can’t. The two engineers who know the codebase are retiring in eighteen months. Your organization has never shipped a cloud-native service and there is nobody in the building who has. The training budget exists but the timeline doesn’t — and every quarter you spend developing people is a quarter the competitor is already in market.
Those constraints are real. So let’s deal with them.
The first thing to settle is what kind of decision you’re actually making. Closing a capability gap is a build-versus-buy problem, the same as any other. What does it cost to grow this internally — over what timeline, with what probability of success? What does it cost to bring it in, and what do you give up in the trade? Most organizations skip that analysis entirely. They default to hiring because hiring feels like progress, or they default to the vendor who showed up with a polished deck because the meeting ran long and someone had to make a decision.
Run the numbers. Then decide.
If you do bring in outside expertise — and sometimes you should — watch the trap carefully. Bringing in a team to modernize your monolith while your own people are kept out of the room is expensive outsourcing with a better label. The knowledge walks out the door when the engagement ends, and you are back in the same meeting in four years with a slightly newer monolith and a substantially lighter balance sheet. Structure it so your engineers are in the room, asking questions, building the model alongside the people who already have it. The external team is the training program. Not the solution.
And stop trying to hire an army. In the Harry Potter story, it is not about scale. Dumbledore’s Army does not beat Voldemort by being larger than the Death Eaters. What matters is that specific people were in specific rooms at specific moments with specific capabilities. Five engineers who have done this before will outrun fifty engineers figuring it out as they go. Every time. The instinct to scale headcount at the first sign of a large problem is exactly backwards. You need density of judgment, not volume of bodies.
Somewhere in your gap, there is probably also a person you need who does not exist in your org yet — someone who has run a modernization effort at this scale, who can make the right architectural call fast because they’ve made it before, who recognizes the traps from the entrance rather than from inside them. That person probably does not work at your company right now. Bringing them in is not a sign that you failed. Pretending you don’t need them is.
There is no perfect team waiting in the wings. The organizations that modernize successfully start without one. What they have is honesty about the gap and the willingness to make the structural call — hire, bring in, partner, train — that the situation actually requires.
The ones that fail are still waiting for the team to get ready on its own.
The Real Enemy Is Your Attachment
I have had enough of these conversations now to know what stalls them.
It is not budget. It is not timeline. It is not even the codebase itself, monstrous as it might be.
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 — the same decisions, the same history, the same compromises. Changing the monolith means confronting choices made by people who may still work there, who may report to you, who may be you. It means admitting that some of what was built over the last twenty years was built for the wrong reasons, for the wrong customers, by well-intentioned people operating without enough signal.
That is uncomfortable. And because it is uncomfortable, a lot of organizations outsource the discomfort to a vendor. They buy a modernization platform. They engage a services firm. They announce an AI-driven transformation initiative. And something gets shipped and demonstrated and presented to the board — while the attachment remains intact, and the actual hard decisions never get made.
You will know you are actually modernizing when something gets deleted. When a customer segment gets gracefully wound down. When an engineer looks at a module that hasn’t been touched in three years and it is simply gone. That is the signal that you are doing it right.
One More Thing: It Is March 2026
You are late.
The 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. That gap is real and it will not close easily.
There is one silver lining in being slow, and it is this: because most enterprises were slow, the talent you need now actually exists. In 2022, engineers who had lived through a genuinely AI-native development cycle — distributed systems, DDD, observable infrastructure at real scale — were rare. The pool was thin. You were competing with every well-funded startup in the world for the same handful of people.
That’s changed. The market caught up. Engineers who’ve done this — genuinely, in production, at real scale — exist now. Not everywhere. But findable.
Getting them to want to work at your company — at a twenty-year-old codebase with manual deployments and a backlog that reads more like a museum exhibit than a product roadmap — that’s a different conversation.
That’s the next post.
First: 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 to all three is yes, you are ready to have a real conversation about modernization.
If the answer is no — to any of them — then the AI tooling conversation is premature. You are shopping for spells when you do not yet have a team.
Build the team first.
The spells come after.
The Playbook, Stripped Down
If you want to cut through all of this and put something on a whiteboard, here it is.
One. Get a product organization that can actually talk to customers. Not survey them. Not send them a renewal call. Talk to them. Find out what they’re building with your software, what they’re working around, and what they’d miss if you turned it off tomorrow. That is your map. Without it, everything else is guesswork dressed up as a roadmap.
Two. Use observability in your current codebase as a live signal of what is working and what is not. Instrument what you have. Watch what fires and what doesn’t. Treat three years of silence in a module as a vote to delete it. The telemetry is your north star — it tells you where the ground is solid enough to stand on and where you’re about to step through the floor.
Three. Get engineers who can build the next generation of your product — and use the strangler pattern to move forward. Not a big-bang rewrite. Not a parallel track that never ships. Strangle the old system one slice at a time, replace it with something modern, and keep the lights on while you do it. That is how you get from here to there without betting the company on a single migration that takes three years and blows up in year two.
That’s it. Three things. Most of the complexity in modernization conversations comes from avoiding these three things, not from doing them.
Start there.