Website Redesign vs Rebuild vs Migration: How to Choose

Redesign when the website’s message, journey, or interface needs to change but its foundation can still support the business. Rebuild when the platform, code, data model, editing system, or technical architecture prevents the required outcome. Migrate when the site moves to a different host, platform, domain, or URL structure. These are separate decisions: a project can migrate without a visual redesign, redesign without changing platforms, or combine a rebuild and migration while preserving valuable content and URLs.

This framework is for a business deciding what to request and how to compare website proposals. It is not a substitute for inspecting the current site, analytics, search data, content, integrations, accessibility, hosting, and contracts. The right path depends on what is working, what is blocked, and what the new site must prove.

Use four project paths, not one vague “redesign” label

“New website” is not a sufficient scope. A proposal should say which of these paths it includes, which assets survive, which constraints are removed, and how the team will verify the result.

Do not let one performance score decide the project

A slow page can justify investigation, but it does not automatically justify rebuilding an entire website. The delay may come from an oversized hero image, third-party scripts, a slow server response, a theme or plugin, layout instability, or heavy interaction code. Some causes are local; others are structural.

Google’s Core Web Vitals guidance defines the current metrics around real-world loading performance, responsiveness, and visual stability. That makes performance evidence useful, but the scope still comes from diagnosis. Test representative page types and important user journeys, separate field data from lab tests, and identify the cause before pricing a repair or rebuild.

The same principle applies to age. A website is not technically unfit because it looks old, and a modern visual layer does not correct broken content, inaccessible workflows, weak information architecture, or fragile integrations.

Build a preserve / change / prove ledger

At AP Works, we make the decision across five layers. For every material part of the current website, write one of three instructions:

• Preserve: this asset, behaviour, route, relationship, or piece of evidence is valuable and must survive.
• Change: this is a known constraint or mismatch, and the new scope must replace or correct it.
• Prove: this is uncertain; inspect, test, or measure it before deciding whether to keep or replace it.

This ledger prevents two expensive mistakes: rebuilding valuable parts because nobody inventoried them, and preserving harmful parts because “migration” was mistaken for a copy-and-paste exercise.

1. Business journey

List the audiences, offers, decisions, and actions the site must support. Preserve journeys that already bring qualified conversations. Change unclear positioning, dead-end pages, or forms that ask for the wrong information. Prove assumptions with approved analytics, search data, sales questions, and stakeholder evidence.

2. Content and search

Inventory pages, files, titles, headings, internal links, traffic entry points, backlinks where available, and content owners. Preserve useful technical depth and pages that answer real buyer questions. Change duplication, outdated claims, weak hierarchy, or pages with no current purpose. Prove whether a page should be consolidated, rewritten, redirected, archived, or retained.

3. Interface and accessibility

Review navigation, responsive layouts, forms, errors, focus order, keyboard operation, content structure, contrast, media alternatives, and status messages. Preserve familiar interactions that work. Change components that block users or make key tasks unclear. Prove the result with the actual end-to-end journeys, not only a homepage screenshot.

WCAG 2.2 treats conformance at the full-page level and, where a page belongs to a multi-step process, across the complete process. For a redesign, that means testing the whole quote, booking, application, account, donation, or checkout journey—not declaring success from an isolated component.

4. Platform and ownership

Document the CMS, theme or builder, custom code, database, repository, hosting, licences, accounts, environments, deployment process, backups, and handoff rights. Preserve a platform that still fits the editing and operating model. Change dependencies that prevent required work or create unacceptable lock-in. Prove who controls the domain, source, data exports, billing, recovery channels, and production access.

If the main question is which platform or ownership model fits the business, read the custom-coded website versus WordPress decision guide. That is a platform decision; this article is about deciding how much of an existing site should change.

5. Operations and integrations

Map forms, CRM routing, ecommerce, booking, payments, email, analytics, consent controls, search tools, feeds, DNS, business email records, and third-party scripts. Preserve verified connections and identifiers. Change brittle manual handoffs or unused tools. Prove every dependency in staging and again after launch, including failure and recovery paths.

Choose a repair when the defect is local

A focused repair is often the better business decision when the platform can support the required change and the risk is contained. Examples include:

• compressing or replacing heavy media and removing unused scripts;
• correcting a confusing service page or form without changing the whole information architecture;
• repairing headings, labels, focus behaviour, error handling, or contrast in a reusable component;
• creating a missing landing page within an otherwise useful content system;
• fixing a broken integration whose surrounding workflow remains valid.

