Moving to another host is a routine operation that only becomes a problem when rushed. The main rule: the site has to run on the new server and be verified before the domain is switched. Below is the order in which visitors notice nothing.
When a move is actually needed
There are few valid reasons and all of them are measurable. A slow server response that site optimisation does not fix. Regular outages or hitting plan limits. An outdated PHP version the host will not update, which blocks platform upgrades. No backups, or no way to restore from them. Support that does not answer during an incident.
If none of those applies and the site merely feels slow, measure where the time goes first. A move does not speed up heavy pages: if the cause is images and scripts, new hosting changes nothing.
What to prepare before the move
- A full backup of files and the database, verified by deploying it
- A list of domains and subdomains served by the current server
- Current DNS records, including MX and the SPF, DKIM and DMARC text records
- The PHP version, extensions and settings the site depends on
- Scheduled tasks and external services that call the site
- A list of third-party integrations where the current server IP is registered
The order of migration
A day ahead, lower the TTL on the domain records so the switch propagates quickly. Move files and the database to the new host, configure the environment and check the site through a temporary address or the hosts file - the domain still points at the old server at this stage.
Check more than the home page: open inner sections, submit a test enquiry, verify image loading and the customer account if there is one. At this point it is wise to block content editing on the old server, otherwise new enquiries and edits stay there.
Switch DNS and keep the old hosting paid for a few more days. While caches refresh, some visitors still reach the old server, and switching it off on moving day costs enquiries.
What to verify after the switch
- The site opens with and without www, redirecting to the chosen primary version
- HTTPS works and the certificate on the new server is valid
- Forms submit and messages reach the right mailbox
- MX and mail text records are in place; mail arrives and sends
- Scheduled tasks run on the new server rather than continuing on the old one
- Search Console shows no rise in availability errors and the sitemap responds
- Server logs show no database or permission errors
Frequently asked questions
Will the site be down during the move?
With the right order, no. The site is deployed on the new server first, verified, and only then the domain is switched. Downtime happens when the order is reversed: DNS is changed first and the new server configured afterwards.
What happens to email when the site moves?
If mail lives on the same hosting, it moves with the site and the mailboxes need migrating separately. If mail is on an external service, the critical point is not losing MX and text records when NS servers change - the new zone is created from scratch and mail records often simply do not make it in.
Does a move affect search rankings?
With URLs and content preserved, essentially no. Problems arise when the URL structure changes without redirects, or when the site stays unreachable for a long time. If addresses do change, redirects are prepared in advance, before the domain is switched.
We can handle the migration
Send the site address and the current and intended hosting. We will review what needs moving and in what order.
Discuss your project ↗