“Every legacy system was once a greenfield project that succeeded.”
Every new wave in tech arrives with a promise to replace the old, cleaner code, faster deployments, better scalability. We are now deep in the age of microservices, serverless, and distributed everything. And yet, beneath countless companies’ most critical infrastructure lies something many engineers scoff at: the monolith.
But what if we’ve been too quick to dismiss it?
Let me take you back.
The Story We’ve All Lived: “We Inherited a Monolith…”
It’s a sentence uttered with dread in many engineering retrospectives.
The monolith, we’re told, is the villain, unscalable, untestable, unmaintainable. It’s the digital equivalent of a haunted house: nobody wants to go in, everyone just wants to tear it down.
But let’s pause.
That monolith? It’s still standing. It’s been running for 20+ years, processing millions of transactions, surviving team churns, poor documentation, and shifting priorities. It supported the company before Kubernetes was a word, before CI/CD was cool, before “DevOps” was even a job title.
Shouldn’t that resilience earn some respect?
Assumption Check: Are Monoliths Really the Problem?
We assume monoliths are:
- Inherently slow to change
- Impossible to scale
- Difficult to test
- Anti-agile
But let’s test that.
What makes them slow to change? Poor architecture? Or the absence of any architecture decisions? Often, the issue isn’t the monolith itself, it’s how carelessly it was grown.
Hard to test? Not necessarily. Many monoliths can be split cleanly into modules and benefit from clear separation of concerns (think Hexagonal Architecture). Martin Fowler, who helped define microservices, also said:
“You shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile. Start with a monolith, keep it modular, and only split it out into microservices once the monolith becomes a problem.”
And base on many aspects, I would say:
“Modular monoliths are underrated.”
So maybe it’s not the format. Maybe it’s the discipline (or lack of it).
Counterpoint: Microservices Aren’t Saints Either
Let’s not forget:
- Microservices introduce complex orchestration
- Distributed systems bring network failures, timeouts, latency
- They require more DevOps maturity, not less
- Debugging becomes a treasure hunt
A poorly designed microservice architecture is often worse than a well-maintained monolith. As Simon Brown noted in Software Architecture for Developers:
“If you can’t build a structured monolith, what makes you think microservices are the answer?”
Because if your team can’t manage a modular monolith, they’ll definitely struggle with 40 interdependent services.
Reframing the Legacy: Wisdom Over Worship
Legacy doesn’t mean outdated. It means battle-tested.
Think about Linux. The kernel dates back to 1991, yet it powers everything from smartphones to supercomputers. Or look at PostgreSQL, nearly 30 years old, but still a go-to choice for critical data infrastructure. Why? Because maturity brings stability, community wisdom, and decades of optimization.
Or take Unix philosophy. It’s older than most of us writing code today (1978), yet it continues to influence how we design software, modular, composable, reliable.
If age were a disqualifier, these pillars wouldn’t still be holding up half the internet.
What legacy systems offer:
- Proven reliability under pressure
- Deep, often undocumented domain expertise embedded in logic
- Business-critical processes that just keep working
The respectful mindset isn’t: “Let’s replace it.”
It’s: “Let’s learn from it, adapt it, and evolve it with care.”
Because wisdom doesn’t scream for attention, it hums quietly in the background, keeping things running.
Lessons From the Field: My Own Transformation
Years ago, I joined a company that ran a spaghetti-coded monolith. No tests, no pipelines, and no documentation. Sounds like a nightmare?
But here’s what we did:
- We mapped the domain.
- Introduced modular refactoring.
- Wrapped the edges in APIs.
- Slowly built microservices only where justified.
- Used the monolith as the stable core, not an anchor.
We didn’t fight it. We collaborated with it.
And guess what? The business didn’t grind to a halt. Our team didn’t burn out. The CEO didn’t worry about losing years of logic.
What a Skeptic Might Say
“Aren’t you just slowing down innovation by defending old tech?”
– No. I’m advocating for wise innovation. Evolution, not disruption for its own sake. When engineers run into legacy systems, the goal shouldn’t be to rewrite, it should be to redeem.
“But our monolith is a mess!”
– Then fix the mess. Don’t assume microservices will solve poor design. They’ll magnify it.
What We Should Be Asking Instead
- Is this legacy system still delivering business value?
- Have we truly understood its architecture before judging it?
- Can we make incremental improvements rather than betting everything on a rewrite?
- Are we ready to support the operational load microservices demand?
Conclusion: Smart Architecture Is Context-Aware, Not Trend-Driven
The most effective engineering teams today don’t obsess over being “pure” microservices or “fully modern.” They focus on what works best for the business, in the context of their current constraints.
That often means embracing hybrid architectures:
- Keeping the monolith where domain logic is mature, well-understood, and stable.
- Carving out microservices for fast-moving, independently deployable features, like user notifications, billing, or analytics dashboards.
- Using serverless for lightweight, event-driven tasks like image processing or webhooks.
This isn’t compromise. It’s strategic composition.
Companies like Amazon still run monoliths internally. Shopify famously evolved towards a modular monolith architecture to regain teams productivity and deployment ease. These aren’t failures, they’re smart responses to real engineering problems.
So the next time someone scoffs at your monolith, say:
“It’s not a relic. It’s a reliable foundation. And we know when to build on it, and when to build beside it.”
That’s not old-fashioned thinking. That’s architecture with intent.
Your Turn: Respect Before Refactor
- Audit your legacy system’s value.
- Identify bounded contexts before carving anything out.
- Treat the monolith as a partner, not a problem.
- Choose evolution over revolution.
And remember: Software that works is never obsolete.