A repair becomes the wrong choice when each fix exposes another system-wide limitation, the same defect exists across most templates, or the current platform cannot be safely changed, tested, maintained, or handed over.

Choose a redesign when the experience is the constraint

A redesign is appropriate when the business has changed faster than the website’s message and structure. The offer may be difficult to understand, audiences may be mixed together, navigation may reflect an internal org chart, or the visual system may no longer support the brand.

The redesign scope should identify content responsibility, information architecture, reusable page types, design-system components, responsive behaviour, accessibility acceptance tests, and the actions each important page should enable. It should also state which back-end, data, and integration work is excluded. Otherwise, a visual proposal can quietly become an undefined rebuild.

Choose a rebuild when the foundation blocks several layers

A rebuild is justified by a pattern of constraints, not by a preference for new technology. Strong signals include:

• the content model cannot represent the pages, relationships, languages, or structured data the business needs;
• core templates cannot be made responsive, accessible, or performant without replacing their implementation;
• updates depend on an unsupported theme, abandoned plugin, fragile generated code, or inaccessible vendor account;
• the site cannot connect reliably to required systems or expose clear failure states;
• ownership, deployment, recovery, or maintenance boundaries cannot be made acceptable inside the current setup;
• several user journeys, page types, and operational dependencies need coordinated change.

Rebuild does not mean discard everything. Content, routes, design cues, data, analytics definitions, and business rules may still be valuable. Reimplementation should be selective: preserve the asset, replace the constraint.

Treat migration as a risk layer across the project

A migration describes movement, not quality. Moving the same site to a new host may be a pure infrastructure project. Moving from a proprietary builder to a custom stack may require a rebuild. Moving to a new domain during a rebrand adds search, DNS, email, analytics, and communications work even if the page design remains familiar.

When URLs change, create a page-level map before launch. Google’s site-move documentation recommends preparing and testing the new site, mapping current URLs to their new destinations, enabling redirects, and monitoring both old and new URLs. It also advises changing one major variable at a time when practical.

For permanent moves, Google identifies server-side 301 and 308 redirects as signals that the destination should become canonical. Do not send a large set of unrelated old pages to the homepage. Update internal links, canonicals, sitemap entries, and campaign destinations; remove accidental staging noindex rules; retain Search Console verification; and test important old URLs directly. Google currently recommends keeping redirects for at least one year and, from a user perspective, often longer.

A hypothetical decision example

The following is a hypothetical example, not an AP Works client project, result, or performance claim.

Suppose an 80-page professional-services website has useful technical articles and stable lead forms, but the navigation hides its main services, the mobile templates are difficult to use, the theme is no longer maintainable, and editors cannot create the content relationships required for the new offer. The company wants to keep its domain and business email.

The ledger might decide:

• Preserve: the domain, email service, approved technical content, high-value URLs, form destinations, analytics events, and brand recognition.
• Change: information architecture, page templates, visual system, component implementation, content model, and deployment approach.
• Prove: which older articles still serve buyer intent, which redirects are one-to-one, whether the CRM accepts staged submissions, and whether the new journeys pass mobile, keyboard, performance, and form tests.

This is a redesign and rebuild with a same-domain platform migration—not a reason to erase the content or change every URL. The labels matter less than making each responsibility and acceptance test explicit.

Ask every proposal to show the preservation plan

Before comparing price or visual concepts, ask each team to address:

1. Which current pages, files, routes, data, integrations, and accounts have been inventoried?
2. What will be preserved, changed, consolidated, redirected, archived, or investigated?
3. Does the scope include repair, redesign, rebuild, migration, or a defined combination?
4. Who owns content decisions, copy, photography, data cleanup, redirects, DNS, email, analytics, and third-party access?
5. How will the team test representative templates and complete business journeys on desktop, mobile, keyboard, and assistive technology?
6. What is the staging, backup, launch, rollback, monitoring, documentation, and handoff plan?
7. Which outcomes are acceptance criteria, and which business results require measurement after launch?

A proposal can be visually impressive and still omit the work that protects continuity. The preservation plan reveals whether the team understands the existing business asset, not only the new design.

Define launch evidence before design begins

After launch, measure the business outcomes separately. The website ROI framework explains how to connect discovery, qualified actions, sales evidence, and gross profit without borrowing an industry benchmark.

Sources and further reading

• Google Search Central: Site Moves and Migrations
• Google Search Central: Redirects and Google Search
• Google Search Central: Understanding Core Web Vitals and Google search results
• W3C: Web Content Accessibility Guidelines (WCAG) 2.2

Explore AP Works’ approach to custom website redesigns, rebuilds, and migrations, or brief a website project →