Clients picture migration weekend as a single dramatic DNS flip at midnight. Reality is messier and more boring: files copy for hours, someone discovers a hardcoded database URL in a plugin, email stays on the old host until Tuesday, and the staging site becomes the only calm place in the project.
Here is what a well-run hosting migration actually looks like when we move a Canadian business to Swift Host. No heroics, just a sequence that keeps the site up and the inbox working.
Before the weekend: the quiet prep work
Most of the work happens Monday through Friday, not Saturday at 2 a.m.
- Inventory DNS (A, MX, TXT, subdomains)
- Export databases and confirm backup integrity
- Lower TTL on records you will change
- Document cron jobs, custom PHP settings, and SSL requirements
- Stand up staging on the new server with a temporary hostname
- Run smoke tests: login, forms, checkout, file uploads, email send
If staging is broken, you do not cut over. You fix staging. Weekend migrations fail when teams skip this step to "save time."
Friday evening: freeze and final sync
We ask clients to freeze content changes if possible (no big WordPress edits, no product uploads). Not always realistic for stores, but fewer moving parts help.
Final rsync or database dump captures the latest state. For busy WooCommerce sites we may schedule cutover in a low-traffic window (Sunday morning Alberta time is common).
Saturday: the actual move
Typical order of operations:
- Restore files and database on new Canadian infrastructure
- Update wp-config.php or app env (DB host, URLs, Redis keys)
- Fix permissions, PHP version, missing extensions
- Re-test on staging URL with hosts file or temp domain
- Issue or install SSL on the new vhost
- Update production DNS when tests pass
DNS propagation means some visitors still hit the old server for a while. We keep the old account readable (not deleted) until TTL expires everywhere that matters.
What clients feel vs what happens backstage
Clients feel: "The site was slow for an hour" or "My colleague still sees the old site."
Backstage: Propagation, browser cache, Cloudflare orange-cloud settings, or an old MX record nobody updated.
We verify from external DNS tools and mobile data, not just the office Wi-Fi. "Works on my machine" is not a sign-off.
Email: often the thing that breaks
Website DNS and mail DNS change on different schedules. Many migrations move the site first and leave MX pointing at Google Workspace or the old host until mailboxes are ready.
Weekend panic usually sounds like: "The site is live but I am not getting contact form emails." That is often SPF/DKIM, a form plugin still posting to the old server, or MX not updated when it should have been left alone.
We document which records change and which stay put before anyone touches the zone file.
Sunday: soak test and handoff
After DNS settles:
- Submit contact and order forms for real (not just "200 OK")
- Place a test order if e-commerce
- Check admin login, backups, and cron
- Scan error logs on the new server
- Confirm monitoring alerts point at the new IP
Monday morning is when staff log in from home networks with fresh DNS. That is the real acceptance test.
When things go wrong (and how we roll back)
Rollback is reverting DNS to the old A record values we saved on day one. Old hosting stays online until we are confident. No improvising MX targets from memory at 11 p.m.
Common surprises: PHP 8.x breaking an old plugin, image paths still pointing at the old temp URL, Redis/Memcached auth mismatches (we have seen this on WordPress migrations from Bluehost), oversized uploads blocked by new limits.
Each surprise is fixable. They are expensive when nobody budgeted time for them.
Canadian hosting angle
Moving from US hosting to Edmonton, Beauharnois, or Toronto/Cambridge does not change the migration playbook. It changes latency and data residency after cutover. Compliance questionnaires get answered with real facility names instead of "US-East."
Some clients migrate for performance (Western Canada staff on Edmonton metal). Others for Law 25 or contract language. The weekend timeline is the same either way.
What you can do to make it boring (in a good way)
- Give your host SSH/FTP access and DNS access early
- List every subdomain that matters (booking, client portal, old microsites)
- Tell us where email lives and must stay living
- Accept that staging week is part of the project, not optional
Boring migrations are successful migrations. Excitement is for product launches, not DNS.
Bottom line
Migration weekend is the visible tip of a week of prep, a day of cutover, and a day of verification. Plan for propagation, protect email, keep rollback handy, and test from outside your office before you declare victory.
Planning a move to Canadian hosting? Talk with Swift Host. We will walk you through a realistic timeline before anyone schedules a Saturday DNS change.
