Do You Need a Rebuild, a Refactor, or Something Smaller?

The system is old, everyone complains about it, and someone in the room finally says the word: rebuild. Every change takes weeks, the person who built it left two jobs ago, and the team has papered over the gaps with so many workarounds that the workarounds have become the process.

Starting over feels like the obvious move, and it feels good, because a clean rebuild promises a fresh system with none of the old baggage.

Frustration is a real signal, and a terrible strategy on its own. A painful system can be fragile code that needs replacing, or it can be a workflow that outgrew its design, a data structure that no longer fits, or an interface slowing everyone down, and those do not all lead to the same fix.

Before you commit to rebuilding, you need to know what problem you are actually solving, because a rebuild only pays off when you know what has to be preserved, what has to change, and what should never be carried forward.

‍

Is a painful system always a failed system?

No. A system can be genuinely annoying and still be doing real work every day. It may hold years of customer data, pricing logic, approval rules, and compliance steps that no one has fully written down anywhere else. Employees complain about the dated portal, and they also depend on details inside it that live only in the software and a few people's heads.

This is the part that gets lost when frustration takes over. An old admin tool that is hard to use might contain a decade of exception logic, the odd cases the business learned to handle the hard way. A reporting tool that needs constant cleanup might still carry the category definitions the whole company runs on. The old screens are the least of it.

Underneath them is a record of how the business learned to operate, and some of that record is worth keeping.

So the useful thing to ask is not whether the system annoys people. It is what the system still knows about the business that nobody has written down.

‍

Why do companies jump straight to "rebuild it"?

Because a rebuild feels like control. It hands leadership and the team a clean story: a better interface, fewer bugs, cleaner reporting, and a system people will finally want to use. That story is appealing enough that companies often commit to it before they have done the work that makes a rebuild succeed:

• Mapped the current workflow end to end
• Separated the software problems from the operational ones
• Documented the business rules buried in the old code
• Decided who will own the workflow after launch

Sonos is the cautionary version. In May 2024 it replaced its working app with a ground-up redesign and released it without fully accounting for what customers actually used every day.

The new app dropped sleep timers, alarms, and core accessibility features, and left some older systems barely usable. The backlash was immediate. Revenue fell 16 percent in the fourth quarter of fiscal 2024, the stock dropped around 13 percent, and by January 2025 CEO Patrick Spence had stepped down after eight years. The redesign itself was defensible. Releasing it before they understood what the old app did well is what cost them.

The lesson holds at any size. The team building the new system rarely has the full operational context of the old one, so they do not know which workflows are load-bearing or which temporary workaround became permanent infrastructure.

That is why Martin Fowler's advice from two decades ago, to grow the new system alongside the old one and retire the old one piece by piece, keeps outlasting the big-bang rewrite. The confidence to replace everything at once usually comes from not yet knowing everything the old system does.

‍

Rebuild, refactor, or maintain?

Rebuild is one option on the table. It should not be the only one. There are three honest paths, and most of the skill is in telling them apart:

• Maintain when the core workflow still fits, the system is stable, and users have specific frustrations rather than broad failure. The fix might be better documentation, minor improvements, or a cleaner support process.
• Refactor or modernize when the business logic is still valuable but parts of the system need structural work: cleaner architecture, better integrations, improved UX, stronger reporting, or updated dependencies. This is the path when a few workflows cause most of the pain and the system can be improved in stages.
• Rebuild when the system blocks real business decisions, small changes create major risk, the data model no longer supports the work, or the business has changed so much that the old assumptions no longer apply.

Plenty of painful systems never actually reach the rebuild end of that list. They land in the middle, where targeted work fixes the real problem for a fraction of the cost and risk.

‍

What do you need to understand before you decide?

Every modernization conversation should start with the business, before anyone scopes a line of code. A handful of questions surface whether you are looking at a rebuild or something smaller:

• What does the system still do well? Name what should not be lost before you talk about what to replace.
• Where does the work actually slow down? Map the points where people wait, duplicate effort, build side spreadsheets, or leave the system entirely.
• Which business rules live only inside the system? Old software often holds logic that exists nowhere else.
• Which workarounds have become permanent? A workaround usually points to a missing feature, an unclear owner, or a real system limit.
• Which problems are technical, and which are operational? A new system will not fix an approval process that no one owns.
• What will the business need this to do two years from now? The next version should be built for where the business is going, which is rarely the same as where it has been.

Skip this, and you risk the most expensive outcome in modernization: replacing a mess you understood with an expensive one you do not.

‍

What does modernizing well actually look like?

It starts with understanding the business well enough to choose the smallest move that solves the real problem. Sometimes that means building on top of what already works. When BeaconMedaes needed a platform to run a new division, we left their working stack in place. We started as a development partner on their existing infrastructure, then built MyMedGas as a fully integrated platform layered on top of it, architected to be maintainable and extended quickly as the product grew. The systems that were doing their job kept doing it.

Sometimes the honest answer is a full rebuild, because the business genuinely needs one. Witherspoon Rose Culture, a wholesale rose grower, was running on tools that could not handle the full scope of how their business actually runs, from spray mix tracking to complex end-of-month financials. No off-the-shelf platform fit, so we built Quickrose from the ground up, a single operations platform for ordering, inventory, and financial workflows, with a mobile app for the field. That rebuild was earned, because we understood the operation before we replaced the software.

This is where our motto stops being a slogan. We believe that business is built on transparency and trust, and that good software is built the same way, which is why we will tell you when a smaller move beats the big rebuild. A partner worth having is trying to solve the right problem, and will happily talk you out of the largest one.

‍

How do you know if you actually need a rebuild?

Swap "should we rebuild this?" for a sharper one: what business capability do we need that the current system cannot support? That reframe moves the whole conversation off the age of the software and onto the outcome. Maybe you need faster quoting, cleaner customer onboarding, more reliable reporting, or fewer manual handoffs. Once the capability is clear, the right technical path usually gets a lot more obvious, and it is often smaller than a rebuild.

The age of a system is a poor reason to replace it. The gap between what the business needs and what the system can do is a good one. Start there, and the choice between maintaining, modernizing, and rebuilding follows from the business need instead of the frustration.

A rebuild can be exactly the right call. It should be earned by understanding the business first, the way BeaconMedaes and Witherspoon were. Older systems often hold the history of how a company learned to operate, and part of that history needs to be left behind while part of it needs to be protected.

The companies that modernize well know the difference before they write the next version. So before you replace the whole thing, get clear on what the business actually needs, and choose the smallest responsible move that delivers a durable improvement. Sometimes that is a rebuild. Often it is something smaller, cheaper, and a great deal less risky.