Switching website provider: your handover checklist

1. Do you need a handover or a rebuild?

This guide concerns a business website presenting services and receiving enquiries. Shops, account systems and applications with changing data need an additional plan for transactions, users and records.

Start with the problem: outdated content, an unreliable provider, inaccessible editing or unsuitable functions. A new team can sometimes maintain the existing site. A redesign may be justified when the structure or technology no longer fits, but a provider change alone is not proof.

Wix, for example, requires its websites to run on its own infrastructure.³ Paying a designer to use a platform does not remove that platform’s hosting constraints.

2. Check contracts and rights before giving notice

List the services that stop together: web hosting, domain management, email, licences, support and account access. Confirm notice, renewal, effective end and file-delivery dates. An invoice or login does not settle copyright ownership.

For a UK commission, the Intellectual Property Office explains that copyright normally remains with the creator unless otherwise agreed in writing.² Rights elsewhere depend on applicable law and the agreement. Have unclear terms checked rather than applying UK rules to every English-speaking country.

Ask the next provider to confirm the files, licences and access needed, what can be retained and what must be rebuilt. Request a transition quote including overlap, restoration, redirections and email work where relevant.

3. Build the handover inventory

Copy this table and add an owner, expected date, evidence location and requested / received / verified status. An absent item stays “to obtain”, not “not applicable” by default.

A CMS is the system used to edit content, such as WordPress. A text export may help a rebuild, but is not a complete backup of a website to move. Check recovery methods and two-factor authentication for essential accounts. Grant individual or delegated access securely, outside the inventory document.

4. Keep the domain and protect email

Your registrar manages the domain registration. Your web host serves the site. Email can have a third provider. They do not necessarily need to move together.

Is a registrar transfer necessary?

If you control the current domain account, directing the website to new hosting may be sufficient. Confirm which registration and DNS services remain after cancellation.

For generic domains such as .com, ICANN explains transfer authorisation codes and possible locks, including circumstances where a 60-day restriction applies.¹ Country-code domains such as .uk, .ca and .au follow their registry’s rules. Ask the registrar about eligibility, fees and timing before setting the launch date. A registrar transfer and a change of registered holder are separate operations.

DNS records connect a domain to its services. Web records, email-receiving records (MX) and verification or security records serve different purposes. Changing nameservers can therefore affect much more than the website.⁵

Preserve the current records and identify which need to change. Account for their cache duration, or TTL: changing back is not always immediate.⁵

Will email stay where it is?

If email stays, preserve its subscription, access and required DNS records. Google Workspace uses MX records to receive mail; launching a new website does not by itself require replacing them.⁶

If email moves, scope it as a separate task: mailboxes, aliases, historic messages, calendars, devices and final synchronisation. Changing MX records directs incoming messages; it does not copy your mail history.⁶

Test sending and receiving with an external address, plus website form notifications. Keep the old email access until migration and final recovery are verified.

5. Preserve useful URLs and prepare redirects

Keeping the domain does not preserve visibility if important pages disappear or their addresses change. Identify useful URLs from Search Console, available analytics, links and business knowledge. If history is unavailable, record the gap and prioritise service and contact pages.

Fictional mapping example, on the same domain:

Statuses 301 and 308 indicate permanent moves; 404 and 410 indicate missing or removed content. Use permanent server-side redirects for permanent URL changes.⁷ Give each old URL a relevant final destination, avoid unnecessary chains and do not redirect everything to the home page. Google recommends keeping redirects as long as possible, generally at least a year, and warns that rankings can fluctuate during a move.⁴

When the addresses remain unchanged, no redirect is needed solely because the provider changes. Those pages must still exist and work.

Search Console’s Change of Address tool is for domain or subdomain moves, not an ordinary hosting change, same-domain path changes or an HTTP-to-HTTPS move. Check the tool’s supported cases before using it.⁸

6. Use a timetable based on dependencies

“Day 0” is the public switchover. These intervals are illustrative, not a standard delivery commitment. Contract notice or missing accounts may require starting earlier.

Choose a quieter period when the people able to fix problems are available. A weekend without support is not automatically safer. Define the fallback: who authorises reversal, what stays available and how newly received data is protected.

7. Give approval only after verification

• Domain management and renewals are confirmed.
• Required files, rights and licences have been received and tested.
• Important pages and redirects reach their agreed destinations.
• Contact and booking work on phone and desktop through to real receipt.
• Email sending, receiving and relevant history are verified.
• Public pages are accessible to search engines; test restrictions are removed from the public version.
• Measurement works and previous exports are retained.
• Backup, fallback and responsibility for incidents are clear.

After switchover, record the final checks, actual incident resolutions and handover acceptance. Remove old access after confirming what still depends on it. End each old subscription separately, retain cancellation confirmation and arrange data return or deletion as applicable. Monitor priority pages and enquiries; do not promise an unchanged ranking.

Use the monthly review template for the next improvements. If a rebuild is needed, prepare the website brief and cost comparison.