Don’t Criticize the Curtains: A Lesson in Modernizing Legacy Systems

A Funny Story About Curtains (and Legacy Code)

One of my favorite ways to explain modernization of legacy systems is this.

Imagine you’re invited over to someone’s house for dinner. You walk in, take a quick look around, notice the curtains, and immediately say, “Wow… these are tacky. You should really replace them.” That would be a bold move. And probably the last time you get invited over. 😄

Because the reality is—you have no context.

You don’t know if those curtains came with the house, or if they were the only option available at the time. You don’t know if there were budget constraints, or if they belonged to someone important to them. Maybe they were chosen quickly during a stressful move, or maybe they’ve just never been high enough on the priority list to change. There’s always a story behind what you’re seeing—you just don’t have it yet.

And this is exactly what happens when we walk into legacy systems.

Legacy Systems Are a History of Good and Bad Decisions

When you open up an older codebase for the first time, it’s very easy to jump straight to judgment. You see patterns you wouldn’t use today, dependencies that feel outdated, logic that looks more complex than it should be, and your first instinct is to ask, “Why would anyone do it this way?”

But that question, on its own, misses the point.

Because that system didn’t appear fully formed—it evolved. It was shaped by the constraints of its time: the technology that was available, the deadlines that had to be met, the team that existed, the business priorities driving decisions in that moment. Over time, as new features were added and priorities shifted, the system adapted. Not always cleanly. Not always intentionally. But it adapted.

That’s how accidental complexity grows. Not because people were careless, but because systems are living things. They change under pressure. They accumulate decisions. They reflect tradeoffs that made sense at the time.

So when you walk in and immediately decide everything is “wrong,” what you’re really showing is a lack of understanding of how systems—and organizations—evolve.

Modernization Is Evolution, Not Judgment

If you take that same mindset into modernization—walk in, declare everything broken, and try to replace it all—you’re going to run into problems quickly.

Because modernization isn’t about redecorating the entire house overnight. It’s about understanding what’s there, what still works, and what needs to change—and then making those changes thoughtfully over time.

That’s why approaches like the strangler fig pattern are so effective. Instead of forcing a full rewrite, you gradually introduce new capabilities alongside the existing system. You wrap parts of it, extract functionality, and replace pieces where it makes sense. Over time, the system evolves into something more flexible and maintainable, without putting everything at risk at once.

And this is where concepts like microservices and APIs become useful—not as goals in themselves, but as tools for decoupling. When parts of the system can operate more independently, you gain the ability to change one thing without breaking everything else. That’s what real modernization enables.

The Devil Is in the Details (and It’s Not Glamorous)

What often gets missed in conversations about modernization is how much of the work is not about building something new—it’s about stabilizing what already exists.

You spend time improving performance, because systems that are barely holding on don’t respond well to change. You upgrade libraries and frameworks, sometimes just to stay supported and secure. You replace outdated APIs, not because it’s exciting, but because it’s necessary. You add logging and observability so that when something goes wrong—and it will—you can actually understand why.

A lot of this work is invisible from the outside. It doesn’t look like transformation. It doesn’t make for a great demo. But it’s the foundation that everything else depends on.

Every Decision Is a Tradeoff

Modernization also forces you to think more deeply about tradeoffs than most people expect.

There are cost considerations—especially when introducing cloud services or third-party tools. There’s long-term ownership—who is going to support this new system, and do they have the skills to do it? There’s complexity—are you actually simplifying the system, or just moving complexity somewhere else?

And then there’s the temptation to over-engineer.

It’s very easy to start designing for a future that may or may not happen. To build systems that are theoretically flexible, but practically harder to understand and maintain. To over-decouple everything “just in case,” and end up with a system that’s harder to work with, not easier.

The reality is, no one fully knows what the future system needs to be.

So the goal isn’t to design the perfect architecture upfront.

Do Just Enough to Enable Change

Good modernization focuses on enabling change, not predicting it.

That means making systems modular enough that when something needs to evolve, it can. It means reducing coupling so that failures are contained instead of cascading. It means improving the parts of the system that are actively causing friction, rather than rewriting stable components that rarely change.

Sometimes the right decision is to modernize aggressively. Sometimes it’s to leave something alone because it’s doing its job well. Both are valid—if they’re intentional.

The goal isn’t perfection. It’s progress that doesn’t create new problems.

What This Really Comes Down To

That curtain moment—the instinct to walk in and judge—shows up in engineering more often than we like to admit.

But strong engineers and strong leaders pause.

They ask questions.
They look for context.
They try to understand the constraints before proposing solutions.

Because modernization done well isn’t about proving the past was wrong.

It’s about taking what exists, understanding why it exists, and evolving it into something better—without losing sight of the people and systems that depend on it.

And honestly, sometimes the curtains stay for a while.

Not because they’re perfect.
But because there are more important things to fix first.