Insights
Rebuild or modernize? Decide for each capability what users will experience (preserve, redesign, replatform or retire), then choose the engineering route. Don't decide for the whole product at once.
Don't decide for the whole product at once. Split it into the capabilities customers use, and decide for each one what the user will experience: it stays as they know it, it works differently, it looks the same on a new foundation, or it goes away. Then choose the engineering route, rebuild included, that delivers those outcomes.
Last reviewed September 29, 2026.
Those four outcomes are preserve, redesign, replatform and retire. They are what a customer can actually notice. Everything else in a modernization plan is how you get there.
Should we rebuild or modernize our legacy software?
The question compares two engineering routes, and customers experience neither of them. They experience whether the report they run every Monday still works, whether the screen they know by heart has moved, and whether the export another team depends on still arrives.
The widely used modernization frameworks are organized around code and infrastructure. AWS's seven migration strategies (retire, retain, rehost, relocate, repurchase, replatform, refactor) describe what happens to a workload. They are good at that job. They say little about what a person using the software will lose, relearn or keep, because that is not what they are for.
So a team can pick "rebuild" or "refactor" with care and still leave the user outcome undecided. That undecided part is where damage can happen, as the examples below show.
A rebuild is not a fifth user outcome. It is an engineering route, and every capability inside a rebuild still lands in one of the four. The useful test of a rebuild plan is whether it can say which.
The four things a user can experience
| Outcome | What the user notices | Choose it when | What to prove before release |
|---|---|---|---|
| Preserve | Nothing. The capability works as it did. | People depend on the behavior and it still does its job, even if code or surrounding screens change. | The same inputs give the same results, including edge cases, exports and permissions. |
| Redesign | The task works differently: new flow, new layout, new terms. | The workflow or information structure is what now limits the work, and the underlying model still holds. | Existing users can complete their real tasks in the new design, not only new users in a test. |
| Replatform | Ideally nothing. The foundation underneath moves. | Hosting, framework, vendor support or security limits drive the change, not the experience. | Behavior, performance and data meaning survive the move in real conditions, not only in a lab. |
| Retire | The capability is gone, with notice and, where needed, an alternative. | Its value no longer justifies running it, and you know who still relies on it. | Every dependent has been found, told and given a path; retained records are handled. |
Two of these are meant to be invisible (preserve and replatform), one is meant to be visible and better (redesign), and one is a deliberate loss (retire). A large program can need all four at once, across different parts of the product.
The table has a practical consequence. If an outcome is meant to be invisible, the acceptance test is sameness, checked by the people who use the software. If it is meant to be visible, the acceptance test is whether existing users are better off after the adjustment period. Those are different tests, run by different people, and a plan that doesn't say which one applies to each capability cannot run either properly.
The damage can come from an outcome nobody chose
Some failures that reach customers are not bad choices among the four. They are outcomes that happened without being chosen: a capability meant to be preserved that quietly became a retirement, or a platform move that became a redesign because the new foundation came with a new interface.
A rebuild that retired features by default. In May 2024 Sonos released a rebuilt mobile app. Tom Conrad, then its interim CEO, later told Wired that a set of lesser-used features had not been implemented on the new software platform, and that the company launched intending to add them in fast-follow releases, as reported by 9to5Mac. He also said the company would not have shipped had it understood how the software would perform in customers' homes. In the terms of this framework, capabilities that users expected to be preserved were, in effect, retired for an unknown period.
The way back had also closed. In August 2024 then-CEO Patrick Spence wrote that he had hoped to re-release the old app as an alternative, and explained in a Reddit AMA, as reported by PCMag, that speaker and cloud software had changed since launch, so that "re-releasing S2 would make the problems worse, not better." This is a consumer product, not B2B software, but the mechanism transfers: once the platform under the old experience changes, keeping the old experience alive as a fallback is itself work that has to be planned.
A replatform that was supposed to be invisible. In April 2018 the UK bank TSB moved its customer services onto a new IT platform. According to the Financial Conduct Authority, the data itself migrated successfully, but the platform immediately experienced technical failures; all branches and a significant proportion of its 5.2 million customers were affected, and it took until December 2018 to return to business as usual. The FCA and the Prudential Regulation Authority fined TSB £48.65 million, citing failures to organize and control the program and to manage risk from its critical IT supplier. A platform move that was meant to be invisible to customers became highly visible to them for months.
Neither case says rebuilds or platform moves are wrong. They show that the user outcome has to be decided and then tested as its own requirement, separate from whether the engineering work is finished.
Why "preserve" is harder than it sounds. Joel Spolsky's 2000 essay on Netscape's rewrite argued that old code holds bug fixes that each took real-world use to find, and that starting over throws that knowledge away. Hyrum Wright's observation about APIs, now called Hyrum's Law, makes a similar point from the dependency side: with a sufficient number of users of an API, all observable behaviors of a system will be depended on by somebody. The same reasoning applies to people who use the product. A written specification is unlikely to capture all of these dependencies, and some surface only when someone's workaround stops working.
Why "preserve everything" is also wrong. Martin Fowler, arguing for gradual replacement over rewrites, notes that it is often hard to figure out the details of existing behavior and that "much of that behavior is stuff that isn't really wanted" (Strangler Fig, 2024). Some behavior deserves retirement. The point is to retire it on purpose, knowing who relied on it, not to discover the retirement in support tickets.
How to assign an outcome to each capability
Work at the level of a capability a user would name: creating a quote, approving an order, running a saved report. A code module is the wrong unit, because users don't experience modules. Then work through these questions for each one.
- Who depends on it, including people who never log in? List the direct users, then the downstream ones: the finance team that receives the export, the integration that reads the file, the customer contract that names the report. Hyrum's Law predicts this list is longer than the documentation suggests.
- What evidence do you have, and what is unknown? Usage data, support history and watching people work each show something different. Low usage is a reason to investigate retirement, not proof that nobody needs it. Record unknown as unknown.
- Is the pain in the experience or in the foundation? If people struggle with the task, that points to redesign. If the platform blocks change, security or support, that points to replatform. If both, consider sequencing them rather than bundling them. AWS gives similar advice for large cloud migrations on complexity grounds, recommending that teams move the application first and modernize it after the move. The user-side reason is simpler: when a foundation change and an interface change ship together and something breaks, it is harder for users and support to tell which one caused it.
- If it changes, what does a user lose, even temporarily? Habits, saved configurations, positions in a workflow and familiar terms all count. Google researchers Aaron Sedley and Hendrik Müller (CHI 2013) describe change aversion as discomfort when something familiar is replaced with something unfamiliar, and separate it from difficulty caused by design flaws. After a redesign, ask which one you are seeing. Aversion tends to ease as the new version becomes familiar; a lost capability doesn't.
- What is the way back if the outcome fails? For preserve and replatform, that may mean running old and new paths side by side for a period. Sedley and Müller's list of measures for the Google Drive launch includes letting users switch between the new and old interface. Their paper is a single case study, and they say controlled experiments would be needed to isolate each measure's effect, and the Sonos case shows the reverse: once the fallback is gone, every defect lands on the customer.
- Who accepts the outcome? Name the person who signs off that a preserved capability really is the same, or that a retirement has reached every dependent. For a replatform, that should include someone who uses the software every day, not only the team that moved it.
The result is a map of the product with one of four outcomes against each capability, the evidence behind it and an owner. That map is the brief for the engineering decision, not a substitute for it.
When a rebuild is the right route
A rebuild can be the right call. It is most defensible when the existing foundation blocks outcomes you need, for example when capabilities you must preserve can no longer be kept running safely or supported, or when the redesigns your customers need cannot be built on the current structure. A rebuild justified mainly by an interface that looks old is weaker, because an old-looking interface is a case for redesign, which doesn't require a new codebase.
A rebuild plan is ready to fund when it can show, for every capability in scope, which of the four outcomes the user will get, how sameness or improvement will be tested, and how old and new will coexist until the old path can be retired. Fowler's argument for the strangler fig approach is that replacing a system gradually, piece by piece, reduces risk and delivers value sooner, even though the temporary architecture costs something. The four-outcome map makes those pieces easier to define, because each one has a stated user result.
This framework has limits. It does not settle engineering constraints: an unsupported platform or a security requirement can force a replatform whatever users would prefer. It does not estimate cost or effort. And it depends on evidence about how people actually use the product, which a team may have less of than it assumes. What it does is keep the user outcome from being decided by default.
Where this work sits
To work through the options for one capability on your own, the free application modernization options worksheet records the evidence and transition cost for each route and the next test before you commit. If your team is still disputing which intervention is justified, an Application Modernization Assessment maps the capabilities in scope, compares the viable options, records the transition work a target-only plan leaves out and defines the first implementation test.
Tcules applies the same thinking in its own work. In its work with Benchmark Gensuite, Tcules redesigned a high-use scope selector inside an established enterprise suite into three views, aiming to preserve the orientation that established users relied on, and tested the direction as coded prototypes. That case stops before customer release, so it shows the method rather than an outcome. When the direction is already agreed, legacy software modernization covers the design and engineering work, and product modernization defines the wider term.
