How to Migrate a Website to New Hosting Without Downtime

Overview

A hosting migration is more than copying website files. A complete move may involve a database, uploaded media, scheduled tasks, server settings, SSL certificates, domain records, email services, analytics, payment forms, and third-party integrations. Missing one dependency can produce broken pages, failed forms, lost messages, or an avoidable period of downtime.

The safest approach is to separate the migration into stages. Keep the existing site running while you prepare the new server. Copy the site and database, test the copy privately, lower DNS time-to-live (TTL) values before the change, then switch traffic only after the new environment is ready. Do not cancel the old hosting account until the new site and all related services have been checked.

Before starting, confirm what is actually moving. A site may use one provider for web hosting, another for domain registration, and a separate service for email or DNS. Changing web hosting alone should not require changing the domain registrar or email provider. If domain ownership or registrar access also needs to change, treat that as a separate project and review a domain transfer checklist before proceeding.

Checklist by scenario

For any website migration

1. Assign an owner and a maintenance window. Choose a period when traffic and business activity are relatively low, but allow enough time for testing and DNS troubleshooting. Record who can approve the cutover and who can restore the previous configuration.
2. Inventory the current environment. Record the domain and subdomains, DNS provider, nameservers, A and AAAA records, CNAME records, MX records, TXT records, redirects, cron jobs, PHP or runtime version, database engine and version, storage locations, SSL setup, CDN, firewall, analytics, forms, APIs, and external integrations.
3. Confirm access. You should be able to access the current hosting control panel, server or SFTP account, database, DNS management, domain registrar, email administration, and the new hosting account. Store recovery details securely rather than in a shared document containing plain-text passwords.
4. Take and verify backups. Save a complete copy of website files and a database export in a location separate from the current host. Check that the archive opens, the database file is present, and the backup represents recent content. A backup is not a migration plan until it can be restored; use the backup testing workflow to validate it.
5. Prepare the destination. Match the required runtime, database version, extensions, web-server settings, file permissions, document root, redirects, and scheduled tasks. If the new platform differs substantially, document each configuration change instead of assuming the old settings will translate automatically.
6. Copy files and data. Transfer the application files, uploads, themes, plugins, configuration files, and database. Update connection details for the new database, but keep a copy of the original configuration before editing it.
7. Test privately. Use a temporary address, staging feature, local hosts-file entry, or another access method that does not expose an unfinished site to the public. Check representative pages, not only the home page.
8. Lower DNS TTL before cutover. If you control the relevant DNS records, reduce their TTL ahead of the planned change so resolvers can refresh the destination more readily. The exact timing depends on the previous TTL and resolver behavior; lowering a value does not instantly clear caches that already contain the old value.
9. Make the final sync. Immediately before cutover, copy new uploads and recent database changes. For an active site, place it in maintenance mode or temporarily pause writes only if necessary and acceptable for the business.
10. Change only the required DNS records. Update the web records that should point to the new host. Avoid replacing nameservers or editing email records unless that is part of the planned migration. Use a DNS record reference such as the DNS records guide to distinguish web, mail, verification, and service records.
11. Monitor and retain the old host. Check the site from more than one network and continue monitoring the old environment during the DNS transition. Keep the previous site available until traffic is consistently reaching the new server and rollback is no longer needed.

For WordPress

Put WordPress into a controlled state before the final database export. Record the WordPress version, active theme, plugins, upload directory, permalink structure, site URL, home URL, and any cache or security settings. Disable or pause jobs that could write data during the final sync, such as scheduled imports, membership activity, orders, comments, or form submissions.

On the new host, confirm that the database credentials work, the correct PHP extensions are enabled, permalinks resolve, and uploads retain their expected paths. Clear application, server, CDN, and browser caches after testing. Do not perform a broad search-and-replace on the database without a rollback plan; serialized WordPress data can be damaged by unsuitable replacement methods. For platform choices and deployment patterns, compare the relevant hosting options for developers and managed WordPress.

For sites with business email

