Website Migration Checklist: Move Your Site to a New Host Safely

Overview

This article gives you a practical website migration checklist you can return to whenever hosting, infrastructure, or team workflows change. The goal is not just to copy files from one server to another. A safe migration means preserving application behavior, keeping DNS records accurate, protecting email delivery, maintaining SSL coverage, and having a rollback plan ready before you touch production.

Most hosting migration steps fall into five phases:

1. Inventory what exists now. Know exactly what the site depends on: files, databases, DNS records, scheduled jobs, SSL, email services, CDN settings, firewall rules, and third-party integrations.
2. Build the destination first. Provision the new host, match runtime requirements, restore data, and test with a temporary URL, hosts file override, or staging domain.
3. Reduce cutover risk. Lower DNS TTL where appropriate, pause content changes if needed, collect fresh backups, and schedule the switch for a low-traffic window.
4. Cut over carefully. Update DNS, watch logs and uptime, verify SSL and redirects, and confirm that forms, payment flows, and email still work.
5. Keep rollback possible. Do not cancel the old host immediately. Leave the old environment available until traffic, jobs, and data consistency are confirmed.

If your domain registration and hosting are managed separately, migration is often easier because you can switch DNS without moving the domain itself. If you are also planning a domain transfer, treat that as a separate project with its own timeline and risk checks. For that process, see Domain Transfer Checklist: How to Move a Domain Without Downtime.

Before choosing a new environment, make sure the target plan matches your workload. A small brochure site, a WooCommerce store, and a custom application do not have the same hosting needs. If you are still comparing options, Shared Hosting vs VPS vs Cloud Hosting: Which Should You Choose? and Best Web Hosting for Small Business Websites: Features, Limits, and Upgrade Paths can help frame the tradeoffs.

Checklist by scenario

This section gives you reusable checklists by migration type. Start with the universal checklist, then add the scenario that fits your site.

Universal pre-migration checklist

• List every domain and subdomain involved, including www and non-www versions.
• Export or document current DNS records: A, AAAA, CNAME, MX, TXT, SRV, and any verification records.
• Record current TTL values before changing anything.
• Back up website files, databases, environment files, media uploads, and configuration files.
• Document server versions and requirements: PHP, Node.js, Python, database version, web server, extensions, memory limits, and cron jobs.
• Inventory third-party dependencies such as CDN, WAF, payment gateways, SMTP relays, search services, object storage, and API keys.
• Check whether email is hosted with the web host, a third-party provider, or a separate mail server.
• Create a migration window and define a rollback decision point.
• Set up the destination hosting account, access credentials, SSH keys, and deployment method.
• Confirm how SSL certificates will be issued or imported on the new host.
• Prepare a temporary testing method: staging URL, preview domain, or local hosts file override.
• Notify stakeholders if the site includes checkout, lead forms, logins, or editorial publishing.

Scenario 1: Static site or simple business website

If the site is mostly HTML, CSS, JavaScript, and media assets, the migration path is usually straightforward. The main risks are incomplete uploads, wrong redirects, and missed DNS records.

• Copy all public files and preserve directory structure.
• Verify the home page, contact page, form handlers, downloads, and image paths on the new host.
• Check redirects from old URLs to current ones.
• Confirm SSL is active before or immediately after cutover.
• Update the A record or CNAME only after testing the new host.
• Keep the old host online until DNS propagation stabilizes.

Scenario 2: WordPress or other database-driven CMS

CMS migrations are common, but they have more moving parts: database serialization, plugins, caching, media libraries, and background jobs.

• Export the database and take a fresh copy right before cutover.
• Copy the full application directory, including uploads, themes, plugins, and hidden files.
• Match runtime versions and key extensions on the new host.
• Update application configuration for the new database credentials.
• Run any required search-and-replace carefully if URLs or paths change.
• Test login, forms, media loading, search, checkout, and admin tasks.
• Clear application, object, and CDN caches after cutover.
• Recreate scheduled jobs and verify they run successfully.

Scenario 3: Custom app on managed cloud hosting

For custom applications, the website is only one part of the migration. The safer approach is to treat it as a deployment event with infrastructure checks.

• Version-control the application and deploy from a clean build where possible.
• Move secrets into the new host's environment management system rather than copying them loosely.
• Provision databases, storage, workers, and queues before web traffic is switched.
• Confirm outbound access to APIs, SMTP services, and webhooks.
• Run database migrations in a controlled order and know whether they are backward compatible.
• Check health endpoints, application logs, and process restarts.
• Verify firewall allowlists and webhook source validation if IPs change.
• Monitor error rates closely during and after DNS cutover.

Scenario 4: Site migration without downtime for high-traffic sites

Zero downtime is not always realistic in the absolute sense, but low-disruption cutovers are possible with planning.

• Lower TTL on key DNS records well before the cutover if your provider and timing allow it.
• Reduce content changes during the final sync window, especially for stores, forums, or membership sites.
• Take a final database snapshot just before switching traffic.
• Use maintenance mode only if data consistency matters more than uninterrupted browsing.
• Cut over during a predictable low-traffic period.
• Monitor application logs, real user checks, and uptime immediately after the switch.
• Be ready to revert DNS if a critical path fails.

