# Refactor or rewrite a website people already use? How to decide

> When a site that people use daily shows its age, rewrite it or change it in stages? Three running products we changed one part at a time, and when not to.

Source: https://lastdoorsolutions.com/blog/refactor-or-rewrite-a-running-website

**For a website people already use every day, our starting point is usually to change one part at a time.** Change the part that hurts, on the structure people already know. A full rewrite puts everything that works at risk to fix the parts that do not.

Below are the three histories this view comes from, and the signs that tell you when a rewrite is the better call.

## Refactor, rewrite, rebuild: what each means

- **Refactor:** change how the code is organised while preserving its existing behaviour.
- **Rewrite:** replace the codebase from scratch, usually on a new framework.
- **Rebuild or redesign:** a new site, often with new structure, content and design at once.
- **Evolve:** our word for refactoring plus replacing one area at a time, so the rest keeps running.

## What a rewrite resets

A site that has run for years holds more than its pages. **People know where things are. Staff know how to publish.** Links from other sites point at its addresses. Search engines have learned what it is about. A rewrite needs a plan to preserve those behaviours, publishing tasks and addresses.

**Changing one area at a time gives those requirements a smaller scope,** so each change can be checked against the site as it runs.

## Change the part that hurts, on a structure people know

[TraqIT](/work/traqit) is event-management software for trade-show teams, already in daily use when we started. From February 2018 to February 2019 we redesigned it in stages.

**The first release did not move anything.** It refreshed the components on the structure users already knew, so they could adopt the change before the larger one came. The larger redesign followed. We mapped routine tasks and took out their intermediate steps. The interface was then organised around the tasks an event organiser has to finish, with testing rounds between the iterations.

The plan separated changes to familiar controls from changes to the tasks themselves. The record confirms the transitional release, but not when the task-based design went live.

## Replace one area at a time

[TwinsUK](/work/twins-uk) is the UK's largest adult twin registry, at King's College London. **We worked with it from 2012 to 2023, and we never rewrote everything at once.**

![A timeline from 2012 to 2024. Research area rebuilt from late 2012 to mid 2013. Twin Zone, a new members' site, designed and built from late 2016 to late 2017, then looked after to 2023. Research site rebuilt in two rounds in 2017 and 2018, then looked after. Repairs in 2019, 2020 and 2023.](/images/blog/twinsuk-one-area-at-a-time.png)

*TwinsUK's web tools, one area at a time, 2012 to 2023.*

- **2012 to 2013.** The research area came first. A page that was one long block of text became an interactive diagram with a page for each research area behind it.
- **2016 to 2017.** Twin Zone, the members' site, was designed in 62 screens and opened in November 2017.
- **2017 to 2018.** The research site was rebuilt: 49 screens in two rounds.
- **Over the same years.** The data access system moved from forms and email to one application, built first on WordPress and later rebuilt as a Laravel application.
- **2019 to 2023.** Repairs when they were needed: malware cleared in 2019, a search rebuilt in 2020, both sites repaired for PHP 8.1 in 2023.

**Evolving did not mean never rebuilding.** Two parts were rebuilt outright. The difference is scope: each rebuild covered one area, while the rest kept running.

## Compare each part before it goes live

[Discovery World Trekking](/work/discovery-world-trekking) has taken more than 5,000 booking requests and enquiries through its site since 2019. In September 2026 we started a design system for the site as it runs.

**We did not begin from a blank page.** We compared each part of the live site with its new version: a trip card, a badge, a price.

![The same trip card before and after. Before: white text on an orange Best Seller badge, marked 2.8 to 1, fails AA. After: the badge stays orange with dark text on the top edge of the photo.](/images/blog/badge-contrast-before-after.webp)

*One part, compared before it went live: the trip card and its badge.*

The client reviewed the new design in rounds on a preview site, and it went live on 16 October 2026. **Part-by-part comparison turns a redesign into a set of decisions a client can check, one at a time.**

## When a full rewrite is the better call

Evolving has limits, and we say so when we meet them.

| Sign | Why a broader replacement may be needed |
| --- | --- |
| **The platform gets no security updates** and cannot be upgraded to one that does | Every part sits on the risk |
| **The content model is wrong at the root** | Every new page fights it |
| **Nobody can safely change the code** | Nobody understands the legacy code, and nothing tests it |
| **The business has changed** | The site's structure describes a company that no longer exists |

**Even then, the rewrite can often run in stages behind the live site,** one area at a time, the way TwinsUK's research site and data access system were.

## Five questions to decide it

Answer these with the people who run the site every day:

1. **What exactly is wrong?** The look, the structure, the content model or the code underneath?
2. **What works well today,** and how would a rewrite protect it?
3. **Can the change ship in stages** that each make sense on their own?
4. **Who uses the site daily,** and what will they have to relearn, and when?
5. **What can be compared before and after,** so each decision can be checked?

If most answers point to one or two parts, change those parts first. If they point to the foundation, plan the rewrite, and still look for a way to ship it in stages. That is how we approach [WordPress sites that are already running](/services/wordpress).

A running site holds decisions its users and staff already depend on. A replacement needs to carry forward the ones that still matter.

## Weighing a rebuild of a site your team relies on?

Tell us what is wrong with it today. We will say which parts we would change first, and whether a rewrite is worth it.

[Talk to us about your site](https://lastdoorsolutions.com/contact?service=wordpress)