WordPress migrations fail in boring ways. Someone forgot MX records. A plugin hard-coded the old IP. Search-replace turned widget settings into gibberish. The site "worked" on staging until DNS flipped and checkout started timing out.
A good checklist does not make the move glamorous. It makes the weekend predictable. Use this before you copy files or touch production DNS, whether you are moving to Canadian hosting, off a bloated shared plan, or finally leaving a host you have outgrown.
Two weeks out: know what you are moving
Export a snapshot of reality, not what you think the site is:
- WordPress version, PHP version, and MySQL/MariaDB version on the current host. Match or upgrade thoughtfully on the new server.
- Full plugin and theme list with versions. Note anything custom, mu-plugins, or licensed (ACF Pro, Gravity Forms, etc.).
- WooCommerce or membership plugins if present. They add cron jobs, tables, and session behavior you cannot ignore.
- Uploads folder size and total database size. Big media changes copy time and backup windows.
- Outbound integrations: payment gateways, CRM, shipping APIs, webhooks that whitelist IP addresses.
- Who owns DNS, SSL, and email? Often three different logins. Write them down.
If you cannot log into all three, stop and fix access before you schedule cutover.
One week out: lower TTL and line up staging
Drop DNS TTL to 300 seconds (five minutes) at least 24 hours before go-live. That makes rollback and propagation less painful. See DNS and propagation when you migrate hosts if your registrar UI is confusing.
Provision staging on the new host with the target PHP extensions (imagick, intl, redis if you plan object cache). Clone the site to a staging URL and test there first. Our staging guide is worth a read if you usually edit live.
On staging, verify:
- Admin login and password resets
- Forms and SMTP (contact forms love to break on new IPs)
- WooCommerce checkout with a real gateway test mode
- Cron: scheduled posts, subscription renewals, backup plugins
- Pretty permalinks and HTTPS without mixed-content warnings
Backups you can actually restore
Take a fresh full backup before any migration step: database, all files (including wp-content), and a copy of wp-config.php stored outside the web root. Confirm you can restore it somewhere, not just that the zip exists.
If your host offers snapshots, great, but snapshots are not a substitute for off-server backups. Read hosting backups that actually restore before you trust a one-click export.
Email: decide before DNS day
Web hosting and email are often bundled in your head but not in DNS. Moving the website does not move mail unless you plan for it.
Document current MX, SPF, DKIM, and DMARC. If mail stays on the old provider, do not point MX at the new web server by accident. If mail moves too, schedule that separately or with a clear order of operations. Website migration without email downtime walks through the split.
Search-replace and serialized data
URLs hide in post content, widgets, options, and plugin JSON. Plan a safe search-replace strategy (WP-CLI search-replace with serialization awareness, or trusted migration plugins). Never run blind SQL updates on wp_options.
After replace, spot-check: homepage, a few posts with embeds, the menu, footer widgets, and WooCommerce emails if you run a store.
Security and access housekeeping
- Rotate migration passwords after cutover (SFTP, database, admin accounts shared with contractors).
- Update firewall allowlists and API keys tied to the old server IP.
- Reissue or reinstall SSL on the new host before you send traffic.
- Enable MFA on hosting, DNS, and WordPress admin where possible.
Cutover day: sequence that works
- Put up a brief maintenance notice if you need one (some teams skip this with a fast DNS swap).
- Final sync: database and files from old to new. Freeze content edits during the window if you can.
- Run URL updates on the new environment.
- Smoke test on the new server using hosts file or staging URL with production data.
- Flip DNS (A/AAAA or CNAME as appropriate). Purge CDN cache if you use one.
- Watch error logs and uptime for the first few hours. Test forms and checkout again on production.
For a hour-by-hour picture of what clients feel, read hosting migration weekend: what actually happens.
First 48 hours after go-live
Keep the old host online (read-only) as a rollback parachute. Monitor:
- 404 spikes (permalink or .htaccess issues)
- PHP errors in logs
- Failed cron or backup plugin emails
- Google Search Console crawl errors after URL changes
Lower TTL can stay short for a week, then raise it again once you are confident.
When you are moving to Canadian hosting
Data location, support time zones, and latency for Canadian visitors are usually the reasons. The checklist is the same, with extra attention to privacy policies if you handle personal data north of the border. Our longer walkthrough is in migrate WordPress to Canadian hosting.
Bottom line
Pre-migration work is inventory, staging proof, backups you have tested, and a DNS/email plan written down. Rush the copy, wing DNS, and you will debug production at midnight. Slow down the week before so cutover day is mostly checklist execution.
Want a migration plan with realistic downtime and rollback? Talk with Swift Host. We move WordPress and WooCommerce sites to Canadian infrastructure and prefer boring go-lives.