First decide whether email is moving. If email remains with its current provider, preserve the MX records and related SPF, DKIM, and DMARC records. Test sending and receiving from internal and external addresses after the web cutover. If email is moving too, export or otherwise preserve mailboxes, aliases, forwarding rules, calendars, and contacts according to the provider’s process, then plan that work separately from the website switch. Review the email authentication audit guide before changing mail records.

What to double-check after cutover

• DNS: Confirm A, AAAA, CNAME, MX, TXT, and verification records from more than one resolver or network. Check that the intended hostname resolves to the new server and that an old IPv6 record is not directing some visitors elsewhere.
• HTTPS: Visit the HTTP and HTTPS versions of the domain, confirm the certificate covers every required hostname, and check for mixed-content warnings. Review the SSL troubleshooting guide if browsers show certificate or redirect errors.
• Content and navigation: Open the home page, key landing pages, category pages, search, images, downloads, PDFs, and representative old URLs. Check that internal links, canonical tags, robots directives, and XML sitemaps are still correct.
• Transactions and forms: Submit contact, signup, checkout, booking, and download forms in a controlled way. Confirm validation, confirmation pages, notifications, webhooks, payment callbacks, and CRM connections.
• Performance and server behavior: Check response times, caching, compression, logs, error rates, resource limits, scheduled jobs, queues, and background workers. A site can appear visually correct while a cron job or API integration is failing.
• Search visibility: Confirm that the site is not accidentally blocked by a staging robots file, password protection, noindex directive, or incorrect canonical URL. If URLs changed, preserve redirects and investigate crawl errors rather than assuming DNS alone will protect rankings.
• Backups and recovery: Configure backups on the new host and perform a small restore test. Hosting migration is complete only when the new environment can be recovered, not merely when pages load.

Common mistakes

Changing nameservers without an inventory. A nameserver change can move control of every DNS record, including email and third-party verification. If only the website is changing, update only the necessary web records unless you have intentionally rebuilt the full DNS zone.

Testing only the homepage. Broken database queries, uploads, redirects, forms, and scheduled tasks often appear deeper in the site. Use a page and feature inventory that reflects real business activity.

Forgetting new content during the final copy. An early database export may omit recent orders, comments, accounts, or form entries. Plan a final sync and define how write activity will be handled during the cutover.

Deleting the old account too soon. DNS caches do not change everywhere at the same moment. Keep the old environment, backups, DNS records, and access credentials until validation is complete and your rollback period has passed.

Assuming identical server settings. Differences in PHP modules, file permissions, database versions, rewrite rules, case sensitivity, mail delivery, or environment variables can cause failures that are invisible in a basic visual test.

Skipping email tests. A website migration can leave the page online while contact notifications disappear. Verify both inbound and outbound mail, then check authentication records if mail services were touched.

When to revisit

Reuse this checklist before every hosting change, major platform upgrade, domain or DNS redesign, seasonal traffic period, or infrastructure consolidation. Revisit it after a failed cutover, an unexpected rollback, a security incident, or a restore test that exposes missing files or configuration.

Update the operational details whenever your hosting panel, CMS, runtime, backup tool, DNS provider, CDN, or email platform changes. Paths and button names in control panels can change, while the underlying sequence—inventory, backup, staging, testing, controlled DNS cutover, monitoring, and rollback—remains useful.

Before acting, print or copy the following short runbook:

1. List every service and record involved.
2. Verify a restorable backup.
3. Build and privately test the new environment.
4. Lower relevant DNS TTL values in advance.
5. Define the final sync and cutover time.
6. Test DNS, HTTPS, content, forms, email, integrations, logs, and backups.
7. Write down rollback triggers, such as failed transactions, missing data, persistent server errors, or broken email.
8. Keep the old host available until the agreed validation period ends.

For domain and hosting projects, preparation is the main protection against downtime. A staged migration gives you evidence at each step, making it easier to move forward confidently or restore the previous setup before a small issue becomes a business interruption.