Website Migration Planning: The Complete Guide

Moving a website from one host, platform, domain, or URL structure to another is one of the highest-risk operations in web management. Done well, visitors never notice. Done poorly, you lose search rankings, break inbound links, drop traffic, and spend weeks cleaning up the mess.

The problem is not that migrations are inherently difficult. The problem is that they involve dozens of interdependent systems, and missing any one of them creates failures that surface days or weeks after the move. DNS propagation, redirect mapping, SSL provisioning, CDN configuration, database migration, email routing, third-party integrations, and search engine re-indexing all need to happen in the right order.

This guide covers how to plan a migration from start to finish, regardless of whether you are moving hosts, changing domains, switching CMS platforms, or restructuring URLs. For the broader context on keeping your site healthy through changes, see the website maintenance and monitoring guide.

Types of Website Migration

Not all migrations carry the same risk. Understanding which type you are dealing with determines your planning effort.

Hosting Migration

Moving your site from one hosting provider to another while keeping the same domain, CMS, and URL structure. This is the lowest-risk migration because the public-facing site stays the same. The main concerns are DNS cutover timing, database transfer integrity, and SSL certificate provisioning on the new host.

Domain Migration

Changing your site's domain name (e.g., oldbrand.com to newbrand.com). This is high-risk for SEO because every URL changes, and search engines need to re-associate all your rankings with the new domain. Every inbound link pointing to the old domain needs a redirect to the new one. For detailed redirect planning, see the site migration redirect guide.

CMS Migration

Switching content management systems (e.g., WordPress to a headless CMS, or Squarespace to a custom platform). URL structures almost always change, templates change, and functionality may change. Content needs to be exported, transformed, and imported. This combines the risks of URL restructuring with the risks of a complete frontend rebuild.

URL Restructuring

Changing your URL patterns without changing the domain or CMS. Examples include moving from /blog/2024/01/my-post to /articles/my-post, or reorganizing category structures. Every changed URL needs a redirect from the old path to the new one.

HTTPS Migration

Switching from HTTP to HTTPS. While simpler than other migrations, it still requires redirects from every HTTP URL to its HTTPS equivalent, certificate provisioning, updating internal links, and verifying that mixed content issues do not break pages.

Combined Migrations

The riskiest scenario is combining multiple migration types. Moving to a new host, new domain, and new CMS simultaneously multiplies the failure points. When possible, break combined migrations into sequential steps. Move to the new host first. Stabilize. Then change the domain. Stabilize again. Then restructure URLs if needed.

Pre-Migration Planning

Planning is where migrations succeed or fail. Rushing to execution without thorough preparation is the single most common cause of migration disasters.

Inventory Your Current Site

Before you can migrate, you need a complete picture of what you are migrating.

URL inventory. Crawl your current site to get a full list of every URL. Use a crawler like Screaming Frog, Sitemap (if your sitemap is complete), or your web server's access logs to identify all URLs that receive traffic. Do not rely on your sitemap alone. Sites often have URLs that get traffic but are not in the sitemap.

Content audit. Identify every page, post, media file, download, and dynamic URL on the site. Note which pages receive the most organic traffic (check Google Search Console) and which have the most inbound links (check a backlink tool). These are your highest-priority pages for redirect mapping.

Technical inventory. Document your current server configuration, DNS records, SSL certificates, cron jobs, environment variables, API integrations, and third-party services. Each of these needs to be replicated or reconfigured on the new setup.

Functionality audit. List every form, search feature, user account system, e-commerce flow, API endpoint, and interactive element. Each needs to work on the new site before you cut over.

Create a Redirect Map

If any URLs are changing, build a complete redirect map: a spreadsheet or database that maps every old URL to its new equivalent.

