Website redesign and migration checklist for UK businesses

1. Decide whether to repair, redesign or move platform

Start with an observable problem: the menu is hard to use on a phone, the enquiry form fails, services are out of date or the platform cannot support the required shop. A specific problem makes it possible to compare a targeted fix with a larger rebuild.

Keep the current design and platform when they can support the necessary improvement. A redesign suits a wider change to content or customer journeys. Consider a platform move when editing, checkout, integration or maintenance requirements cannot reasonably be met in the existing setup. Ask for the reason, the work involved and what your team will maintain afterwards.

2. Make a page and connection inventory

Create one row for each current page with its URL, purpose, content owner and proposed action: keep, improve, merge or remove. Note pages that receive enquiries, search visits or useful external links where you have records. Include documents and images that customers still need.

Alongside that list, record the domain account, hosting, business email provider, booking destination, payment provider and enquiry inbox. Identify the account owner and who can approve changes. Passwords, customer records and private messages do not belong in this planning sheet.

• Keep a restorable backup or export, and confirm what it actually contains.
• Record the current enquiry and booking journey before changing it.
• Save dated performance and search reports for comparison, where available.
• Agree how content changes made during the build will reach the new website.

3. Map changed URLs to useful destinations

Preserve a useful page address when there is no reason to change it. If an address must change, record its closest relevant replacement and plan a direct permanent redirect. Do not redirect every removed page to the homepage simply to avoid an error page.

The example table below is an illustrative salon migration worksheet, not a report about a client project. It separates an unchanged page, a renamed page, a genuinely merged page and a discontinued service. The correct action depends on whether a useful equivalent exists.

Update internal links, canonical URLs and the sitemap to use the final addresses. Test old links as well as new ones. Google recommends server-side permanent redirects, such as 301 or 308, when URLs move; a redirect plan does not guarantee unchanged rankings.

4. Check email, booking and checkout separately

A working homepage does not establish that business email still works. Record the existing email-related DNS settings and agree which website settings need to change with the people managing those accounts. Test sending and receiving mail after the planned change.

For bookings, follow the actual customer route into the agreed provider and check the correct business, service and confirmation step. A preferred-date enquiry is different from reserving an available appointment.

For an online shop, agree how products, variants, delivery rules and customer or order records will be handled. Use the payment provider's appropriate test workflow to check successful, failed and cancelled payments. Confirm that an order reaches the merchant's system once, and agree any controlled live check separately. A payment button alone is not a completed shop.

5. Review the replacement before release

Review the important page types on a small screen and a larger screen. Use the menu, read a long service title, open and close the assistant, and complete a labelled test enquiry. Check where it arrives and whether the visitor receives an understandable confirmation.

A private preview should stay out of search results. Before releasing the production website, check that public pages are accessible, required noindex restrictions have been removed and the production canonical addresses are correct. Keep private account and administrative pages restricted.

Give the business owner a short acceptance record: what was checked, which environment was tested, the outcome and any remaining dependency. Do not describe a form preview, opened WhatsApp link or demo appointment as a submitted lead or real booking.

6. Assign launch and recovery responsibilities

Agree who releases the website, who can change its settings and who checks incoming enquiries afterwards. Decide what would justify restoring the previous version, such as a broken essential checkout or a widespread page failure. A recovery plan should explain how new enquiries or orders will be retained.

After release, open representative old and new URLs, check redirects, submit the current sitemap through the relevant webmaster account and review indexing reports as they update. Investigate missing pages and customer reports rather than repeatedly submitting the same URLs.

Keep a record of enquiries and completed work separately from visits. Compare a consistent period and account for changes in campaigns, demand and content. A redesign can affect search visibility while it is processed; neither launch approval nor a successful test establishes a future ranking.

Send Webora a migration brief

Send your current website, the issue to solve, the platform if known, the pages or connections to retain and your target date. We can then discuss a focused improvement, a replacement business website or a separately scoped migration.

A six-to-seven-page replacement may fit Webora's £400 package when the agreed functions fit its scope. Product migrations, account systems, large content moves and additional integrations need their own quote and timetable. Domain access, hosting coverage, renewals and support are confirmed in the written arrangements.

Keep this comparison handy