A website hosting migration is complete when visitors reach the intended site, new records are preserved and the important functions work. Seeing the homepage is not proof that forms, scheduled jobs or mail have moved correctly.
This guide covers a host change with the same domain and page URLs. A domain change needs a separate URL and redirect plan. A rebuild or CMS change introduces further work. Use the English transfer worksheet to assign checks and record observations.
Establish which services move
Website hosting, domain registration, DNS and email may have different providers. Identify website files, uploads, software, database, DNS, mailbox location, aliases, scheduled tasks, external integrations and required access.
Ask what a migration service includes. Moving a site does not automatically include mailbox content, licences or its outgoing-mail provider. Keep passwords and tokens out of the worksheet and transfer access through an agreed secure method.
Preserve a recoverable starting point
Keep a dated backup outside the environment you will change. For a typical WordPress site, files and database belong together. Neither a database export without uploads nor a website-folder copy without the database establishes a complete recovery set.
Save DNS records, redirects and configuration managed elsewhere. Prove the recovery route using a separate restore test. Stop if nobody can demonstrate recovery before the original environment is cancelled.
Test a separate copy
Use protected staging or a host-supported preview. Noindex controls indexing; it is not access protection. Prevent the copy from emailing real customers, taking live payments or running duplicate jobs.
Keep the migration separate from unplanned software upgrades or a redesign. Otherwise the cause of a failure becomes harder to identify. Test the copy's software, files, database and integrations; then check live domain, certificate and production settings separately at the switch.
Define acceptance before switching traffic
| Check | Evidence to keep | Stop condition |
|---|---|---|
| Important pages | URL, time and correct visible content | Missing or incorrect page |
| Images and downloads | Correct file opens | Broken reference or wrong version |
| Form | Identifiable test reaches the agreed destination | Success message without receipt |
| Administration | Authorised user completes the required task | Session or permission failure |
| Redirect | Old URL reaches its intended destination | Loop or incorrect endpoint |
| Background work | Recorded outcome without duplicate processing | Both environments may process it |
Fill observations, owners and open actions in the worksheet. Its empty result fields are intentional; it is a template rather than a record of a completed migration.
Plan DNS, mail and writes together
Changing nameservers can affect the entire DNS zone, not only the website. Preserve mail records if email stays with its provider. If mail moves too, plan mailbox content, aliases, clients and the mail switch separately; test sending and receiving.
Cached DNS answers mean some visitors may still reach the old environment. Agree how incoming orders, enquiries and edits are preserved through final synchronisation, a controlled write pause or another justified method. Do not leave that decision until after traffic changes.
Worked example and rollback decision
Imagine a fictional consultancy with ten WordPress pages, a brochure and a contact form. Domain registration and email stay in place; only hosting changes. The copy loads, but the test enquiry never arrives. The decision is stop: delivery not demonstrated, even though the form shows success. The operator corrects the route and repeats the test before switching.
This is a tabletop example, not a customer case. It illustrates why acceptance checks need a user outcome.
Assign one go/no-go owner and a recovery route. Returning DNS to the old host is not sufficient if new records already exist on the new host. Preserve those records before rollback. Choose a switch time when responsible people are available.
Finish with evidence and operating ownership
Check the real domain, HTTPS, key tasks and record destinations after switching. Cancel old hosting only after confirming nothing essential remains and checking any linked services. Remove temporary indexing blocks from intended public production pages.
Assign the next checks using the website maintenance checklist and maintenance cost guide. A migration does not automatically include a new website development project, and it does not guarantee unchanged search traffic.