Migrate, Rebuild or Refresh? A Practical Way to Decide

Most website conversations start with a feeling: the site looks dated, editing is slow, or someone has raised a concern about the software underneath it. Feelings are a good starting signal, but they make a poor project brief. Before choosing between a migration, a rebuild or a refresh, it helps to name the actual problems and sort them by where they live.

Three different kinds of change

A refresh changes how the website looks and reads while keeping the platform, the content model and most of the templates. New typography, updated imagery, clearer calls to action and rewritten key pages all fit here.

A rebuild keeps the same general platform family but replaces the theme, templates or custom code. Teams often choose this when the underlying CMS is acceptable but years of patches have made the front end fragile.

A migration moves content, URLs and functionality to a different platform or architecture. It is the largest of the three because every page, form and integration has to be accounted for on the other side.

Sort your problems by layer

Write down every complaint you have heard about the website, then place each one in a layer:

• Presentation: layout, colors, imagery, mobile readability, outdated messaging.
• Content: missing pages, duplicated pages, unclear structure, stale information.
• Editing: how hard it is to publish, preview, schedule or reuse content.
• Functionality: forms, search, bookings, logins, payments, integrations.
• Platform: the CMS or framework version, its extensions, the language runtime, hosting and how updates are applied.

If nearly everything sits in presentation and content, a refresh is often enough. If the platform layer keeps appearing, or the editing layer is blocking your team every week, a rebuild or migration deserves a serious look.

Questions that point toward a migration

Some patterns tend to justify moving rather than polishing:

1. The site depends on extensions or custom code that nobody on the team can confidently update.
2. Routine updates are avoided because they have broken things before.
3. The business wants capabilities the current platform handles awkwardly, such as structured content reused across pages or a faster editing workflow.
4. The team wants to reduce how much server-side PHP the public website relies on and the long-term maintenance that comes with it.
5. Hosting arrangements are unclear, and nobody is sure who owns access.

None of these automatically means migration is the answer. They mean the platform itself is part of the conversation.

Questions that point toward a refresh

On the other hand, a refresh is usually the better investment when:

• Content is reasonably organised and editors are comfortable with the CMS.
• The platform is maintained and updated on a regular schedule.
• The main complaints are about first impressions, messaging or mobile layout.

A well-run refresh can buy several years of useful life, and there is nothing wrong with choosing it.

Cost the hidden work honestly

Whichever path you choose, list the work that rarely shows up in a first estimate: redirect planning, form testing, image optimisation, accessibility review, analytics configuration and content clean-up. These tasks exist in all three paths, and skipping them is where many projects lose search visibility or frustrate visitors.

Make the decision with evidence

Bring three things to the decision meeting: a list of your top ten pages by business value, a list of every form and integration, and a short description of how content gets published today. With those in hand, a scoping conversation can be specific about what moves, what changes and what stays. If you would like a second opinion on which path fits, a preliminary review is a sensible next step before anyone writes a line of code.