Replatform or rebuild? How to decide

When a system is holding a business back, there are two ways forward, and teams agonize over which one to take. Replatform: keep the logic and the data, move them onto modern infrastructure. Rebuild: start from a blank repo and write it again. Pick wrong and you either spend a year reinventing something that worked, or you pour money into propping up a foundation that was never going to hold.

We’ve done both, more than once. Here’s the framework we use.

The question isn’t “which is better”, it’s “what’s wrong”

People frame this as a technology decision. It isn’t. It’s a diagnosis. Before you can choose the cure, you have to be honest about the disease.

Ask: if this system did exactly what it does today, but ran on modern infrastructure, would the business be happy?

• If yes, the logic is fine, it’s just slow, expensive, or hard to host, you have a replatform.
• If no, the way it works is the problem; the workflows, the data model, or the assumptions are wrong, you have a rebuild.

Most teams skip this question and jump straight to “let’s rebuild it properly,” which is how a six-week infrastructure migration turns into an eighteen-month rewrite.

When replatforming is the right call

Replatform when the system’s behavior is sound and its foundation is the problem:

• It’s slow because it’s on dated hosting, not because the logic is wrong.
• The hosting bill is climbing and modern infrastructure would cut it sharply.
• The code is dated but coherent, you can read it and understand what it does.
• The data model still reflects how the business works.

Replatforming is lower-risk because you’re preserving known-good behavior. You’re not re-litigating decisions; you’re moving them somewhere better. The classic example is a content site on aging WordPress hosting: the content and structure are fine, it’s just slow and expensive. Move it to a modern stack and you keep everything that works.

When rebuilding is the right call

Rebuild when the problem is the design, not the deployment:

• The data model fights the business, every new feature requires a workaround.
• Nobody fully understands how it works anymore, and changing one thing breaks three others.
• The workflows it enforces are the ones you’re trying to escape.
• You’d have to throw away most of the logic during a migration anyway.

Rebuilding is higher-risk and usually higher-cost up front, but a replatform that drags a broken design onto new infrastructure just gives you a faster version of your problem. Sometimes the honest answer is that the thing needs to be re-thought, not re-hosted.

The hybrid almost everyone needs

In practice the answer is rarely all-or-nothing. The strongest plan is usually: replatform the parts that work, rebuild the parts that don’t. Keep the data and the proven logic, move them onto modern infrastructure, and rebuild only the specific pieces that are broken.

This is the strangler fig pattern applied at the architecture level, you don’t have to choose between “preserve everything” and “burn it down.” You choose per-component, based on the diagnosis.

How to keep the decision honest

The trap in this decision is ego and optimism. Engineers like rebuilding (blank repos are fun). Stakeholders like the idea of “doing it right this time.” Both biases push toward the expensive option.

The corrective is to scope both paths concretely before committing. What would a replatform involve? What would a rebuild? Put real time and cost estimates next to each. Nine times out of ten, the honest estimate makes the choice obvious, and it’s cheaper than the exciting one.

That diagnosis is the first thing we do on any modernization engagement: we spend real time understanding what’s wrong before we recommend a path, because the scope should reflect reality, not optimism. If you’re weighing this decision, let’s talk it through.