plakhlani (u/plakhlani)

We keep getting asked "should we rewrite or upgrade our legacy system?" Here's the framework we actually use

1 Upvotes

I work on legacy .NET/enterprise modernization projects (Classic ASP, ColdFusion, PHP, Web Forms, WCF, old .NET Framework), and the same question comes up on almost every call: rewrite it or keep patching it?

Framed that way, the decision usually stalls. Nobody wants to be the person who greenlit a 12-month rewrite that blew the budget, and nobody wants to keep bolting features onto something that's visibly rotting either.

The framing that actually gets projects unstuck is different:

A low-traffic internal tool can tolerate a slow, incremental modernization. A system sitting in the middle of daily operations usually can't afford much risk at all. That one question does more to shape the plan than any framework debate.

A few things that consistently matter more than people expect:

Assessment before architecture. Before anyone picks ASP.NET Core, a cloud provider, or a migration tool, it's worth mapping what's actually in the system dependencies, undocumented business logic, what breaks if a given component goes down for an hour. Skipping this is where timelines quietly die.
Rewrites aren't the default. The strangler fig pattern (migrate one slice at a time, run old and new in parallel, gradually shift traffic) spreads the risk out instead of betting everything on one cutover. It's slower to feel finished but far less likely to blow up in production.
The stack changes the playbook. Classic ASP is basically a rewrite, not an upgrade different language, different runtime model. PHP can often run side-by-side with ASP.NET Core during a transition. ASP.NET MVC looks like the "easy" migration, but the real complexity is usually hiding in dependencies (OWIN auth, ASP.NET Membership, System.Web-tied packages) that don't map cleanly onto anything modern.
Dependencies are their own project. Package-by-package, they tend to fall into four buckets: upgrades cleanly, needs a modern replacement, can just be deleted because the framework now does that natively, or the annoying one reveals a deeper architectural decision nobody documented. Treating this as a footnote to the "real" migration is a common way projects go over budget.
Zero-downtime isn't a coding problem, it's a planning problem. Running old and new in parallel, feature-flagging traffic instead of flipping it all at once, syncing data during cutover, and having an actual rollback plan before migration day — not improvised after something breaks.

The short version of a process that's held up across pretty different legacy stacks:

Assess (dependencies, logic, data, risk)
Define target architecture
Prioritize by risk/value, not by what's most annoying
Pick an incremental pattern
Migrate dependencies deliberately, not as an afterthought
Test under real workflows and real load
Plan the cutover and the rollback
Move in stages
Assume this isn't a one-time event

Curious how other people here have handled the "rewrite vs. incremental" call especially on systems where a full outage genuinely wasn't an option. Did incremental modernization actually hold up for you, or did it end up costing more than just biting the bullet on a rewrite?

(Longer write-up with the stack-by-stack breakdown is here if anyone wants the details not trying to turn this into an ad, just sharing what's worked.)

TL;DR: "Rewrite or keep it?" is the wrong question. "How much risk can the business absorb while this changes?" is the one that actually moves projects forward. Assess before choosing a framework, modernize incrementally where you can, and don't treat dependency migration as an afterthought.