Migrating a website sounds risky, and people put it off for years because of that, often while paying a renewal price they resent. In practice it is a methodical process with one genuinely important rule: do not switch anything over until the new copy is working.
Follow that rule and the worst realistic outcome is that you waste an afternoon. Ignore it and you can have a broken site with no easy way back.
The Principle That Makes This Safe
A website move has two separable parts: copying your site to the new host, and pointing your domain at it.
Almost everything that goes wrong comes from doing those in the wrong order, changing the domain first and then trying to get the site working while it is live and broken. Copy first, test thoroughly, switch last. Your old site stays up and serving visitors the entire time.
Before You Start
Take your own backup
Not the host’s backup. Your own copy, downloaded to your computer, of both files and database. If anything goes badly wrong, this is what saves you.
For WordPress, a migration plugin will produce a single archive of both. Otherwise download the files over FTP or from the file manager, and export the database from the control panel.
Write down what you are running
Note your current PHP version, database version, and anything unusual your site depends on. If the new host runs an older or much newer version, you may need to adjust. Mismatched PHP versions are the most common cause of a migrated site showing errors.
Find your domain registrar
This is not always your host. If you got a free domain with your hosting, the host is probably also your registrar, which complicates leaving slightly. Confirm where the domain is managed and that you can log in, before you need to.
Check your DNS records
Export or screenshot your current DNS settings. The critical ones people forget are for email. If your email uses your domain, its MX records live in DNS, and carelessly replacing your DNS with the new host’s defaults will stop your email working. Note every record before you change anything.
Note your SSL situation
You will need a new certificate on the new host. Most provide one free, usually issued automatically once the domain points at them, which means there can be a short window after switching where the certificate is not yet active.
Copying the Site Across
Check first whether the new host offers a migration service. Many will do it for you at no charge, and they do it frequently enough to be good at it. If that is available, take it.
Otherwise, the process is:
- Create the hosting account and add your domain to it, without changing DNS.
- Upload your files to the new server.
- Create a database, then import your exported database into it.
- Update your site’s configuration file with the new database name, user, and password.
- Set the PHP version to match what your site expects.
At this point the site exists on the new host but nothing points at it yet.
Testing Before You Switch
This is the step that determines whether the migration is uneventful, and it is the step people skip.
You need to view the new copy while the domain still points at the old host. The most reliable way is to edit the hosts file on your own computer, mapping your domain to the new server’s IP address. That makes your machine, and only your machine, see the new site at the real domain name, which is exactly the condition you want to test under.
Some hosts also offer a temporary preview URL. These are convenient but can behave differently from the real domain, particularly with WordPress, so treat a preview URL as a rough check rather than a full test.
Once you can see the new copy, work through it properly:
- The home page and several interior pages
- Images and other media actually loading
- Any contact or signup form, submitted for real
- Login to the admin area
- Checkout, if you sell anything, as a genuine test transaction
- Search, if your site has it
- Anything custom or unusual
Fix everything you find now, while the live site is untouched and there is no time pressure.
Making the Switch
Reduce your domain’s DNS time-to-live value a day or two beforehand if you can. That shortens how long the internet caches the old address, which makes the switch propagate faster.
Then update the DNS records at your registrar to point to the new host, either by changing the A record to the new IP address, or by changing nameservers if you are using the host’s DNS. If you change nameservers, re-create every record you noted earlier, especially the email ones.
Propagation usually takes a few hours and can take up to a day or two. During that window some visitors reach the old server and some the new one, which is why you keep the old account running and why you should avoid publishing new content until it settles.
After the Switch
Confirm the SSL certificate has been issued and that the site loads over https without warnings. Check that http requests redirect to https.
Send yourself an email at your domain address, and send one from it, to confirm mail still works.
Run through your testing list again now that the domain genuinely points at the new host. Check your search console for a spike in crawl errors over the following days.
Set up backups on the new host, and confirm your own independent backup is running.
Then wait. Keep the old hosting account for at least two weeks, and preferably a month. It costs one more billing period and it is the difference between a problem being an inconvenience and a problem being a disaster. Only cancel once you are confident.
Problems You Are Most Likely to Hit
A white screen or error after import. Usually a PHP version mismatch or wrong database credentials in the configuration file. Enable error display temporarily to see the actual message rather than guessing.
Images missing. Often file permissions, or absolute URLs in the database still pointing at an old path. A search-and-replace across the database fixes the latter.
Mixed content warnings. Resources being requested over http on an https page. Usually hard-coded URLs in content or theme files.
Email stopped working. Nearly always a missing MX record after a nameserver change. This is why you wrote them down.
The site looks unstyled. Typically a caching plugin holding paths from the old server. Clear and regenerate the cache.
When to Pay Someone
If your site earns money and downtime has a real cost, or if it is large and complicated, paying for a migration is sensible. Many hosts do it free as an incentive to switch, so ask before assuming you need to hire anyone.
For a straightforward WordPress site, though, this is an achievable afternoon’s work, and the recurring saving from a better-priced host will typically exceed what you would pay someone to do it once.