If you need a refresher on how nameservers and records work during cutover, read How to Connect a Domain to Web Hosting: DNS Records Explained. For timing expectations, DNS Propagation Explained: How Long Changes Take and How to Check is a useful companion to any dns cutover checklist.

Scenario 5: Migrations where business email uses the same domain

This is one of the easiest areas to break during a host move. Website traffic and email routing are separate systems, but they often share the same DNS zone.

• Export all existing MX, SPF, DKIM, and DMARC records before making changes.
• Do not overwrite mail records when updating web records.
• Confirm whether the new host tries to auto-manage DNS or email settings.
• Send and receive test messages before and after cutover.
• Check contact forms, transactional email, password reset flows, and SMTP authentication.
• Verify mailbox continuity if mail is also being migrated.

If your domain email setup is under review as part of the move, compare your options first with Business Email Setup With Your Domain: Google Workspace, Microsoft 365, and Zoho Compared.

What to double-check

This section is where most migrations are saved. Even if your file copy and DNS update are correct, details here can still cause failed checkouts, broken admin areas, or silent email problems.

DNS and domain settings

• Make sure you know whether you are changing nameservers or only individual DNS records. These are different actions with different risk profiles.
• Confirm the authoritative DNS provider where changes must actually be made.
• Check both apex and www records.
• Preserve non-web records such as MX, TXT verification, SIP, or service-specific records.
• Document the old values so rollback is immediate if needed.

SSL certificate coverage

• Verify that the new host issues or accepts a valid SSL certificate for every required hostname.
• Check whether wildcard coverage is needed for subdomains.
• Confirm redirects from HTTP to HTTPS behave correctly.
• Look for mixed content warnings after the move.

Application behavior

• Test forms, login, logout, password reset, search, file upload, checkout, and webhooks.
• Review error logs after the first live traffic arrives.
• Check background tasks such as scheduled imports, email digests, invoicing, or cleanup jobs.
• Confirm file permissions, writable directories, and temporary storage behavior.

Performance after migration

• Measure page generation time and static asset caching on the new host.
• Verify CDN and cache headers.
• Check that image optimization, compression, and HTTP keep-alive or equivalent performance settings are active if relevant.
• Compare response times from more than one network location, not just your office connection.

Data integrity and rollback readiness

• Compare record counts or key tables if a database is involved.
• Verify that recent content and media are present after the final sync.
• Keep the old environment unchanged and reachable until validation is complete.
• Write down the exact rollback step, usually restoring old DNS values and pausing writes on the new host if required.

Post-migration performance is also a buying signal for whether the new platform is the right long-term fit. If cost or scaling becomes a concern after the move, review Cloud Hosting Pricing Guide: What You Really Pay Each Month before expanding the deployment.

Common mistakes

You can prevent many migration failures by assuming that the obvious steps are not the risky ones. The problems below come up repeatedly in domain and hosting moves.

Changing too many variables at once

A host change is not the best time to also redesign the site, change the CMS version, modify URL structure, move email, and transfer the domain registration. Break projects apart unless there is a strong reason to combine them.

Skipping a full DNS inventory

Teams often update the A record and forget that the DNS zone contains records for mail, verification, subdomains, and third-party services. One missing TXT or MX entry can create hours of confusion.

Testing only the home page

A migration is not validated because the front page loads. Test the actions that matter: checkout, lead capture, admin editing, search, account login, image upload, and transactional email.

Assuming the new host matches the old environment

Minor version differences, disabled modules, memory limits, or missing background workers can break applications in subtle ways. Match requirements explicitly instead of assuming compatibility.

Forgetting email during website cutover

Mail outages often happen because DNS was simplified too aggressively. If the website and mail share the domain, web hosting changes should be made with email records open in front of you.

Removing the old host too quickly

Do not shut down the old account the moment the new site appears live. Keep it available until DNS propagation is complete, logs look normal, and key user flows are confirmed. This is one of the simplest ways to preserve a safe rollback path.

No rollback trigger

Rollback should not be an emotional decision made under pressure. Define in advance what would trigger it: sustained 5xx errors, failed payment processing, broken login, missing media, or undelivered email.

When to revisit

This checklist is most useful when treated as a living playbook rather than a one-time article. Revisit it any time the inputs behind your migration process change.

• Before renewing or replacing hosting. A contract end date is a good time to re-evaluate managed cloud hosting, performance needs, and migration risk.
• Before seasonal traffic periods. If your business has peak periods, plan migrations well outside them and review the checklist in advance.
• When DNS ownership or domain and hosting arrangements change. New registrars, DNS providers, or platform-managed DNS can alter the cutover process.
• When the application stack changes. New framework versions, added workers, search services, or object storage all affect migration steps.
• When email or SSL handling changes. A new email provider or certificate workflow adds dependencies worth documenting before the next move.
• After every migration retrospective. Add the issues you actually encountered so the checklist improves over time.

For practical next steps, create a one-page migration runbook from this article with four parts: current inventory, destination setup, cutover steps, and rollback steps. Store it alongside your deployment documentation. Include the exact DNS values, the location of your latest backups, the person responsible for the final go/no-go call, and the tests that must pass after cutover. That simple habit turns a generic hosting migration steps list into an operational process your team can trust.

If your next move starts with choosing a more suitable platform rather than switching immediately, compare hosting models first and map them to your workload. That groundwork often prevents the second migration you did not expect to make six months later.