How to Migrate a Website to New Hosting With Minimal Downtime

Overview

A hosting migration changes the infrastructure that serves your website, but the domain name can remain the same. In a typical move, the website files and database are copied to a new server, the application is configured there, and DNS is updated so visitors reach the new host.

The safest approach is to treat the migration as two separate activities: preparing and testing the new environment, then switching traffic. Most of the work should be completed before the DNS change. DNS propagation can take time and may differ between networks, so the old hosting account should remain available until the new service has been verified.

Before starting, record the current setup. Note the operating system or control panel, runtime versions, database engine and version, scheduled jobs, outbound email configuration, SSL setup, CDN settings, DNS records, storage paths, and any external services connected to the site. If you are moving WordPress, also document the site URL, active plugins, caching layers, cron behavior, and PHP requirements. The developer hosting checklist can help identify infrastructure details that are easy to overlook.

A migration is a good opportunity to improve the hosting environment, but avoid changing several major components at once. Moving hosts, changing the CMS, altering URLs, and redesigning the site in one operation makes troubleshooting and rollback much harder.

Checklist by scenario

For any website migration

1. Confirm access. Verify access to the current hosting account, new hosting account, domain registrar, DNS provider, database, deployment tools, and email administration.
2. Review capacity. Check the new plan’s storage, memory, CPU allocation, database support, runtime versions, bandwidth model, backups, logs, SSH access, and scheduled task support. The new environment should meet the application’s actual requirements rather than only matching the old plan’s marketing category.
3. Create a complete backup. Export the database and copy all website files, including uploads, configuration files, custom themes, certificates where appropriate, and server-side scripts. Store the backup separately from both hosting accounts and confirm that it can be opened or restored. See the guide to website backups and restore testing for a more thorough process.
4. Lower DNS time to live in advance. If you control DNS, reduce the relevant record TTL before the planned cutover. This does not guarantee instant propagation, but it can reduce the duration that some resolvers retain the old destination.
5. Build the new environment. Create the site, database, users, permissions, runtime configuration, environment variables, and scheduled jobs. Keep secrets out of public directories and avoid copying credentials into temporary files.
6. Transfer and test. Import the database, copy files, update connection settings, and test the site through a temporary hostname, hosts-file entry, staging domain, or provider preview URL. Do not rely only on the homepage.
7. Plan the cutover. Choose a low-traffic period, announce any expected maintenance if needed, take a final backup, and define who is responsible for DNS, application checks, and rollback.

For WordPress and database-driven sites

• Put the site into maintenance mode only for the final synchronization, not for the entire preparation period.
• Copy the database and wp-content or equivalent content directories, while checking that file ownership and permissions are correct.
• Confirm the new PHP, database, web server, and plugin requirements. Test forms, search, logins, media, redirects, ecommerce functions, and administrative screens.
• Check whether caching, security, image optimization, or backup plugins store data outside the database or public uploads directory.
• Decide how to handle content changes during the migration window. For active sites, use a final database export or a documented synchronization method so new orders, comments, accounts, or submissions are not lost.

For staging details, review how to set up a staging site. A staging copy should be protected from indexing and should not accidentally send production email or process live payments.

For sites with business email

Do not assume that moving web hosting moves email safely. First determine whether email is hosted with the current web host, a dedicated email provider, or another service. Preserve the required MX, SPF, DKIM, and DMARC records, and confirm mailbox credentials, aliases, forwarding rules, quotas, and retention settings. If email remains with a separate provider, change only the web-related DNS records. The business email setup guide covers the records that commonly need review.

For applications and developer-managed infrastructure

Recreate deployment keys, repository webhooks, environment variables, workers, queues, cron jobs, log rotation, firewall rules, and monitoring alerts. Confirm that the application can reach required databases, APIs, object storage, payment systems, and mail relays. Keep a record of every manual change so the new environment can be reproduced rather than becoming an undocumented one-off server.

What to double-check

Before changing DNS

• The new site loads correctly over its temporary test address.
• The production database is current, and the final content synchronization procedure is understood.
• Canonical URLs, redirects, robots rules, sitemap files, and analytics settings are correct.
• SSL has been issued or provisioned for every required hostname, including the www version if used. Test both HTTP-to-HTTPS behavior and certificate coverage.
• DNS records for the website, email, verification services, subdomains, APIs, and third-party platforms are documented.
• Backups exist in a separate location, and the old host will remain accessible during the observation period.
• Monitoring is ready for uptime, response errors, certificate status, and key application transactions. Use the uptime monitoring guide to define useful checks.

During the cutover

Take the final backup, pause or limit writes if necessary, complete the last database transfer, and update the relevant DNS records. Record the exact time and values changed. Check DNS from more than one network or resolver, but remember that a local result is not proof that every visitor has reached the new host.

After the cutover

Test the homepage, key landing pages, internal links, forms, logins, checkout or booking flows, uploads, search, redirects, and administrative functions. Review server and application logs for errors. Check that email delivery still works and that SPF, DKIM, and DMARC remain aligned where applicable. Confirm that the site is not displaying a staging URL, exposing debug output, or sending users to the old server.

Keep the old hosting account active until traffic, logs, DNS resolution, SSL, and business-critical workflows are stable. Only then should you cancel the old service or remove the rollback copy.

Common mistakes

• Changing DNS before testing the copy: This turns the public site into the test environment and increases pressure to troubleshoot in production.
• Forgetting hidden files: Files such as environment configuration, rewrite rules, deployment manifests, and access-control files may not appear in a basic file-manager copy.
• Copying files without the database: A database-driven site may look present while losing content, users, settings, or orders.
• Ignoring write activity: A database export taken too early can omit recent transactions, comments, registrations, or form submissions.
• Assuming email follows the website: Web DNS and mail DNS are related but separate. Replacing all DNS records can interrupt mail even when the website works.
• Using the wrong permissions or runtime: Incorrect ownership, PHP versions, extensions, database settings, or file permissions can produce blank pages and intermittent failures.
• Letting both environments send live messages: A staging copy can send duplicate emails, trigger jobs twice, or interact with production services unless outbound actions are disabled.
• Closing the old account immediately: A rollback requires a working source. Keep the old environment and backups until verification is complete.

For broader hardening after the move, compare the result with this web hosting security checklist. Migration is not complete if the site works but administrative access, backups, firewall rules, or malware monitoring remain unconfigured.

When to revisit

Revisit this checklist before each major migration, hosting plan change, infrastructure redesign, or seasonal traffic period. It is also worth reviewing after changes to the CMS, runtime, control panel, DNS provider, email platform, deployment workflow, CDN, or backup system. Tools and hosting interfaces change, so update the commands and screenshots in your internal runbook rather than assuming an old procedure still applies.

As a practical final pass, save a migration record containing the date, DNS changes, backup locations, test results, unresolved issues, and rollback deadline. Then run this short verification sequence:

1. Resolve the domain and confirm it reaches the intended server.
2. Open important pages from more than one network.
3. Submit a test form and verify its destination.
4. Test login, uploads, search, purchases, bookings, or other critical workflows.
5. Send and receive a test email if mail settings were involved.
6. Inspect logs, uptime checks, SSL status, redirects, and analytics.
7. Confirm backups are running on the new host and that a restore path is documented.
8. Keep the old host available until the agreed rollback window has passed.

A controlled migration is usually uneventful because the difficult decisions were made before the DNS cutover. Treat the process as a repeatable infrastructure change, document what you learn, and update the checklist whenever your hosting workflow changes.