Website Migration Hosting Checklist: Move a Site With Minimal Downtime

Overview

Moving a website to a new host usually involves more than copying files. The site may depend on a database, scheduled tasks, environment variables, DNS records, SSL certificates, email services, third-party integrations, and application-specific configuration. A migration is complete only when the new environment serves the correct content, accepts real traffic, preserves important functionality, and can be supported after the old host is retired.

The safest approach is to separate the work into three phases:

• Prepare: inventory the current site, create verified backups, configure the destination, and reduce DNS time to live (TTL) ahead of the change.
• Transfer and test: copy the site and data, reproduce the required runtime settings, and test the destination using a temporary URL, hosts-file entry, or staging address.
• Cut over and verify: update DNS or the relevant routing layer, monitor the new host, check essential workflows, and keep a rollback option until the migration is proven stable.

The exact commands depend on the platform. WordPress typically requires files, a database, configuration values, and a review of URLs. A custom application may also need a build process, secrets, workers, queues, object storage, or deployment scripts. A static site is simpler, but its DNS, HTTPS, redirects, forms, analytics, and email records still need attention.

If the destination is a VPS, document the operating system, web server, PHP or other runtime version, database engine, firewall rules, backups, and deployment method before moving production traffic. For containerized applications, confirm that persistent volumes, environment variables, reverse-proxy rules, and database connectivity are represented in the new environment. The guides on hosting Docker containers on a VPS and deploying an open-source app on an Ubuntu VPS provide useful context for this type of setup.

Checklist by scenario

Before any migration

• Record the domain, DNS provider, registrar, current host, destination host, and the people responsible for approving the cutover.
• List every hostname in use, including the root domain, www, staging names, API subdomains, mail-related names, and any customer-facing subdomains.
• Record DNS records before changing anything. Include A, AAAA, CNAME, MX, TXT, and verification records.
• Inventory integrations such as payment providers, transactional email, analytics, webhooks, scheduled jobs, storage buckets, and authentication services.
• Confirm the destination supports the required runtime versions, database engine, extensions, storage, traffic pattern, and access method.
• Create a full backup of website files and databases. Store at least one copy outside the current host.
• Test that the backup can be opened or restored. A backup that has never been checked is only an assumption.
• Reduce DNS TTL before the migration if you control the records and expect to change them. Do this early enough for caches to age out; lowering TTL does not instantly clear every cached response.
• Choose a maintenance window based on real traffic and operational coverage, not simply the time that is convenient for the person performing the move.

WordPress hosting migration

• Put the site into maintenance mode only when necessary. For a busy site, plan a final database sync or briefly restrict writes so new orders, comments, accounts, or form submissions are not lost.
• Copy the wp-content directory and confirm that uploads, themes, plugins, and custom files are present. Review file ownership and permissions on the destination.
• Export and import the database using a method appropriate for its size. Check character sets, database credentials, table prefixes, and the database user’s permissions.
• Update the destination configuration with the new database host, name, user, password, salts, file paths, and environment-specific values.
• Verify the site URL and home URL without performing an unsafe blanket replacement. Serialized data and hard-coded references may require a WordPress-aware search-and-replace tool.
• Confirm that permalinks, media files, forms, logins, search, comments, ecommerce workflows, cron tasks, caching, and XML sitemaps work on the new host.
• Check PHP, database, plugin, and theme compatibility before switching DNS. For performance-related configuration, see the guide to speeding up WordPress on VPS hosting.

Custom applications and open-source software

• Document the build and start commands, runtime version, operating-system packages, environment variables, secrets, ports, workers, queues, and scheduled jobs.
• Move the database separately when appropriate, then verify migrations, indexes, users, permissions, connection limits, and time-zone behavior.
• Identify persistent data that is not part of the application repository, including uploaded files, generated reports, certificates, local caches, and user content.
• Recreate reverse-proxy rules, health checks, process supervision, firewall rules, log rotation, monitoring, and backup jobs.
• Test login, registration, file uploads, background jobs, webhooks, API authentication, and failure handling. Do not rely only on the application’s landing page.

