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

• 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.

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.

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.

TwinsUK 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.

• 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.

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 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.

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

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.

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.

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