Website Migration Checklist: How to Move Hosting Providers Without Downtime

Overview

A hosting migration usually involves more than copying website files. You may also need to move databases, email accounts, scheduled tasks, SSL certificates, DNS records, application settings, and domain-related services. The safest approach is to separate the migration into two phases: prepare the new environment while the existing site remains live, then switch traffic only after the new copy has been tested.

Before starting, record the current setup. Note the website document root, database engine and name, PHP or application runtime version, installed extensions, cron jobs, server-level redirects, DNS records, email configuration, SSL arrangement, CDN settings, and any external services that depend on your domain. This inventory becomes both a migration plan and a verification list.

Choose a maintenance window only if your site has changes that are difficult to synchronize, such as frequent orders, user registrations, bookings, or comments. For a mostly static website, a carefully timed DNS change may be enough to avoid visible interruption. For a transactional site, plan a final database or content synchronization and consider temporarily restricting writes during the handover.

If you are comparing the destination environment before moving, review how shared, WordPress, VPS, and cloud hosting differ in the web hosting comparison guide. The right destination should support your application requirements, not merely offer available storage.

Checklist by scenario

For any website migration

• Confirm ownership and access for the domain registrar, current host, destination host, DNS provider, CDN, and email platform.
• Make a full backup of website files, databases, configuration files, and mailbox data where applicable. Store at least one copy outside the current hosting account.
• Export or document DNS records, including A, AAAA, CNAME, MX, TXT, and any verification records.
• Check the new hosting account’s operating system, runtime versions, extensions, storage limits, database support, firewall rules, and backup options.
• Copy the website to the new server without changing the live DNS yet.
• Test the copied site through a temporary URL, preview address, hosts-file entry, or staging domain.
• Confirm file permissions, environment variables, database credentials, application secrets, and writable directories.
• Reduce DNS record time to live before the planned switch when your DNS provider allows it. Remember that resolvers may still retain records for a period of time.
• Prepare a written cutover time, owner, test checklist, and rollback decision.

For WordPress hosting migrations

• Copy the WordPress files and database together, and confirm that the site URL values match the intended domain.
• Check the PHP version, enabled extensions, memory limits, upload limits, rewrite rules, and scheduled tasks on the destination.
• Verify that themes, plugins, media files, and custom code are present. Do not assume a backup restored every generated or excluded file.
• Clear caching layers only after the new site is functional. Test logged-in and logged-out views separately.
• Review forms, search, memberships, ecommerce functions, webhooks, and third-party API connections.

A separate staging copy is especially useful when you need to test a new PHP version, database version, control panel, or server configuration. The guide to staging and production environments explains how to keep testing changes away from the live site.

For websites with email

• List every mailbox, alias, forwarder, autoresponder, distribution address, and mobile or desktop mail client.
• Decide whether email will remain with the existing provider or move with the website. Website hosting and email hosting do not have to be on the same service.
• If MX records will change, plan the switch carefully and preserve the required SPF, DKIM, and DMARC records.
• Export or migrate mailbox data before cancelling the old account, then test sending and receiving from several external addresses.

For ecommerce or frequently changing sites

• Identify the systems that write data: orders, carts, customer accounts, inventory, forms, comments, and booking calendars.
• Take a final backup immediately before cutover and perform a final synchronization if the platform supports it.
• Test payment callbacks, shipping integrations, tax settings, transactional email, account login, and order status updates.
• Keep the old environment available until you have verified recent transactions and confirmed that rollback is no longer needed.

What to double-check

DNS timing: DNS changes do not reach every visitor simultaneously. During propagation, some users may reach the old server while others reach the new one. Keep both environments capable of serving the site during this overlap, and avoid making content changes on only one server.

SSL and canonical hostnames: Test HTTP to HTTPS redirects, the preferred www or non-www version, certificate coverage for every required hostname, and mixed-content warnings. If SSL is managed by the new host, confirm that certificate issuance and renewal are active before changing DNS. For background on certificate choices, see SSL certificates explained for hosting.

Redirects and search paths: Preserve existing URLs whenever possible. If URL structures change, create one-to-one 301 redirects rather than sending many old pages to the homepage. Test important legacy URLs, canonical tags, XML sitemaps, robots directives, and analytics or search verification settings.

Application behavior: Browse key pages anonymously and while logged in. Submit forms, upload a file, search the site, complete a checkout if applicable, and inspect server and application logs for errors. A homepage that loads successfully is not proof that the migration is complete.

Backups and rollback: Confirm that destination backups actually run and can be restored. Record the old DNS values, preserve the old hosting account, and define the conditions for reverting traffic. A rollback plan is useful only when its steps are clear and access has been tested.

Common mistakes

• Changing the domain registrar and hosting at the same time: A domain transfer is separate from a hosting migration. Keep the move understandable by changing one major dependency at a time unless there is a strong operational reason to combine them.
• Skipping an independent backup: A host-generated backup may be inaccessible after an account problem or cancellation. Download a copy and verify that it contains the files and database you need.
• Testing only through the temporary URL: Some applications behave differently when the real hostname, HTTPS, cookies, or callback URLs are involved. Test the final domain before declaring success.
• Forgetting hidden services: Cron jobs, webhooks, API keys, DNS verification records, firewall allowlists, image storage, and monitoring checks can fail even when the visible site works.
• Closing the old host too early: Keep it available through the DNS overlap and verification period. Do not rely on memory to recreate missing files or records later.
• Ignoring performance and limits: Confirm that the new plan has adequate CPU, memory, storage, database connections, process limits, and bandwidth for normal and peak workloads. Hosting speed is a configuration and capacity concern, not just a marketing label.

When to revisit

Use this checklist before every hosting provider change, major server rebuild, domain transfer, or platform upgrade. Revisit it before seasonal planning cycles if your website has predictable traffic peaks, sales periods, registrations, or publishing deadlines. It is also worth updating whenever your hosting control panel, deployment workflow, DNS provider, backup tool, CDN, email platform, or application stack changes.

For the next migration, turn this article into a project document. Add the actual DNS records, account owners, backup locations, test URLs, maintenance window, and rollback threshold. Assign each task to a named person, take a timestamped backup, and do not cancel the old service until the new site, email, SSL, redirects, monitoring, and backups have all passed review. For a broader reference, keep the complete website migration checklist alongside your operational runbook.