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

Overview

A good website migration checklist reduces avoidable risk. Most hosting moves fail for ordinary reasons: missing backups, incomplete DNS records, uncopied cron jobs, forgotten redirects, or testing only the homepage and not the parts of the site that actually matter.

Before you start, define what kind of move you are making. In practice, there are three separate changes that people often bundle together:

• Hosting migration: moving site files, databases, and application settings to a new server or cloud hosting environment.
• DNS change: pointing the domain to the new hosting provider.
• Domain transfer: moving domain registration from one registrar to another.

These do not have to happen at the same time. In many cases, separating them makes the migration safer. You can keep domain registration where it is, move the site first, confirm everything works, and only then decide whether to transfer the domain later. If you need a deeper DNS refresher, see DNS Records Explained: A, AAAA, CNAME, MX, TXT, NS, and SRV and How to Point a Domain to Your Hosting Provider: Complete DNS Setup Guide.

Use this checklist in four phases:

1. Plan: inventory the current site and identify dependencies.
2. Clone: copy the site to the new host and configure it fully.
3. Test: validate functionality before changing DNS.
4. Cut over and monitor: switch traffic, watch logs, and keep the old host alive until the new one is stable.

If the site generates leads, sales, or support requests, schedule the cutover during a low-traffic window and make sure someone with DNS access, hosting access, and application admin access is available during and after the switch.

Checklist by scenario

This section gives you a practical hosting migration checklist by use case. Start with the universal checklist, then add the scenario-specific items that apply to your stack.

Universal pre-migration checklist

• Document the current environment: hosting plan, server type, PHP or runtime version, database version, web server, SSL setup, CDN, backups, scheduled tasks, and third-party integrations.
• List everything tied to the domain: website, email, transactional mail, subdomains, API endpoints, staging sites, and verification records.
• Create full backups of files and databases, and store copies off the current server.
• Export DNS zone records before making any changes.
• Lower DNS TTL in advance if you control the zone and want a faster cutover.
• Set up the new hosting account, including SSL, runtime versions, database users, firewall or access rules, and backup policies.
• Copy the website to the new host.
• Update configuration files such as database credentials, environment variables, and file paths.
• Test the site on the new host using a temporary URL, hosts file override, preview domain, or staging domain.
• Confirm forms, logins, search, checkout, media uploads, and admin functions work correctly.
• Prepare a rollback plan: know how to point traffic back, restore backups, or temporarily pause changes.
• Only after testing, update DNS to point the live domain to the new host.
• Monitor logs, uptime, and error reports after cutover.
• Keep the old hosting account active until you are confident the migration is complete.

Scenario 1: Static site or brochure site

If your site is mostly HTML, CSS, JavaScript, and images, the move is usually straightforward, but you still need to verify the details.

• Confirm all assets were copied, including hidden files like .htaccess or caching rules if relevant.
• Check redirects, canonical tags, robots.txt, and sitemap references.
• Verify any contact form service, embedded booking tool, analytics script, or third-party widget still loads correctly.
• Test mobile rendering and image paths on key pages.
• Review caching and compression settings on the new host.

Scenario 2: WordPress site

WordPress is a common migration case because the site depends on both files and a database. Managed WordPress hosting can simplify some tasks, but the checklist still matters. If you are evaluating hosting types, see Managed WordPress Hosting vs Regular Web Hosting: What Actually Changes?.

• Back up the full WordPress files and database.
• Record the active theme, plugin list, and current PHP version.
• Move the wp-content directory and database carefully; do not forget uploads.
• Update wp-config.php with the new database credentials.
• Search and replace old URLs if the migration process requires it, especially when changing domains or paths.
• Re-save permalinks after launch if links return errors.
• Test caching, image optimization, security plugins, and redirect plugins on the new environment.
• Check scheduled tasks such as cron jobs, backups, and WooCommerce emails.
• Verify admin login, form submissions, media library access, and plugin licensing.

Scenario 3: Ecommerce site

Ecommerce migrations carry higher risk because orders, inventory, payment flows, and customer communication are involved. If you run a store, treat the migration as an operational event, not just a hosting task. For platform-specific planning, see Best Hosting for WooCommerce Stores: Features, Limits, and Upgrade Triggers.

• Schedule the migration outside peak order hours.
• Decide whether to place the store in maintenance mode during final sync.
• Check payment gateway callbacks, webhooks, tax tools, shipping apps, and fraud tools.
• Verify transactional email delivery after launch.
• Confirm checkout, cart persistence, customer login, account pages, and order notifications work.
• Review SSL certificate coverage and mixed-content warnings.
• Test inventory updates and any ERP or CRM integrations.
• Make sure no orders are left behind on the old server during the final cutover window.

Scenario 4: Custom app, CMS, or VPS migration

If you are moving to VPS hosting, cloud hosting, or another custom stack, the application layer matters as much as the content.

• Document the exact runtime versions, packages, services, and system dependencies.
• Replicate firewall rules, reverse proxy configuration, and SSL termination behavior.
• Move environment variables securely; do not hard-code secrets during the migration.
• Test background workers, queues, cron jobs, and scheduled scripts.
• Confirm file permissions, storage paths, and object storage integrations.
• Validate process management and restart behavior after deployment.
• Review database access rules, replication assumptions, and backup retention.
• Check application logs and server metrics immediately after cutover.