For a container-based deployment, confirm that the new host has the required images, persistent volumes, network definitions, and secret values. A deployment that starts successfully but stores data in an ephemeral container filesystem is not ready for production.

Static websites

• Build the site from the same commit or source archive that is currently live, then compare the generated output with the existing deployment.
• Check relative and absolute asset paths, client-side routes, redirects, forms, search, analytics, and any server-side headers.
• Recreate custom response headers, compression, caching rules, redirects, and error pages on the destination.
• Confirm that HTTPS covers every hostname and that the hosting platform serves the expected certificate after DNS changes.

DNS and email during cutover

DNS changes should be treated as part of the migration, not as an afterthought. Update only the records that need to change, and preserve unrelated records. If the website and email use different providers, do not replace the entire zone with a simplified template. Preserve MX records and email-related TXT records such as SPF, DKIM, and DMARC when they are still required.

Before changing nameservers, export or record the complete zone. If you are pointing a domain to a VPS, review how to point a domain to a VPS. For a managed DNS setup, the Cloudflare DNS setup guide explains the records, nameserver, email, and SSL considerations to review.

What to double-check

Use a written acceptance list rather than relying on memory. At minimum, verify:

• Content: representative pages, images, downloads, metadata, and recent database records are present.
• URLs: canonical URLs, redirects, trailing-slash behavior, pagination, and internal links are correct.
• Security: HTTPS works, HTTP redirects as intended, administrative access is protected, secrets are not exposed, and temporary test accounts or files are removed.
• Application behavior: forms deliver messages, users can log in, transactions or submissions complete, and webhooks receive responses.
• Performance: pages load from the new host, caching behaves as expected, and resource limits are not being reached.
• Operations: backups run, logs are accessible, monitoring is configured, and someone knows how to restart or roll back the application.
• Search visibility: robots rules, sitemaps, status codes, and important redirects have not changed unintentionally.
• Email: website-generated messages arrive, the domain’s mail records remain intact, and the migration has not redirected mail to the wrong system.

Check the site from more than one network or use a DNS propagation check after the cutover. DNS visibility can differ between resolvers, and a successful lookup from one location does not prove that every visitor is reaching the destination. Keep the old host available while caches and remaining traffic settle.

Common mistakes

• Changing DNS before testing the destination: Build and verify the new site first. DNS should be the final routing step, not the test environment.
• Forgetting the final data sync: A database copied hours before cutover may miss orders, comments, accounts, or form submissions created afterward.
• Copying files but not the database: This can produce an older site, missing content, broken users, or configuration errors.
• Replacing the entire DNS zone: This may remove email, verification, or third-party service records that were unrelated to the website.
• Ignoring scheduled tasks: Cron jobs, workers, queues, and recurring imports often do not migrate automatically with website files.
• Assuming SSL will fix itself: Confirm domain coverage, certificate issuance, renewal, proxy mode if applicable, and redirects from HTTP to HTTPS.
• Retiring the old host immediately: Keep the previous environment intact until traffic, logs, email, and business-critical workflows have been checked.
• Skipping a rollback plan: Decide in advance which DNS or deployment change will reverse the move, who can approve it, and what data could be lost during rollback.

When to revisit

Revisit this checklist before every production migration, even if the new move resembles an earlier one. The risk profile changes when the application, DNS provider, hosting architecture, database size, email provider, or deployment workflow changes. Review it before seasonal planning cycles, major campaigns, platform upgrades, domain changes, and any move from managed hosting to a VPS or container platform.

Update your internal version whenever your tools or workflows change. Add provider-specific steps only after confirming them in a test environment, and remove steps that no longer apply. Keep the latest DNS export, backup location, access contacts, maintenance plan, test URLs, and rollback procedure with the migration record.

For the next move, start by copying this checklist into a task document. Assign an owner to each item, record the planned cutover time, perform a restore test, and define the conditions for rollback. After the site is live, run the verification list again at a later interval and document what failed, what required manual work, and what should change before the next migration.