Modernising legacy SaaS without a big-bang rewrite
A staged modernisation, starting with the customer-facing experience, can give an ageing product a future without betting the business on a multi-year rewrite.
Plenty of successful B2B SaaS products are quietly ageing. The software works well and customers rely on it, but the codebase is a decade or two old, the people who built it are heading towards retirement, and the platform was designed for a different era. Sooner or later the same question arrives: how best to carry a proven product forward.
The instinct is often to rebuild from scratch. On a recent engagement, the big-bang option, a complete rewrite, carried a large six-figure price tag and multiple years of work before the business would have seen anything. For a product that already earns its keep, that’s an enormous amount of risk to carry in a single bet.
There’s usually a calmer route. A phased approach reduces that risk: stakeholders can see where the project is heading, and there’s room to steer and correct as it goes.
The real risk
It’s tempting to frame the problem as the user interface, since a dated, non-responsive screen is usually what prompts the conversation. But the interface is only a symptom. The deeper risks tend to be structural.
Many products of this vintage are built on ASP.NET Web Forms, the classic .aspx model. Web Forms has no direct path to modern .NET: ASP.NET Core doesn’t support it. The framework, not the styling, is what limits a product’s future.
Two risks usually compound it. The developers who understand these systems are often near retirement, and the pool of engineers fluent in Web Forms keeps shrinking. Hosting and resilience tend to be dated too, having grown over years rather than by design.
Why a full rewrite is usually the wrong move
A from-scratch rewrite is the most expensive and least certain option on the table. Joel Spolsky famously called it ‘the single worst strategic mistake that any software company can make’, because it discards years of fixes and edge cases quietly encoded in the old system. Meanwhile the existing product still needs maintaining, customers still expect progress, and nothing guarantees the replacement will match what the original got right.
For a small company, several years without visible return is a commercial risk in itself. Momentum matters for both the team and the client. A big rewrite can bring a product to a halt, and that’s a heavy price to carry.
Modernising the edges first
A staged approach changes the risk profile entirely. Instead of replacing everything at once, the new and the old run side by side, and functionality moves across in slices. This is the strangler-fig pattern, named by Martin Fowler and documented as a standard approach by Microsoft: a new system grows around the old one until the old one can be retired.
A sensible first slice is often the part customers actually feel. A progressive web app (PWA) can deliver a responsive, installable, offline-capable experience using standard web technology rather than a separate native app. It talks to the existing backend through a clean JSON API, so the business logic that already works carries on working. The backend can then be modernised behind that API, slice by slice, on its own schedule.
The pay-off is real value in front of customers early, and a path that can pause or change direction without leaving the business stranded.
Where AI fits
AI has a genuine role here, though not the one the hype suggests. An established product doesn’t need to become an ‘AI product’. The value is in the delivery.
On this kind of engagement, AI agents make it possible to explore an unfamiliar two-decade-old codebase in days rather than weeks, and to build quick proofs of concept while the options are still being weighed. The same tools then accelerate the delivery itself: drafting wireframes, turning them into specifications, generating tests, and helping write the code for each slice. That’s much of what makes a staged rewrite affordable for a small team. Used this way, AI lowers the cost and risk of modernisation, without adding a single AI feature nobody asked for.
AI-assisted development sits on a spectrum, from hand-written code at one end to one-shot ‘vibe coding’ at the other. Generated code is already part of how software gets built, and has been for a while. The question for a product that has to last isn’t how much of it AI can produce, but whether the team still owns and understands what ships. Longevity depends on that ownership, not on the volume of code.
A bit of groundwork makes that ownership easier to keep. Clear requirements and a documented house style give the agents conventions to follow, so new code matches what’s already there rather than drifting. The architecture still needs to be designed and understood up front. AI changes how quickly each slice gets built, not the judgement about what to build or how it fits together.
Start with a map
None of this works without understanding the product first. The early work on an engagement like this isn’t writing code. It’s learning the industry, the customers, and the existing system well enough to judge what’s worth keeping and what isn’t. A modernisation roadmap is only as good as that picture.
For an established product facing this decision, the message is reassuring. There’s usually a way forward that doesn’t involve betting the company on one multi-year rewrite.
If a long-standing product is reaching this point, a short exploratory conversation is a sensible first step.
References
- StranglerFigApplication, Martin Fowler
- Strangler Fig pattern, Microsoft Learn
- Migrate from ASP.NET Framework to ASP.NET Core, Microsoft Learn
- ‘Things You Should Never Do, Part I’, Joel Spolsky
- Progressive web apps, MDN Web Docs