New Website or Modernise the Existing One?
The choice is not simply between a visual refresh and an expensive rebuild. First identify whether the problem is content, customer paths, technology, security, editing capability or a combination of these.
Contents
- Assess the current site
- Decision criteria
- When to modernise
- When to rebuild
- Migration and redirects
- Reducing decision risk
- Rebuild plan
Assess the current site
Inventory URLs, important landing pages, forms, integrations, analytics, content owners and customer complaints. Test core journeys on a phone and desktop. Check whether the platform is supported, access is controlled, backups exist and editors can make safe updates.
Separate symptoms from causes. An old-looking site may only need clearer content and mobile improvements. A new theme cannot fix an unclear offer or broken enquiry handling. See why a website does not generate enquiries for a structured diagnosis.
Decision criteria
Modernisation is usually suitable when the technical foundation is supported, secure and extensible, while content, components, mobile views or selected integrations need work. A rebuild is more credible when the offer and structure no longer match the business, the platform is unsupported or fragile, editing is persistently difficult, or required functions exceed the architecture.
When to modernise
Keep the existing foundation when key URLs can remain, access is clear and targeted improvements can solve the problem. Update service structure, content, forms, priority performance issues and event tracking in stages. Do not keep patching if every change needs a workaround or another fragile extension.
When to rebuild
Rebuild when business positioning has changed substantially, the information architecture cannot support customer paths, technology creates ongoing risk, or accessibility and editing are blocked by the foundation. A new site should simplify the experience, not copy every old page into a new visual layer. The wider process is covered in how to build a website step by step.
Migration and redirects
Migration is about preserving useful value, not copying every page. Classify each old page: improve and retain, merge, archive or remove. Consider freshness, user value, traffic, links and business importance. Collect media, metadata, headings, forms and integrations as well as body text.
Create a redirect map with each old URL, its closest relevant new URL and any exception. Do not point every old page to the home page. Test for loops, chains and correct statuses before launch. Preserve analytics continuity with the same consent model, valid identifiers and event definitions, and annotate the migration date. Google's URL change migration guidance explains the technical principles.
Reducing decision risk
Treat the choice between modernisation and a new site as a hypothesis that can be tested. For example: “the current platform can safely support a revised service structure and form without losing valuable URLs,” or “the unsupported architecture requires workarounds for every change.” Attach evidence to the claim: known technical constraints, a real content-editing attempt, mobile testing, update and backup records, and feedback from people who use the site day to day.
Run a small proof of concept before committing to a wide scope. In a modernisation, that could mean improving one representative service page together with its mobile view and form. In a rebuild, it could mean a navigation prototype, a service-page component and a partial content-import test. The goal is not to produce a free part of the whole site; it is to test the critical risks around editing, performance, accessibility, integration or migration.
Migration is not only a technical activity. The offer owner should approve which text still represents the business. Marketing or sales should identify pages used in campaigns and referrals. IT should confirm access, domains, DNS, email, forms, integrations and backups. The analytics owner should identify what is measured and which event definitions must continue. Without that collaboration, a project can preserve the visual layer while losing the operational process.
Separate responsibilities for materials and approvals in the plan. Agree who supplies text, photography, legal information, policies, translations and access; who approves design; and when a scope change needs a decision. Rebuilds often attract “while we are here” feature requests. Put them in a separate backlog and assess their purpose, risk and launch impact rather than mixing them with mandatory migration work.
Prepare a rollback or rapid-recovery plan before switching the domain. Not every change can be reversed with one click, so record contacts, configuration backups, the previous-site version, an on-call owner and test order. Ensure a staging environment is not indexed and that test form messages cannot reach customers. On launch day, a short list of critical checks is safer than relying on collective memory.
Do not judge SEO or conversion prematurely after release. First resolve 404s, broken redirects, form failures and measurement inconsistencies. Then monitor important URLs and traffic sources carefully against the period before the change. Ask the team whether the offer is easier to update, whether visitors understand its scope sooner and whether information needed before a call is accessible. These operational signals help establish whether the selected path has worked.
Rebuild plan
Define goals and audiences; inventory URLs, content and functions; design the new structure; prepare content and mobile components; implement technical SEO, analytics and consent; test the redirect map; then launch and monitor 404s, indexing, forms and important events. For help scoping the work, see website development services.