Developers like clean starts.
It is easy to understand why. A new codebase has no strange conventions, no half-finished integrations, no unexplained hacks, and no years of technical debt attached to it. You get to choose the structure, the naming, and the architecture.
Real project work is rarely that generous.
At BORN Group I worked on both sides of this: projects where the Magento codebase was still reasonably understandable, and projects where it felt like every change came with a tax. Dakine was one of the cleaner experiences. Other Magento codebases were more tangled, more fragile, and much harder to trust.
After doing both, I stopped asking, “Would I rather rewrite this?”
The better question became:
Is this codebase salvageable enough that improving it is smarter than replacing it?
That is a much less emotional question.
The inheritance tax: what you inherit beyond code
When you inherit a Magento codebase, you do not inherit just PHP files. You inherit data assumptions baked into the schema, deployment habits built around a particular server setup, configuration decisions that made sense at the time they were made, business rules hidden in custom modules that no one documented, and integration contracts with third parties that the current team may not fully understand.
That is why inheritance work feels heavier than reading code line by line. You are trying to understand a living system, not a repository.
This is especially true in Magento because so much behavior is indirect, observers, class rewrites, configuration scope, layout updates, admin settings. None of those leave obvious traces in PHP files you would normally search through.
Two codebases can have roughly the same feature list and feel completely different to maintain based on how predictable those moving parts are.
The inheritance tax is really the cost of lost intent. If the code tells you what it is doing but not why, every change becomes slower.
Signs a codebase is worth saving
I do not think a codebase needs to be pretty to be worth saving.
What matters more is whether it is understandable enough to be shaped.
The signs I trust most: module boundaries are still visible, naming is inconsistent in places but not chaotic everywhere, integrations are ugly but not magical, the deployment path is unpleasant but repeatable, and bugs tend to have local causes rather than system-wide mystery causes.
That was the difference in the cleaner Magento projects. They still had debt, but the debt was navigable. I could form a mental model of the system and improve one area without feeling like I might accidentally damage three unrelated areas.
That is a very important quality.
Salvageable systems let you build confidence as you work on them. Unsalvageable systems consume confidence faster than you can rebuild it.
Signs it isn’t
The danger signs are different.
A codebase starts looking unsafe to me when no one can explain why important modules exist, when core behavior has been overridden in too many brittle ways, when every change requires production trial and error to verify, when configuration scope is messy enough that the same bug behaves differently across stores for unclear reasons, and when upgrades feel impossible because the customization layer is too entangled with the platform to safely move.
This is where the conversation about “technical debt” gets too vague. Some debt is just the cost of history. Other debt means the system has stopped being a trustworthy place to change things.
That distinction matters.
I am willing to work with historical mess. I am much less willing to trust architecture that no longer has safe extension points.
The “rewrite from scratch” trap
Once a codebase feels painful enough, rewriting starts sounding wise.
Sometimes it is wise.
Very often it is just emotionally satisfying.
The trap is that a rewrite removes visible mess while also discarding hidden knowledge: edge cases that were learned the hard way, operational workarounds that exist for real reasons, data compatibility assumptions baked into the current system, and integrations that only look simple from the outside.
Magento makes this trap worse because some bad-looking customizations exist for reasons the team only remembers after the rewrite breaks them.
I have become much more suspicious of rewrites that are justified mainly by frustration. Frustration is a real signal, but it is not yet a business case.
If the current system is ugly but navigable, a rewrite can easily take longer, cost more, and still end with missing behavior.
That does not mean rewrites are wrong. It means they need stronger reasons than, “This code is hard to work in.”
A pragmatic approach: the strangler pattern for Magento
The approach I trust most in messy Magento systems is something closer to the strangler pattern than to a full restart.
That means identifying the pain points that are both high-value and locally understandable, replacing or isolating them one area at a time, and keeping the business running while the shape improves.
Magento is a good candidate for this kind of thinking because not all parts of the system are equally unhealthy. A checkout customization may be fragile while catalog management is acceptable. A search integration may deserve replacement while customer account flows can stay where they are for now.
This approach is less dramatic, but it respects reality better.
It also creates a useful feedback loop. If the codebase responds well to targeted replacement and refactoring, that is evidence it is worth saving. If every isolated improvement still gets trapped in systemic chaos, that is evidence the architecture is worse than it first looked.
That is a much safer way to discover the truth than betting everything on a rewrite.
What I’ve learned about technical debt from both experiences
The biggest thing I have learned is that technical debt is not simply “old code”.
Technical debt becomes dangerous when it removes your ability to predict change.
That is why two Magento codebases of the same age can feel completely different:
- one is old but understandable
- the other is old and adversarial
Dakine taught me that inherited code can still be workable if its intent is visible.
The more tangled Magento systems taught me that a rewrite is not automatically maturity. Sometimes maturity means knowing how to improve a difficult system without pretending it should have been rewritten six months ago.
If I had to reduce it to one rule, it would be this:
Save the system if you can still create local confidence.
Replace the system if every change proves the architecture no longer has trustworthy boundaries.
That rule is less exciting than “always rewrite” or “never rewrite”, but it has served me much better.