Why Migrations Go Wrong

Most website migration problems are not technical failures — they are missed steps. A forgotten MX record breaks email. A too-high DNS TTL causes hours of split traffic. A skipped redirect map tanks search rankings. This checklist is provider-agnostic: it works whether you are leaving GoDaddy, Bluehost, SiteGround, Wix, or a self-managed server, and whether you are moving to TransPark or anywhere else in Canada.

The goal is zero downtime and zero data loss. That is achievable for almost any standard site with preparation.

Phase 1: Inventory Before You Touch Anything

You cannot migrate what you have not documented. Record all of the following:

[ ] Every domain and subdomain in use
[ ] Full DNS zone: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), and any verification records
[ ] Current DNS TTL values (you will lower these before cutover)
[ ] Website files and total size
[ ] Databases, their engine, and version (MySQL/MariaDB/PostgreSQL)
[ ] Email accounts, aliases, and forwarding rules
[ ] SSL certificates and their type (Let's Encrypt vs paid)
[ ] Cron jobs and scheduled tasks
[ ] Application credentials and API keys
[ ] Third-party integrations (payment gateways, CDNs, analytics)

Phase 2: Prepare the New Environment

Set up and fully test the site on the new host before pointing any live traffic at it.

[ ] Provision the new hosting with a matching runtime (PHP/Node/database version)
[ ] Transfer files and import the database
[ ] Update configuration (database credentials, environment variables, base URLs)
[ ] Provision SSL on the new server
[ ] Test the site on a temporary URL or hosts-file override
[ ] Verify forms, checkout, login, and search all work
[ ] Confirm scheduled tasks and cron jobs are configured

Phase 3: Protect Your Search Rankings

This is the step most businesses skip, and it is why some migrations cause a traffic drop.

[ ] Map every old URL to its new equivalent (if the URL structure changes)
[ ] Set up 301 (permanent) redirects for any changed URLs
[ ] Keep your XML sitemap accurate and submit it in Google Search Console
[ ] Preserve page titles, meta descriptions, and heading structure
[ ] Verify structured data (schema markup) still renders
[ ] Do not de-index the new site by leaving a "noindex" tag or a blocking robots rule in place from staging

A clean 301 map preserves the ranking authority of your existing pages. Without it, search engines treat your new URLs as brand-new pages with no history.

Phase 4: Lower TTL, Then Cut Over

[ ] 48 hours before cutover, lower DNS TTL to 300 seconds
[ ] At cutover, update A/AAAA records to the new server
[ ] Leave the old server running for at least 72 hours as a safety net
[ ] Update MX records only after the website is confirmed stable
[ ] Reconfigure SPF, DKIM, and DMARC for the new sending infrastructure
[ ] Restore TTL to normal values once propagation completes

With TTL pre-lowered, propagation typically completes within 15–60 minutes, and both old and new servers serve valid responses during the window — so visitors see no downtime.

Phase 5: Email Is Its Own Migration

Email is where "no downtime" migrations most often fail, because MX changes and mailbox transfers are separate from the website move.

[ ] Copy historical mail using an authenticated IMAP migration tool
[ ] Recreate aliases and forwarding rules on the new host
[ ] Change MX records only after mailboxes exist on the new server
[ ] Send and receive test messages from several external providers
[ ] Confirm mobile clients and any app notifications still deliver

Phase 6: Post-Launch Verification

After cutover and propagation, run through this before decommissioning the old host:

[ ] SSL padlock shows on every page (no mixed-content warnings)
[ ] All forms submit and deliver
[ ] Checkout and payment flows complete end to end
[ ] Email sends and receives correctly
[ ] Redirects resolve to the right destinations (spot-check old URLs)
[ ] Backups are running on the new host
[ ] Analytics is still collecting data
[ ] Google Search Console shows no new coverage errors

When to Keep the Old Host Running

Do not cancel the old hosting the moment the site loads on the new server. Keep it active for at least 30 days. DNS caches, forgotten subdomains, and email clients can keep hitting the old server for days. Cancelling early is the most common cause of "the site was fine and then broke a week later."

The Canadian Angle

If part of your reason for migrating is data residency, verify the destination actually keeps data in Canada — including backups. Many providers advertise a Canadian presence but replicate backups to US regions by default. Confirm the full data path: primary storage, backups, and where support staff access the environment. That is what makes the move meaningful under PIPEDA rather than cosmetic.

TransPark handles full managed migrations — files, databases, email, DNS, and redirect mapping — for clients on annual plans, entirely within Canadian infrastructure. But whether you move with us or on your own, this checklist keeps the migration boring, which is exactly what a good migration should be.

Website Migration Checklist for Canadian Businesses: A No-Downtime Playbook