How to Migrate a Website to a New Host Without Downtime: A Reusable Checklist

Overview

The safest way to move a website to a new host is to separate the migration into preparation, replication, testing, and DNS cutover. Your existing website remains live while you build and verify a working copy at the destination. Only after testing should you direct visitors to the new server.

“Without downtime” should be treated as a practical goal rather than an absolute promise. DNS caches, database writes, third-party services, and configuration differences can create a short period in which users reach different versions of the site. You can reduce that risk by planning the change, pausing or synchronizing writes where necessary, and keeping the old hosting account active until the new site is confirmed.

Before choosing a migration method, record the current environment. Note the operating system, PHP or application runtime version, web server, database engine and version, SSL setup, scheduled tasks, cron jobs, DNS records, email services, storage paths, and any external integrations. If the destination host does not support a required dependency, copying the files alone will not produce a working site.

If you are still evaluating the destination, review how to compare web hosting plans without getting misled by marketing. Check renewal costs and resource limits before moving production traffic, not only the introductory offer.

Checklist by scenario

Before every migration

• Choose a migration window with relatively low traffic and few planned site changes.
• Confirm access to the current host, new host, domain registrar, DNS provider, database, deployment tools, and email administrator account.
• Export a complete backup of website files, databases, configuration files, media, and application-specific uploads.
• Download or independently store at least one backup outside both hosting accounts. Test that the archive can be opened and that the database can be imported.
• Record DNS records, including A, AAAA, CNAME, MX, TXT, and any verification or subdomain records. Do not assume the new provider will recreate them automatically.
• List every hostname that must work after the move: the root domain, www, staging, API endpoints, mail subdomains, and other application subdomains.
• Reduce the DNS TTL for records you plan to change, if your DNS provider permits it. Do this ahead of the cutover so resolvers are more likely to refresh the record promptly. Existing caches may still retain the previous value.

For a static website

• Copy the complete document root, including hidden files such as configuration files and verification files.
• Recreate redirects, custom error pages, security headers, cache rules, and build or deployment settings.
• Test relative and absolute asset paths, image files, forms, downloads, and client-side routes on a temporary hostname or hosts-file override.
• Confirm that the new server serves the correct index file and does not expose directory listings or private files.

For WordPress or another database-driven site

• Copy application files and export the database using the application’s supported tools or the host’s database utilities.
• Create the destination database and user, then import the database and update connection credentials in the configuration file.
• Check the site URL, home URL, serialized data, upload paths, cache settings, and environment-specific values. Use an application-aware search-and-replace method rather than a blind text replacement where serialized data may be present.
• Match the required runtime version and install needed extensions, themes, plugins, packages, or system libraries.
• Temporarily disable caching, queued jobs, or write-heavy features if they could make the test copy inconsistent with production. Re-enable and validate them before cutover.

For an online store, membership site, or active application

• Identify data that changes during the migration, such as orders, customer accounts, comments, bookings, messages, or inventory.
• Perform an initial copy while the old site remains live, then schedule a short maintenance or read-only period for the final database synchronization.
• Document payment, webhooks, API keys, callback URLs, background workers, queues, and scheduled tasks. Test them in a controlled way without creating duplicate transactions.
• Take a final backup immediately before the DNS change and retain the old site until transactions and user logins are confirmed on the new host.

For email and domain hosting

• Determine whether email is staying with the current provider or moving with the website. Website hosting and email hosting can be separate services.
• If email is staying where it is, preserve the existing MX, SPF, DKIM, and DMARC records unless your mail provider instructs you to change them.
• If email is moving, create mailboxes and aliases before changing MX records. Confirm passwords, forwarding rules, mailbox quotas, and migration or import requirements.
• Check TXT records used by email, analytics, payment providers, webmaster tools, and other services. Missing verification records can break integrations even when the website loads.

For developer-led migrations, confirm SSH access, Git deployment, staging support, cron configuration, logs, and command-line tools before committing to the move. The developer hosting comparison covers the capabilities that commonly affect this workflow.

What to double-check before cutover

Build a private test copy on the new host using its temporary URL, preview address, staging domain, or a local hosts-file entry. Avoid changing public DNS until the following checks pass:

• Open representative pages with and without trailing slashes, query strings, and URL parameters.
• Test the homepage, navigation, search, forms, login, password reset, uploads, downloads, comments, checkout, and other business-critical paths.
• Inspect browser developer tools and server logs for missing assets, 404 responses, redirect loops, permission errors, mixed content, and application warnings.
• Verify that HTTP redirects to HTTPS, the SSL certificate covers every required hostname, and canonical URLs remain correct.
• Compare robots.txt, XML sitemaps, noindex settings, analytics tags, consent tools, and search verification files with the production site.
• Confirm file ownership and permissions. The web process should be able to read required files without making sensitive configuration files publicly accessible.
• Run a basic performance check from more than one network or location and compare the result with the old host. A change in server location, caching, DNS, or runtime configuration can affect speed.
• Test backups, restore instructions, monitoring, error logging, cron jobs, and deployment access on the destination.

At cutover, make the planned DNS change, record the exact time and new values, and monitor both hosts. Because DNS propagation is not instantaneous, keep the old website available and avoid making uncoordinated content changes until traffic has settled on the new server. Verify the site using different networks, devices, and DNS resolvers where practical.

Common mistakes and troubleshooting

Changing DNS before testing: This turns the live domain into a test environment. Copy and validate the site first, then switch DNS.

Forgetting hidden files: Missing rewrite rules or environment files can cause broken routes, failed deployments, or incorrect security behavior. Include hidden files in the transfer and compare directory contents.

Copying a database only once: A busy site may receive new orders or user data after the first export. Use a final synchronization plan for applications with ongoing writes.

Assuming email follows the website: The website’s A record and email’s MX record serve different purposes. Preserve or deliberately recreate all mail records.

Ignoring DNS records outside the root domain: API, verification, staging, and marketing tools may rely on subdomains and TXT records. Export the entire DNS zone or create a manual inventory.

Closing the old account too soon: Keep the previous host, backups, and access credentials until the site, email, forms, transactions, and scheduled tasks have been checked after cutover.

If the new site shows a database connection error, recheck the database name, username, password, host value, permissions, and runtime extensions. For a 500 error, inspect application and server logs, then compare runtime versions and rewrite rules. If pages redirect repeatedly, review HTTPS enforcement, proxy settings, canonical redirects, and application URL values. If email stops working, compare MX, SPF, DKIM, and DMARC records with the mail provider’s required configuration.

For SSL-specific problems, use the troubleshooting steps in how to set up SSL and fix common HTTPS errors. For post-migration speed issues, use this guide to speeding up a website on any host.

When to revisit this checklist

Save this checklist with the project’s deployment documentation and revisit it before every hosting change, major redesign, domain transfer, platform upgrade, or seasonal traffic cycle. It should also be reviewed when your host changes its control panel, backup process, staging tools, PHP or application runtime options, DNS provider, or email platform.

After each migration, record what differed from the plan: the final database method, DNS values, propagation observations, failed tests, rollback decision, and the date the old host was retired. That short post-migration note makes the next move faster and reduces dependence on memory.

Final action list: make and test an independent backup; inventory files, databases, DNS, email, and integrations; lower TTL in advance; copy the site; test on the destination; plan final data synchronization; document rollback; change DNS; monitor both hosts; and only close the old account after successful verification.