platform modernizationdevelopment strategydrupal

When to Modernize Your Platform vs. Rebuild From Scratch

Every few months, someone reaches out with the same problem: their website or application is slow, hard to maintain, and painful to deploy. The codebase has been touched by multiple developers over multiple years. Nobody wants to work on it. And the first instinct is always the same.

“We need to rebuild the whole thing.”

Sometimes that’s the right call. But more often than not, it’s an expensive mistake.

The rebuild instinct

Rebuilding feels decisive. It’s a clean slate. You get to pick a modern stack, throw away all the legacy mess, and start fresh. On paper, it sounds like the obvious answer.

In practice, rebuilds are where budgets go to die.

Here’s what usually happens:

  • The rebuild takes 2-3x longer than estimated
  • The old system still needs to be maintained in parallel
  • Features get cut from the new version because time runs out
  • The team ends up with two systems to support during the transition
  • After launch, you discover the old system had edge cases and business logic nobody documented

We’ve seen this firsthand on enterprise platforms — a “quick rebuild” turns into an 18-month project that still doesn’t cover everything the old system did.

When modernizing makes more sense

Modernizing means improving what you have incrementally. You keep the system running, fix the worst problems first, and upgrade the architecture piece by piece.

This approach works well when:

  • The core business logic is sound — the system does what it needs to do, it’s just slow or hard to maintain
  • The platform is still supported — if you’re on Drupal 9, upgrading to Drupal 10 is a far better investment than rewriting in a new CMS
  • The team can’t afford downtime — modernizing lets you ship improvements continuously instead of waiting months for a big-bang launch
  • Nobody fully understands the old system — if the original developers are long gone and there’s no documentation, you’re going to miss things in a rebuild. Modernizing forces you to understand what’s there before changing it
  • Budget is constrained — modernizing $30k worth of targeted improvements can deliver more business value than a $150k rebuild

When you actually should rebuild

Rebuilding is the right call when:

  • The technology is truly dead — no security updates, no community, no path forward. Drupal 7 end-of-life is a real example
  • The architecture fundamentally can’t support what the business needs — you need real-time features and you’re on a stack that can’t handle them
  • The codebase is genuinely unsalvageable — not just messy, but architecturally broken in ways that can’t be incrementally fixed
  • You’re changing the product entirely — if you’re not just improving the existing system but building something fundamentally different, a rebuild makes sense

How to assess what you have

Before making the call, do an honest assessment:

  1. What are the actual pain points? List them specifically. “It’s slow” isn’t good enough. Where is it slow? Page load? Deployments? Content editing? Each problem might have a targeted fix
  2. What’s the deployment situation? Sometimes the biggest improvement isn’t rewriting code — it’s setting up proper CI/CD so your team can ship changes confidently
  3. Is the platform still maintained? Check if your CMS, framework, or language version is still receiving security updates
  4. What would break if you started over? Integrations, data migrations, SEO equity, user workflows — these all have real costs in a rebuild
  5. What’s the business actually asking for? Often the stakeholders don’t care about the tech stack. They want the site to load faster, the content team to publish easier, or the data to flow correctly. Those might be fixable without rebuilding anything

The middle path

The best outcomes we’ve seen usually involve a phased approach:

  • Stabilize the most critical problems first
  • Set up modern development and deployment practices
  • Upgrade the platform version if possible
  • Refactor the worst parts of the codebase incrementally
  • Plan a future migration only after you fully understand what you have

This isn’t as exciting as a clean-slate rebuild. But it’s predictable, lower risk, and usually delivers business value faster.

The bottom line

If your platform is painful but functional, modernize first. Fix deployments, upgrade versions, improve the worst code, and get stability. You can always rebuild later with a much better understanding of what you’re replacing.

If the technology is dead, the architecture is fundamentally broken, or the business needs have completely changed, then rebuild — but go in with realistic timelines and budget.

The expensive mistake isn’t picking the wrong approach. It’s making the decision based on frustration with the current system rather than a clear assessment of what it would actually take to fix it.