Website Migration Plan: A Step-by-Step Workflow for Moving Hosts Without SEO Loss

Overview

A hosting migration changes where your website files, database, and application run. It does not necessarily change your domain name, URL structure, or search engine settings. That distinction matters: a carefully planned host move can preserve existing URLs, while an unplanned change can expose missing pages, server errors, insecure connections, or incorrect DNS records.

The safest approach is to separate the migration into four phases:

1. Inventory: document the current site, domain, DNS, email, integrations, and measurement tools.
2. Preparation: create backups, configure the new hosting account, and build a private staging copy.
3. Cutover: synchronize recent changes, update DNS, and monitor the old and new environments.
4. Verification: test important URLs, forms, tracking, email, security, and performance before retiring the old host.

This guide assumes that the domain name and URL structure will remain the same. If you are also changing the domain, moving from HTTP to HTTPS, or redesigning the site, treat the work as a broader SEO migration. You will need a complete URL map and a tested redirect plan. For related domain changes, see The Complete Website Migration Checklist.

Checklist by scenario

Before moving any website

• Record the domain registrar, DNS provider, current host, and renewal contacts.
• Export or document all DNS records, including A, AAAA, CNAME, MX, TXT, and any verification records. The DNS records troubleshooting guide explains what each common record does.
• List every subdomain, such as www, shop, app, staging, or api.
• Record the current PHP, database, web server, runtime, and CMS versions where applicable.
• Identify scheduled jobs, cron tasks, webhooks, payment integrations, external APIs, firewalls, caching layers, and content delivery services.
• Confirm how website files, databases, media, configuration files, and application secrets will be backed up.
• Capture a baseline of important URLs, response status codes, page titles, canonical tags, robots directives, XML sitemaps, and organic landing pages.
• Note the current analytics, tag manager, search console, uptime monitoring, and error-monitoring configuration.

Keep this inventory in a shared document with the date of the last verification. It becomes both a migration plan and a post-launch audit record.

For a WordPress or database-driven site

• Put the site into maintenance mode only if necessary; otherwise plan a short content freeze during the final synchronization.
• Back up the database and all site files separately. A backup is useful only if you know where it is stored and how to restore it.
• Export the media library and check that uploads are complete rather than relying only on the database.
• Review configuration values for the database name, user, password, table prefix, salts, environment mode, and site URL.
• Confirm that the new host supports the application’s required software versions and extensions.
• Replicate scheduled tasks and disable duplicate cron jobs if both hosts may run them at the same time.
• Use the host’s migration tool only after checking what it transfers: files, database content, email, DNS, SSL settings, and scheduled tasks may be handled separately.

For hosting selection, compare the operational fit rather than choosing only by introductory price. The guide to shared hosting, VPS, and managed WordPress hosting can help frame that decision.

Before the DNS cutover

• Create the site on the new host using a temporary hostname, preview URL, hosts-file entry, or other private testing method.
• Check that the application does not generate public links pointing to the temporary address.
• Import the database and files, then test representative pages, images, downloads, search, forms, logins, checkout flows, and user accounts.
• Install the SSL certificate and verify both the preferred hostname and any required alternate hostname.
• Confirm that the new server returns the intended status codes and does not block search crawlers accidentally.
• Lower DNS record TTL in advance if your DNS provider supports that control and if the change is appropriate for your plan. TTL does not guarantee an exact switchover time.
• Choose a low-traffic cutover window and identify who can approve the change and who can investigate problems.

During and immediately after cutover

1. Take a final database and file backup.
2. Freeze publishing or user-generated activity long enough to prevent new data from being left on the old server.
3. Synchronize the final changes to the new host.
4. Update only the DNS records required for the website. Do not overwrite unrelated email or verification records.
5. Use several networks or a DNS propagation checker to compare responses, but remember that different resolvers may update at different times.
6. Open the homepage, key landing pages, high-value articles, forms, login areas, and transaction paths.
7. Review server logs and monitoring alerts on both hosts while traffic transitions.

What to double-check

SEO and URL integrity

A host move should not require changing URLs. Crawl a representative sample and check for unexpected 404, 403, 404-like soft errors, redirect chains, or server errors. Confirm that canonical URLs, internal links, XML sitemaps, robots.txt, pagination, structured data, and hreflang settings—if used—still reflect the production domain.

If URLs must change, create a one-to-one redirect map from each important old URL to its closest relevant new URL. Avoid sending every old page to the homepage. Test redirects from the old path, not only from a manually typed destination. Keep the old environment available until you have reviewed traffic, logs, and crawl reports.

DNS, email, and SSL

The website’s A or AAAA record is only one part of a domain’s infrastructure. MX records control mail delivery, while SPF, DKIM, and DMARC support email authentication. A web migration can leave email working, break it, or create inconsistent results depending on which DNS records are changed. Before cutover, compare the old and new DNS zones line by line. For email-specific checks, use this SPF, DKIM, and DMARC configuration guide.

Test HTTPS on the main hostname, alternate hostname, important subdomains, and representative deep URLs. Check that HTTP redirects to the intended HTTPS version and that page assets do not load over insecure connections.

Analytics and application behavior

Load the site in a clean browser session and confirm that analytics requests, consent controls, tag manager containers, conversion events, and form notifications work as expected. Test from both an authenticated and unauthenticated perspective if the site has accounts. Review application logs for database errors, missing environment variables, permission problems, failed jobs, and timeout messages.

Common mistakes

• Changing nameservers without copying the DNS zone: This can remove mail, verification, or service records even when the website itself loads.
• Testing only the homepage: Broken templates, uploads, forms, and legacy URLs often appear deeper in the site.
• Forgetting the final content sync: Articles, orders, comments, or account changes made after the first backup may be absent from the new host.
• Leaving a staging block in place: A password restriction or crawler directive used for testing must be reviewed before launch.
• Assuming DNS changes are instant: Plan for a transition period and monitor more than one resolver or network.
• Deleting the old host immediately: Keep a restorable copy and a rollback path until the new environment is stable.
• Redirecting every missing URL to one destination: Preserve relevance with specific redirects, or allow genuinely retired pages to return an intentional status.
• Ignoring the hosting account’s renewal and resource limits: Document renewal dates, backups, storage, bandwidth, and operational contacts as part of the handoff.

When to revisit

Revisit this migration plan before every host change, major redesign, domain transfer, DNS provider change, or infrastructure consolidation. It is also worth repeating a smaller version after a server upgrade, CMS migration, CDN change, or security incident. Hosting control panels and migration tools change over time, so verify the current provider’s instructions instead of assuming that an older workflow still applies.

For a practical final review, schedule these checks:

• Before cutover: confirm backups, credentials, DNS records, staging tests, and the rollback owner.
• On cutover day: verify DNS responses, HTTPS, core user journeys, email, analytics, and server logs.
• After the transition: review errors, redirects, crawl reports, search visibility signals, uptime, and application performance.
• Before closing the old account: confirm that backups are restorable, no required service still depends on the old host, and the new host has an operational monitoring plan.

Use this article as a runbook, not a one-time checklist. The most reliable migration is the one that preserves a documented baseline, changes one infrastructure layer at a time, and keeps a tested route back until the new site has earned your confidence.