You are moving the website to a new host this weekend. Email stays on Microsoft 365. Sounds simple until someone changes the wrong DNS record at cutover and the office stops getting mail for six hours.
Website migration and email migration are related in DNS, but they do not have to happen together. Most downtime horror stories come from treating one change as the other.
Separate the two systems in your head
Website traffic follows A/AAAA or CNAME records (and sometimes www vs apex redirects).
Email follows MX records, plus SPF, DKIM, and DMARC for deliverability.
Moving WordPress to Swift Host changes where HTTP requests land. It does not automatically move inboxes unless you change MX. Keep that distinction visible in your runbook.
Before you touch DNS
- Document current MX records (screenshot from registrar or DNS panel)
- Note SPF TXT and DKIM CNAMEs from your mail provider
- Confirm web and mail DNS live in the same panel (or know both logins)
- Lower TTL on A/AAAA records a day or two ahead (300 to 600 seconds)
- Leave MX TTL alone unless you are also moving mail (do not lower both blindly on Friday)
Export a full zone file if your DNS host allows it. Cheap insurance.
Migration sequence that keeps mail alive
Step 1: Build and test the site on the new host (staging URL or hosts file). Do not change live DNS yet.
Step 2: Verify forms, SSL, and integrations on the new server.
Step 3: Update only web records (A/AAAA/CNAME for @ and www) to the new host IP or hostname.
Step 4: Do not delete or repoint MX records during web cutover.
Step 5: Monitor mail flow externally (send test to Gmail, check headers) while checking the website from a phone on cellular data.
MX should still point at Microsoft, Google, or wherever it pointed before. Web traffic goes to the new box. Both can coexist in DNS without conflict.
Common mistakes
Using "change nameservers" when only the site moves. Pointing the domain at the new host's nameservers often imports a default zone that lacks your M365 MX and breaks mail instantly. Use child nameservers or update individual records if mail stays elsewhere.
Editing the zone template. Some panels offer "reset DNS to hosting defaults." That wipes custom MX. Read prompts carefully.
SPF panic. Changing web hosts does not require SPF changes unless you also change how the website sends mail (contact forms, WooCommerce). Form SMTP settings might need updating after cutover; MX records might not.
Forgetting autodiscover / mail subdomains. Outlook and mobile clients use autodiscover CNAMEs. Leave mail-related records untouched during a web-only move.
Contact forms after web migration
Your site might send mail through PHP mail(), SMTP on the old host, or a plugin relay. After migration, test contact and order forms. The website moved; SMTP credentials in wp-config might still point at the old server.
Mail to staff inboxes (MX unchanged) can work while form notifications fail because the app sends differently. Test both paths.
When email does move later
Sometimes you migrate web now and mail in a month. That is fine. Schedule a second cutover for MX with its own checklist. Do not assume "we already changed DNS once" means mail is handled.
We covered the mail-specific cutover in moving email when you change web hosts and when to separate email from web hosting.
Verification checklist on cutover day
- Website loads on cellular (not just office Wi-Fi)
- HTTPS valid on apex and www
- Send inbound test to staff@yourdomain.ca (external sender)
- Staff reply outbound reaches external inbox
- Contact form notification arrives
- MX lookup from external tool still shows correct mail host
Canadian businesses and calm cutovers
Friday afternoon DNS changes before a long weekend are a tradition we could skip. Plan cutovers when someone can watch both web and mail for two hours. Canadian clients still expect email during business hours even if the marketing site is "mostly static."
Bottom line
Migrate the website without email downtime by changing only web DNS records, documenting MX before you start, and testing forms separately from inbox delivery. Nameserver changes and "reset DNS" buttons are where mail usually dies.
Planning a web-only move to Swift Host? Talk with us. We will map A records and leave your MX alone unless you explicitly want mail moved too.
