Moving to a new server is mostly careful copying and patient waiting, and the problems that hurt are rarely the website itself. They are the things around it: email that lived on the old hosting account, a payment gateway that only accepts requests from the old server's IP address, a scheduled task nobody knew existed. If you plan to migrate a website to a new host, work through the order below and most surprises turn into checklist items.

Before you migrate a website to a new host: take inventory

A hosting migration checklist starts with what exists today, not with the copy:

  • Where each piece lives. The domain registrar, DNS provider, web hosting and email are often four different accounts. Write down which company holds each one and who has the login.
  • Software versions: PHP version and extensions, database server and version, web server and any caching layer.
  • Databases and their sizes, including ones used by old installations nobody remembers.
  • Cron jobs and other scheduled tasks: backups, feeds, order exports, cache warmers.
  • Email. Are mailboxes on the same hosting account? Does the site send mail through the local server or through an outside service?
  • IP allowlists. Payment gateways, shipping and ERP connections or partner APIs that only accept traffic from the current server. The new server will have a different outgoing address.

Copying files and databases

Files move best with rsync over SSH, which can be re-run to copy only what changed. For MySQL and MariaDB, mysqldump with the --single-transaction option takes a consistent snapshot of InnoDB tables without locking the site while it runs. On the new server, import the dump and compare row counts in the key tables: orders, customers, posts.

Watch the details that cause quiet damage:

  • Character sets. An old latin1 database imported carelessly as utf8mb4 produces garbled accents and symbols. Check the character set and collation before and after.
  • Version jumps. Moving from MySQL to MariaDB, or to a newer major version, can change how some queries and settings behave. Rehearse on a copy.
  • Hard-coded paths and URLs in configuration files. If the domain changes as well, WordPress needs a search and replace that understands serialized data, such as the one built into WP-CLI.

Test on the new server through the hosts file

Before any DNS change, you can see the site on the new server from your own computer. Add a line to your computer's hosts file that maps the domain to the new server's IP address, and your browser will load the new copy while everyone else still sees the old one. Log in, submit forms, run a test order, trigger a password reset email, and read the error logs on the new server.

Plan the SSL certificate after migration in advance. Certificates from Let's Encrypt and similar authorities are usually validated over HTTP, which only works once DNS points at the new server. You can copy the existing certificate across for the switch, validate through a DNS record instead, or issue a new certificate straight after the cutover. What you want to avoid is visitors reaching the new server before a valid certificate is in place. This test-first approach is the core of our hosting and database migration service.

The DNS cutover: TTL, nameservers and propagation

Resolvers around the world cache DNS answers for as long as each record's TTL (time to live) allows. A day or more ahead, lower the DNS TTL on the records you will change, such as the A records for the domain and www, to a few minutes. Wait at least as long as the old TTL, so the short value is what everyone has cached. On switch day, change the records and most visitors follow within minutes.

What people call DNS propagation is really old cached answers expiring. That is why changing records at the same DNS provider is quick, while deciding to change nameservers at the same time is slower: the delegation for the domain is cached by the top-level domain's servers, often for up to two days. If the DNS provider must change too, copy every record first (MX, the TXT records for SPF, DKIM and DMARC, verification records and subdomains) and move the nameservers on a separate day from the server switch.

How to move a website without losing email

If mail is hosted elsewhere, such as Microsoft 365 or Google Workspace, leave the MX records untouched and email will not notice the move. If the mailboxes live on the old hosting account, they need their own migration, and the MX change should happen only after they are copied. Our email migration to Microsoft 365 or Google Workspace covers that, and a hosting move is often the right time to separate mail from the web server anyway.

After the switch: migrate a website to a new host

  1. For stores and membership sites, pause new orders briefly, run a final database sync and then change DNS, so nothing is written to the old server after the last copy.
  2. Re-create the cron jobs on the new server and disable them on the old one, or customers may receive every scheduled email twice.
  3. Set up backups and monitoring on the new server; they do not travel with the files.
  4. Watch the old server's access log. When the only visitors left are bots, the switch is complete.
  5. Keep the old hosting for a week or two before cancelling, in case a forgotten file or mailbox turns up.

Frequently asked questions: migrate a website to a new host

How long does DNS propagation take?

For record changes prepared with a short TTL, minutes for most visitors. For nameserver changes, allow up to a day or two, because the delegation is cached by the registry's servers.

Can a website move without downtime?

For brochure sites and blogs, yes: both servers serve the same content while DNS switches over. Stores need a short pause in new orders during the final sync, best scheduled for the quietest hour of the week.

Should we move DNS hosting at the same time?

Better not. Change one thing at a time: first the server, then, once everything is stable, the DNS provider or the registrar.

Will moving hosts fix a slow site?

Only if the server is the bottleneck. If the server answers quickly but pages still load slowly, the cause is usually the theme, images or plugins, and a new server alone will not help. Measure first.

Moving a WordPress, WooCommerce, Magento or Joomla site, or a whole cPanel account to a cloud server? Our website and database migration service covers the copy, the database checks, the final sync and the DNS switch. Tell us where the site is hosted now, where it is going and where DNS and email are managed, and we can plan the move with you.