How to Migrate Your Website to a New Host

Migrations fail in DNS, email, and the one cron job nobody listed. The files are the easy part. InMotion and Kinsta advertise free moves because the scary part is coordination, not rsync. Do the inventory first. Lower TTL a week out. Cut over with a documented rollback. Then fix SSL and Search Console like an adult.

List: WordPress files, uploads, the database, cron jobs, extra vhosts, SSL names, and whether mail lives on the old cPanel. Bluehost-to-SiteGround moves go wrong when Catch-all mail still pointed at the old box. Note PHP version and any Redis or Elasticsearch you forgot. Export a database dump you can open. Photograph (or screenshot) DNS at Namecheap or Cloudflare. If you use WP Engine or Cloudways already, use their export tools as a second copy. Write who owns the registrar. A migrate without an inventory is two sites that both almost work. Include licenses: themes and plugins may lock to a domain or IP and need a reissue after cutover.

Kinsta, WP Engine, InMotion, and SiteGround all run migration teams or plugins. Use them when the source is a standard cPanel/WordPress and you do not have exotic services. DIY is a cPanel backup or a duplicator-style package plus a hosts-file test on the new IP before DNS moves. A2 and DreamHost document their own import paths. Do not FTP millions of files by hand; it will lie to you about permissions. Keep the old account paid through the window. Vendor migrations are not magic: serialized URLs, custom tables, and MU-plugins still break. Budget a staging URL on the destination. If the vendor says “we do not migrate mail,” believe them and move Google Workspace first or on purpose after.

If TTL is 86400, resolvers can cache the old A record for a day. Set 300 a week before you care. Keep nameservers at the registrar (Namecheap) if you can; changing nameservers and A records in the same hour is how you get a mystery weekend. Cloudflare users change origin IP in the dashboard; orange-cloud can mask a bad origin until you gray-cloud to test. Do not delete the old zone. Map www and apex. If you use email at the old host, moving the A record without MX is how invoices bounce. Put the cutover in a calendar with a second person. TTL is the only lever that is both free and frequently skipped.

Put the new site on the destination with a hosts-file or staging hostname. Click checkout, login, forms. Then point DNS. Watch an independent monitor and your own phone off Wi-Fi. If it is wrong, point DNS back—that is the rollback, and it only works if the old host is still live and TTL is low. Database writes during a long cutover (orders, comments) need a plan: maintenance mode, or a final dump after freeze. WP Engine and Kinsta migrations often include a follow-up sync; ask. Do not chase permalinks during the first twenty minutes if DNS is still split-brain. Rollback is a written IP and a checkbox, not a feeling that you could “just fix it.”

Issue Let’s Encrypt on the new host immediately; Cloudflare Full (strict) still needs a valid origin cert. Flush permalinks in WordPress. Recheck mixed content. Submit the sitemap; add the property in Search Console if the URL scheme changed. Update GA4 and any payment webhooks (Stripe) to the new reality if the hostname changed. Re-save Cloudflare page rules. Confirm cron. Download a fresh backup from SiteGround, Cloudways, or Kinsta now that production is there. Cancel the old host only after mail, SSL, and a clean crawl. A migrate is finished when the old IP can go dark without anyone noticing. Until then you are running two productions and calling it a project.

Inventory, low TTL, test on the new IP, cut over, keep the old box warm, then SSL and Search Console. Let Kinsta or InMotion carry files if the stack is ordinary. You still own DNS at Namecheap or Cloudflare. Rollback is an IP, not optimism.