When dealing with legacy systems, we often face a crucial fork in the road: should we rebuild from scratch or should we refactor and modernize what already exists?
At first glance, this choice may look like a matter of instinct, personal preference, or even technical skills. Developers may lean toward the option that feels more natural to them: the adventurous ones tempted by a blank slate, the pragmatic ones drawn to incremental changes. But in reality, this is not about personality. There is a simple principle that should guide the decision.
In this article, we’ll explore the advantages and risks of both approaches and then distill the choice into a framework that prioritizes what is truly valuable in your system. Because, in the end, modernization is not about technology for its own sake—it’s about preserving the business advantage that technology enables.
The Legacy Paradox: Competitive Advantage as a Cage
Legacy systems are like Schrödinger’s cat: they exist in a paradoxical state. On one hand, they are the source of your competitive advantage, the crystallization of years (sometimes decades) of domain knowledge, business rules, and refined processes. On the other hand, they are also a source of frustration, a technological cage that slows you down, makes hiring difficult, and resists change.
Ideally, we would like to keep the best and discard the worst. We want to preserve the domain logic that differentiates us from competitors, while shedding the outdated technical stack that adds no real value. The danger, however, is in “throwing the baby out with the bathwater”: losing irreplaceable business logic just to escape from technology that feels obsolete.
The key question is therefore: what is truly valuable in your system?
In most long-lived systems—especially in business-critical applications like ERPs—the value lies overwhelmingly in the business logic. The fact that it is implemented in RPG, COBOL, or another aging language is not where the value resides. As long as the technology is “good enough,” the differentiator is the logic itself: the way your pricing rules, logistics flows, or manufacturing processes are encoded in the system.
As a technologist, it almost hurts me to admit this. I spend my days dreaming about programming languages, frameworks, and architecture. But the hard truth is that technology is not always the most important asset. In cases where innovation is technical at its core—say, real-time streaming or advanced compression algorithms—the technological stack is the differentiator. In such cases, preserving business logic matters less than ensuring you’re at the cutting edge of performance.
Take Skype in its early days. Its competitive advantage was not the way it organized your contacts or managed the user interface. That part of the system could have been average and no one would have cared much. What made Skype revolutionary was the technology that enabled free, reliable voice calls over the internet—a capability that competitors simply couldn’t match at the time. The differentiator was purely technical. The contact list could be “good enough,” because the value lay elsewhere.
But in the majority of enterprise systems, business logic is the crown jewel. And if that’s true for your organization, your priority should be clear: preserve the logic at all costs, even if it means tolerating an “okay” technology stack.
Of course, this is the real world: compromises are unavoidable, resources are finite, and we would all love to maximize both dimensions at once. But clarity about priorities makes all the difference. Preserve the differentiating factor, and contain losses in the other.
The Siren Song of the Big Rewrite
Why is the idea of a full rewrite so tempting?
Because deep down, we all dream of a clean slate. Of leaving behind the mistakes, regrets, and compromises of the past and starting fresh. It’s the same impulse that makes us fantasize about moving to a new city, changing jobs, or reinventing ourselves.
In software, this fantasy takes the form of the “big rewrite”. A brand-new codebase, using the latest frameworks, uncluttered by decades of hacks and patches. It’s seductive because it promises freedom: freedom from technical debt, freedom from legacy tooling, freedom from outdated paradigms.
But just like in life, the reality rarely matches the fantasy. A new beginning doesn’t erase the habits, processes, and constraints that got us here in the first place. If your current codebase is chaotic, chances are high that rewriting it every two years would still lead you back to chaos—just in a shinier language.
There are, of course, cases where rewriting solves genuine problems. If your system was built around a design paradigm that is now obsolete.
The first risk is underestimating complexity. Every software project looks simpler from a distance. We see the big blocks, but not the tangled details. The closer we get, the more edge cases, exceptions, and hidden dependencies emerge. This is especially true if we aim to replicate an existing system while adopting unfamiliar technologies or frameworks. The new stack may solve some old problems, but it also introduces new ones we cannot yet foresee.
The second risk is the double burden when business logic is the differentiator. If your system is technology-driven—say, building the best audio compression engine or the fastest video streaming platform—you can focus the rewrite on technical innovation alone. But if your system is business-logic-driven, you face two masters:
- You must faithfully carry over decades of nuanced, domain-specific rules.
- You must simultaneously navigate the uncertainties of a new technology stack.
This doesn’t double the difficulty—it multiplies it. You’re now fighting complexity on two fronts: technical and business. And history shows that many such rewrites fail precisely because the team underestimates one or both challenges.
In short: the big rewrite is a siren song. It lures us with promises of purity and simplicity, but too often it crashes projects against the rocks of complexity, cost, and lost business knowledge.
Redefining Refactoring: Modernization as Strategic Evolution
Refactoring doesn’t have the glamour of a greenfield project. It often leaves programmers dissatisfied because, instead of indulging in architectural creativity, we begin with constraints. Our mission is not to invent an entirely new system but to preserve the business logic we already have while transforming the technological “shell” that surrounds it.
This can feel limiting. A rewrite lets you dream of elegant architectures and bold design patterns; refactoring forces you to ask: from where we are now, what are the realistic next steps? The range of possible destinations is narrower, because not every architecture can be reached incrementally from today’s codebase.
And yet, this discipline is exactly what makes refactoring viable. The path is incremental, not revolutionary. The art is to take one small, deliberate step at a time while keeping the system functional throughout the journey.
Refactoring can take many forms, depending on the ambition of the modernization effort:
- reorganizing classes and modules,
- adopting a new framework,
- transitioning from a monolith to a service-oriented architecture,
- or even porting the codebase to a new language.
All of these are legitimate forms of refactoring if they are approached incrementally.
This incremental approach demands not youthful exuberance but the patience and wisdom that come after making mistakes. It requires us to accept constraints, stay pragmatic, and move forward with eyes fixed on the goal: to maintain a working system while evolving it into a sustainable, modern one.
The first challenge is almost always testability. If your system cannot be reliably tested, you are walking on a tightrope without a safety net. Manual testing may work in the short term, but at scale it quickly becomes unsustainable. Introducing automated tests into a legacy system is one of the hardest and most valuable investments you can make.
One powerful framework for this mindset is described in The Mikado Method. The method provides a systematic way to untangle complexity: start with a change you want to make, identify the dependencies that block it, address those dependencies first, and only then move forward. By mapping out the “mikado graph” of dependencies, you turn a seemingly impossible transformation into a structured, achievable sequence of small steps.
Ultimately, refactoring is less about indulging creativity and more about disciplined engineering. It’s about respecting the continuity of business operations while gradually reshaping the system beneath them. The glory may be quieter than a grand rewrite, but the payoff is stability, lower risk, and the preservation of what truly matters: the business logic that sets you apart.
Conclusion: Preserve the Past, Prepare for the Future
We’ve looked at different approaches—rewriting from scratch or refactoring and modernizing—but in the end, we return to the same principle we started with: what is the real source of value in your system?
If the source of value is your business logic, then the path to follow is modernization through refactoring. This approach protects that logic, even if it means sacrificing the dream of building the most perfect technical solution. In many ways, it also saves us from ourselves—from the arrogance of thinking we can always do better from scratch, and from the inevitable surprises that software projects love to hide.
Think of it like the paradox between renovating a beautiful 19th-century villa and buying a brand-new house filled with modern conveniences. If what matters most is the charm and elegance of the villa, you accept that even with careful restoration it will never be as energy-efficient as a newly built home. The trade-off is worth it, because you are preserving what truly has value.
For technical teams, the message is just as important. Refactoring may look like the “less creative” option—it doesn’t let you pick the trendiest framework or redesign the architecture in whichever way you like. But in reality, it is a far more demanding technical challenge. Evolving a complex system incrementally while keeping it alive and functional requires discipline, patience, and mastery of specialized techniques.
This is where methods like the Mikado Method or patterns like the Strangler Fig come into play. These aren’t shortcuts; they are advanced strategies that demand study and experience. Far from being “easier,” incremental modernization is one of the most technically sophisticated things a development team can do.
And that’s the paradox: what looks like the safer, less glamorous path is, in fact, the more difficult one—and the one that, for most organizations, carries the best chance of preserving the past while preparing for the future.
The post Architecture Evolution: When to Choose Refactoring Over Rebuilding Legacy Systems appeared first on Strumenta.
