Rebuild or Refactor? What to Do with Old Code

Every developer wants to rewrite the old system. Every business owner fears the cost. Both instincts are sometimes right. I have rescued enough legacy Laravel and PHP apps to have a simple framework for this call.

Refactor step by step when

• The app works and makes money today
• Problems are localized: slow pages, messy modules, missing tests
• You cannot pause new features for months
• The team understands the current system, even if they dislike it

Rebuild when

• The framework or language version is dead and unpatchable
• Every small change breaks something else and takes weeks
• The business changed and the data model no longer matches reality
• Security holes are structural, not patchable

The middle path that usually wins: strangler pattern

Keep the old system running, build replacements module by module, and route traffic over gradually. No big-bang launch, no six-month feature freeze:

# Route new modules to the new app, everything else to legacy
# nginx example
location /billing   { proxy_pass http://new-app; }   # rebuilt
location /reports   { proxy_pass http://new-app; }   # rebuilt
location /          { proxy_pass http://legacy-app; } # not yet

# Repeat until location / points at the new app, then retire legacy

Why rewrites go over budget

The old code silently contains years of edge-case fixes: the customer with two accounts, the invoice rounding rule, the timezone bug from 2021. A rewrite re-discovers them one production incident at a time. Budget for that, or strangle module by module and keep the old system as the reference.

How to decide in one afternoon

List your ten most-wanted changes. Estimate each in the current codebase versus a fresh one. If most changes are painful mainly in one or two modules, refactor those modules. If every single change fights the whole system, plan the strangler rebuild.