Replatforming a legacy web app

Most legacy web apps do not die. They get slow, expensive to change, and scary to deploy, and then someone finally asks whether it is time to replatform. That decision is usually framed as a technical one, but the real questions are about money, risk, and how much your business can tolerate being in motion while the work happens. Here is how to think about it without getting talked into a year-long rewrite you will regret.

What "replatforming" actually means

People use the word to mean three different things, and conflating them is where budgets go to die.

Rehosting is moving the same app to better infrastructure. Same code, new servers. Cheap, fast, low risk, and it solves almost none of the problems that made you want to replatform in the first place.

Replatforming in the honest sense means keeping the product roughly the same but changing meaningful parts of the stack: swapping a jQuery front end for React or Next.js, moving from a PHP monolith to a Node and TypeScript API, migrating from a hand-rolled ORM to Postgres with Prisma, or pulling business logic out of a 4,000-line controller.

Rewriting is starting over from a blank repo. This is the most expensive option, the riskiest, and the one founders reach for emotionally because the old code feels gross. Resist it unless the old system is genuinely unmaintainable, and be honest about whether "unmaintainable" means "the original team left and nobody documented anything."

Most projects that succeed are replatforming, not rewriting. You keep the parts that work, replace the parts that hurt, and never have a six-month window where you ship nothing new.

The big-bang rewrite trap

The classic failure mode goes like this: the team decides the old app is beyond saving, freezes feature work, and starts building a fresh version in parallel. Meanwhile the business keeps needing changes, so the old app gets patched anyway. Now you are maintaining two systems, the rewrite keeps discovering edge cases nobody documented, and twelve months in you have a new app that does 80 percent of what the old one did and a sales team asking why nothing shipped.

The alternative is the strangler pattern, named after the strangler fig that grows around a tree and slowly replaces it. You put the new system in front of or alongside the old one and migrate functionality piece by piece, route by route, while everything stays live.

A practical version with Next.js looks like routing specific paths to the new app and letting everything else fall through to the legacy system:

// next.config.js
module.exports = {
  async rewrites() {
    return {
      // New code owns these paths
      beforeFiles: [
        { source: "/dashboard/:path*", destination: "/dashboard/:path*" },
        { source: "/billing/:path*", destination: "/billing/:path*" },
      ],
      // Everything else still goes to the old app
      fallback: [
        { source: "/:path*", destination: "https://legacy.internal/:path*" },
      ],
    };
  },
};

You migrate one slice, ship it, watch it in production, then take the next slice. If something breaks, the blast radius is one feature, not the whole product. You can stop the project halfway and still have shipped real value, which is something a big-bang rewrite can never claim.

Timelines: what is realistic

Anyone who quotes you a firm timeline before seeing the code is guessing or lying. That said, here are rough shapes based on the kind of app a small product team typically runs.

A focused front-end replatform (modernizing the UI layer, moving to React or Next.js, leaving the back end mostly intact) tends to run two to four months for a real product with a few dozen screens.

A full stack replatform with the strangler approach (new API in Node and TypeScript, Postgres migration, front end rebuilt incrementally) is more like four to nine months, and it ships value the whole way through rather than at the end.

A genuine ground-up rewrite of a mature app is a nine-to-eighteen-month commitment, and the honest version of that estimate has a wide error bar because the old system always hides surprises.

The single biggest schedule risk is not writing code. It is data. Migrating years of accumulated, inconsistent, partially-documented production data is where projects quietly lose months. Budget real time for it and write the migration scripts early, against a copy of real data, not a clean fixture.

Rough cost ranges

We will be clear that these are ballpark figures, not a quote, and they swing hard with scope, data complexity, and how much institutional knowledge already walked out the door.

A front-end-focused replatform with a senior team usually lands somewhere in the low tens of thousands. A full stack strangler-pattern project commonly runs into the mid five to low six figures depending on how many slices there are and how gnarly the data is. A full rewrite is open-ended, and if someone gives you a precise number for one before discovery, treat that as a warning sign rather than reassurance.

The cheaper insurance policy is a short paid discovery phase, often one to two weeks, where an engineer reads the code, maps the data, and tells you what the real project looks like. That small spend prevents the expensive kind of surprise.

What to watch out for

No tests means no safety net. If the legacy app has no automated tests, the first real work is adding characterization tests around the behavior you cannot afford to break. Skipping this feels faster and is not.

Hidden integrations. The payment webhook, the nightly export to an accounting system, the one report a single big customer depends on. These never show up in the spec and always show up in production. Ask early who consumes data from the app.

Feature parity creep. "While we are in here" is how a four-month project becomes a year. Replatform first, improve second. Keep a separate backlog for the shiny ideas.

The team that knows why. Old code is full of weird decisions that were correct at the time. If the people who made them are still around, get their knowledge out of their heads before they leave. If they already left, slow down and budget for archaeology.

SEO and URLs. If your app has public, indexed pages, preserve URL structure and set up redirects. A replatform that quietly tanks your search rankings is a business problem wearing a technical costume.

Takeaway

Replatforming a legacy web app is mostly a risk-management exercise, not a coding one. Prefer incremental migration over the big-bang rewrite, pay for a short discovery phase before committing real money, treat data migration as the hard part it actually is, and protect the behavior your business already depends on. Done that way, you ship value the whole time and never bet the company on a single launch day.

If you want a second opinion on whether your app needs a rehost, a replatform, or an honest rewrite, that is the kind of question we like answering.