Scenario 5: Domain and email attached to the same provider

This is where many otherwise successful migrations run into trouble. The website may work, but email fails because MX, SPF, DKIM, or DMARC records were changed accidentally or not copied over. If email is business-critical, treat it as a separate workstream.

• Export and review existing DNS records before changing nameservers or zone records.
• Preserve MX, SPF, DKIM, and DMARC records exactly unless you are intentionally changing email providers.
• Confirm web-related records separately from email-related records.
• Test incoming and outgoing mail after the DNS change.
• Check subdomains used for mail tracking, verification, or third-party services.
• Review these guides if needed: SPF, DKIM, and DMARC Explained for Website Owners and How to Set Up Business Email for a New Domain.

Scenario 6: Hosting move plus domain transfer

It is possible to combine a website migration with a domain transfer, but it adds complexity. Unless you have a specific reason, many teams prefer to move hosting first and transfer domain registration later.

• Make sure domain contact details are current and the domain is eligible for transfer.
• Do not assume domain transfer and DNS changes are the same task.
• Confirm whether DNS will stay where it is or move with the domain.
• Delay nonessential registrar changes until the website is stable on the new host.
• Use a separate checklist for the registrar move. See How to Transfer a Domain Name Without Downtime.

What to double-check

These are the items most likely to cause hidden problems after a migration. A site can appear fine on the surface while key functions fail in the background.

DNS and routing

• Correct A, AAAA, or CNAME records for the main domain and www host.
• MX, TXT, and verification records still present if email or third-party services rely on them.
• TTL expectations set realistically; propagation is not always immediate.
• Nameserver changes understood before you make them.

SSL and redirects

• SSL certificate installed and renewing as expected.
• HTTP to HTTPS redirect working.
• Non-www to www, or www to non-www, redirect behavior consistent.
• No redirect loops caused by proxy, CDN, or application settings.

Application behavior

• Forms send correctly and land in the right inbox or CRM.
• User login, password reset, and account creation work.
• Search, filters, media uploads, downloads, and admin edits behave normally.
• Scheduled jobs run on the new host.
• Cache invalidation works so changes appear when expected.

Performance and observability

• Error logging enabled and accessible.
• Monitoring, uptime checks, and alerting updated to the new IP or endpoint.
• CDN or caching configuration adjusted to match the new origin.
• Page speed, resource loading, and database response times checked on important pages, not just the homepage.

Commercial details

• Renewal dates and cancellation timing for the old host documented.
• Backups retained long enough to cover a late-discovered issue.
• Any temporary migration service, staging add-on, or premium feature reviewed so you are not surprised by ongoing charges later. This is also a good time to review Web Hosting Pricing Guide: Intro Rates, Renewals, and Hidden Costs to Check.

Common mistakes

If you want to reduce migration risk quickly, avoid these patterns. They are more common than any platform-specific technical problem.

• Changing too many variables at once. A host change, domain transfer, redesign, and email move bundled into one cutover is hard to troubleshoot.
• Testing only the homepage. Real failures usually appear in checkout, forms, login, search, API endpoints, and admin tools.
• Overlooking email DNS records. Website records and mail records are separate; a working site does not guarantee working email.
• Not keeping the old host active long enough. Canceling immediately removes your safety net.
• Skipping a rollback plan. Even a simple reversal path is better than improvising during an outage.
• Ignoring scheduled jobs and background tasks. Cron, queues, and webhooks often fail silently after a move.
• Assuming the new environment matches the old one. Different PHP versions, memory limits, file permissions, or server rules can change application behavior.
• Forgetting external dependencies. Payment gateways, email providers, analytics tools, and security services may need updated IP allowlists, callbacks, or verification records.
• Using nameserver changes when only a single record update is needed. This can unintentionally disrupt unrelated services.
• Not documenting the final state. Once the migration is stable, save the new configuration so the next move is easier.

In short, the safest site migration guide is the one that treats migration as change management, not just file transfer.

When to revisit

This checklist is worth revisiting any time the underlying workflow changes. You do not need an active migration scheduled to benefit from it. Review it before important business periods and whenever your infrastructure becomes more complex.

Revisit this checklist when:

• You are planning a hosting switch, redesign, or platform upgrade.
• You are adding ecommerce, membership features, or business email to an existing domain.
• You are moving from shared hosting to VPS hosting or cloud hosting.
• You are changing DNS providers, CDNs, or SSL management workflows.
• You have added new integrations, webhooks, scheduled jobs, or subdomains since the last migration.
• Your team has changed, and access credentials or responsibilities are no longer clear.
• You are entering a seasonal traffic period and want a safer rollback-ready plan before making infrastructure changes.

For a practical next step, copy this list into your own runbook and turn each item into a status field: not started, in progress, tested, and confirmed after launch. Add your domain records, app dependencies, and post-launch checks. A migration plan becomes much more reliable when it is specific to your environment rather than held in memory.

If you are preparing the move now, the simplest action sequence is this: inventory the current setup, take verified backups, build and test on the new host, update only the DNS records you actually need, monitor closely, and delay account cancellation until the new environment has proven stable. That sequence will prevent most avoidable hosting migration problems.