For domain migrations, this may be as simple as a pattern rule (olddomain.com/* -> newdomain.com/*). For URL restructuring, you need individual mappings for every URL that changes.

Prioritize by traffic and backlinks. If a page gets 10,000 visits per month, its redirect must be correct. Missing a redirect on a page that gets 2 visits per month is less damaging, though you should still handle it.

Test your redirect rules before going live. Feed every old URL through the rules and verify each one lands on the correct new URL. Automated testing scripts save enormous time here.

Set Up the New Environment

Build and configure the new site completely before touching the live one.

Mirror the production environment. The new hosting environment should match your production requirements: same server software versions, same database engine, same PHP/Node/Python version, same memory and storage allocations.

Import content. Transfer all content, media, and database records to the new environment. Verify counts (number of posts, pages, users, products, etc.) match the original.

Configure DNS records. Prepare your new DNS configuration but do not activate it yet. Know exactly which records need to change. If your DNS provider is also changing, set up the new zone file in advance. For a thorough understanding of DNS changes during migration, see DNS propagation explained.

Provision SSL. Set up SSL certificates on the new host before cutover. If using Let's Encrypt, you may need to use DNS validation rather than HTTP validation (since the domain does not point to the new host yet). If using a purchased certificate, install it on the new server and verify the chain.

Test thoroughly. Browse the new site on the new host using a local hosts file override or a staging domain. Check every page template, every form submission, every API call, every image, and every interactive feature. Automated tests (Cypress, Playwright, or similar) are valuable here.

Migration Execution

Choose Your Cutover Window

Pick a time when traffic is lowest. For most sites, this is late evening or early morning in your primary audience's time zone. Avoid Mondays (high-traffic day for most business sites) and Fridays (you do not want to discover problems heading into a weekend with reduced staff).

Inform your team and stakeholders about the window. Have everyone who might need to troubleshoot available during and immediately after the cutover.

Lower DNS TTL in Advance

Two to three days before the migration, lower your DNS TTL (Time to Live) values to 300 seconds (5 minutes) or less. This means that when you update DNS records during the migration, the change propagates faster. Resolvers that cached the old record will fetch the new one within minutes instead of hours.

After the migration is stable and verified, raise the TTL back to a normal value (3600 seconds or higher) to reduce query load on your DNS provider.

Execute the Database Migration

If your database is moving, this is the most sensitive step. Options include:

Dump and restore. Export the database from the old server (mysqldump, pg_dump), transfer the file, and import it on the new server. This creates a brief period where writes to the old database are not captured.

Replication. Set up real-time replication from the old database to the new one. When replication is caught up, cut over. This minimizes data loss but is more complex to set up.

Read-only mode. Put the old site in read-only or maintenance mode, take a final database export, import it, then switch. This guarantees no writes are lost but requires downtime.

For e-commerce or high-traffic sites, the replication approach or a very short maintenance window is strongly preferred over an extended read-only period.

Update DNS

Point your domain's DNS records to the new hosting environment. If you are changing nameservers, update them at your registrar. If you are only changing A/AAAA records or CNAME records, update them at your DNS provider.

Monitor propagation using DNS lookup tools. Different ISPs and regions may see the new records at different times. For a period after the switch, some visitors will hit the old server and some will hit the new one.

Implement Redirects

If URLs have changed, deploy your redirect rules on the new server. If the old server will remain active for a transition period (handling requests from visitors whose DNS has not updated), deploy redirects there as well.

Verify redirects immediately after deployment. Spot-check your highest-traffic URLs manually, then run your automated redirect verification script against the full map.

Verify SSL

Confirm that HTTPS works on the new site for every URL pattern. Check the certificate chain, expiration date, and that there are no mixed content warnings. Browser developer tools and SSL checker tools both work for this.

Monitor Closely

For the first 24 to 48 hours after migration, monitor aggressively. Watch your uptime monitoring for any downtime. Check error logs on the new server for 404s, 500s, or other failures. Monitor Google Search Console for crawl errors. Check your analytics for traffic drops.

If something is wrong, you want to catch it in hours, not days.

Post-Migration Tasks

Verify Search Engine Indexing

Submit your updated sitemap in Google Search Console. If you changed domains, use the Change of Address tool in Search Console to tell Google about the move. Monitor the Index Coverage report for errors.

Expect a temporary fluctuation in rankings. Even well-executed migrations can see a brief dip in organic traffic as search engines reprocess your URLs. This typically recovers within 2 to 6 weeks for a hosting migration and 2 to 3 months for a domain migration.

Update External References

Anywhere your old URLs appear externally, update them if you can:

• Social media profiles and bios
• Business directory listings (Google Business Profile, Yelp, etc.)
• Email signatures
• Marketing materials (print and digital)
• Partner and affiliate links (reach out and ask them to update)
• API documentation and developer resources

You cannot control all inbound links (that is what redirects are for), but updating the ones you control reduces your dependency on redirects over time.

Monitor for Broken Links

Check your server logs and monitoring tools for 404 errors. Each 404 from a previously working URL represents a gap in your redirect map. Fix these promptly, especially for high-traffic URLs.

Set up ongoing monitoring using your website monitoring checklist to catch issues that emerge after the initial post-migration period.

Test Email

If your domain change or hosting change affects email (MX records, SPF, DKIM, DMARC), verify that email sending and receiving works correctly on the new setup. Email configuration errors are one of the most commonly overlooked migration issues. Test both inbound delivery and outbound deliverability.

Keep the Old Server Running

Do not decommission the old server or hosting account immediately. Keep it running for at least 2 to 4 weeks after migration. This gives you a rollback option if something goes seriously wrong, and it handles requests from visitors and crawlers still hitting the old IP address through stale DNS caches.

Common Migration Mistakes

Skipping the redirect map. Assuming that a domain-level redirect covers everything. It does not. Individual URLs that changed paths need individual redirects.

Not testing on the new environment first. Cutting over to an untested setup and discovering problems in production. Always test the full site on the new environment before switching DNS.

Forgetting about email. Moving hosting and breaking MX records, SPF records, or DKIM signing. Email stops working and you may not notice for days.

Migrating on a Friday. Discovering a problem Friday evening and spending the weekend firefighting, or worse, not discovering it until Monday when traffic spikes.

Not lowering DNS TTL. Leaving TTL at 86400 (24 hours) means some visitors will hit the old server for up to a day after you switch. This slows your ability to verify the migration and makes rollback slower.

Combining too many changes. Changing the host, domain, CMS, and URL structure simultaneously. If something breaks, you cannot tell which change caused it. Separate the changes when possible.

Not monitoring after the move. Assuming the migration is done once DNS updates. Problems can surface days or weeks later as search engines recrawl, as edge caches expire, or as users reach pages through old bookmarks.

Migration Timeline Template

Here is a practical timeline for a standard hosting migration. Adjust for more complex migrations.

2 to 4 weeks before: Inventory current site. Document DNS, SSL, server config. Set up and configure new environment. Begin content and database transfer.

1 week before: Complete testing on new environment. Build and verify redirect map. Prepare monitoring and alerting. Brief your team.

2 to 3 days before: Lower DNS TTL. Take a fresh full backup. Final content sync.

Day of migration: Final database sync. Update DNS. Deploy redirects. Verify SSL. Monitor for errors.

First 48 hours: Aggressive monitoring. Fix any 404s or redirect errors. Verify email. Check analytics.

First 2 weeks: Monitor Search Console for crawl errors. Watch organic traffic trends. Update external references.

1 month after: Raise DNS TTL. Decommission old server. Document lessons learned for next time.

For a detailed post-migration monitoring plan, see website downtime: causes and prevention.