How to Move a Website to New Hosting Without Downtime

Overview

A successful website migration separates the work into two tracks: preparing an identical or improved copy on the new host, and changing the routing that sends visitors to it. The site can usually be built and tested on the new server before the public DNS records are changed.

The main risk is not copying files alone. A website may also depend on databases, scheduled jobs, environment variables, server versions, caching rules, payment integrations, contact forms, email records, SSL certificates, and background services. Create an inventory before moving anything.

1. Document the current environment: record the domain names, DNS records, PHP or runtime version, database type, application version, cron jobs, redirects, subdomains, email services, SSL configuration, and third-party integrations.
2. Choose a migration window: select a period with low expected activity. Avoid launching immediately before a campaign, product release, billing cycle, or other event that depends on the website.
3. Confirm access: make sure you can access the current host, new host, domain registrar, DNS provider, email provider, and any required deployment or repository systems.
4. Set a rollback point: keep the old hosting account active until the new environment has passed testing and the post-launch observation period is complete.

Before starting, review your website backup and restore checklist. A backup is only useful for rollback if you know where it is stored and have verified that it can be restored.

Checklist by scenario

For a static website

• Export or copy the complete document root, including hidden files such as configuration files.
• Check that asset paths, redirects, forms, API endpoints, and environment-specific settings are correct.
• Replicate custom headers, compression rules, cache settings, and redirect rules on the new host.
• Test every important page, image, stylesheet, script, download, and form using a temporary hostname or hosts-file override.

For WordPress or another database-driven site

• Put the application into maintenance mode only if needed; avoid leaving it there while you complete unrelated setup work.
• Export the database and copy all application files, including uploads, themes, plugins, and configuration files.
• Create the database and database user on the new host, then import the backup and update connection details.
• Check the site URL, rewrite rules, file permissions, scheduled tasks, media URLs, and any caching or security plugins.
• If content can change during the migration, plan a final database export or a short content freeze immediately before DNS changes.

For WordPress-specific performance checks after the move, use the guidance in How to Speed Up a Website on Any Host. A new server will not automatically correct inefficient queries, oversized images, or unnecessary extensions.

For an ecommerce or frequently updated website

• Identify every source of changing data, including orders, customer accounts, inventory, bookings, comments, and form submissions.
• Do not rely on a stale copy of the database. Use a final synchronization plan, maintenance window, or application-supported migration method.
• Test checkout, payment callbacks, tax or shipping integrations, account login, order notifications, and transactional email in the appropriate test mode.
• Confirm that the new server has suitable resource limits and that background jobs continue to run.

For email and domain changes

Website hosting and email hosting may be separate. Inventory the domain's A, AAAA, CNAME, MX, TXT, and any verification records before editing DNS. If email remains with the existing provider, preserve its MX and authentication records. If email is moving too, schedule that work separately where possible and verify mailboxes, forwarding, SPF, DKIM, and DMARC settings with the mail provider.

Lower the DNS TTL for the records you plan to change before the migration. A lower TTL can help resolvers refresh the records sooner, but it does not eliminate caching or guarantee that every visitor will switch at the same time. Read How to Move a Website With Minimal DNS Propagation Issues for a focused DNS checklist.

What to double-check before switching DNS

1. Backups: retain a recent copy of files and databases outside the hosting account. Confirm the backup date and test a restore of critical data.
2. DNS records: compare the old zone with the intended new zone. Include subdomains, verification records, mail records, and records used by external services.
3. SSL: install and test certificates for the root domain, www hostname, and important subdomains. Confirm that HTTP redirects to HTTPS and that mixed-content warnings are not introduced. See SSL Certificates Explained for certificate considerations.
4. Application configuration: check secrets, environment variables, database credentials, API keys, file permissions, runtime versions, and writable directories.
5. URLs and redirects: test canonical URLs, trailing-slash behavior, old page redirects, robots.txt, XML sitemaps, and any custom 404 page.
6. Monitoring: configure uptime, error, and performance checks before launch so you can compare the new host with the old one. The website monitoring checklist can help define the checks.

To test privately, use the new host's temporary URL, a staging domain, or a local hosts-file entry that maps the domain to the new server's IP address. Test from more than one network when possible, but do not change public DNS until the application behaves as expected.

When ready, update only the necessary DNS records. Record the exact time and values of the change. Keep the previous records documented so they can be restored quickly if required.

Common mistakes and troubleshooting

• Copying files without the database: this often produces an empty, outdated, or partially working site. Confirm the database export and import separately.
• Forgetting hidden configuration files: missing rewrite or environment files can cause 404 errors, redirect loops, or failed application connections.
• Changing nameservers too early: nameserver changes can affect the entire DNS zone, including email. Prefer changing only the required records unless you have intentionally rebuilt the complete zone.
• Testing only the homepage: check forms, login, search, checkout, downloads, images, admin functions, and key landing pages.
• Leaving the old site writable: if visitors can submit data or place orders on the old host after the new site is live, records may split between environments.
• Ignoring SSL and redirects: a site may appear available while HTTPS, www handling, or legacy URLs fail.

If the site fails after the switch, first compare DNS resolution from several networks and confirm that the expected server is receiving requests. Then inspect web-server and application logs, verify database credentials, check runtime compatibility, and test the certificate. If data is missing or transactions are inconsistent, place the site in a controlled maintenance state and follow the rollback plan rather than making unrecorded changes under pressure.

Rollback checklist

• Restore the previous DNS records or nameservers from your documented copy.
• Keep the new environment unchanged so logs and failed requests remain available for diagnosis.
• Identify whether new submissions, orders, or account changes occurred during the attempted cutover.
• Restore from the verified backup only after confirming which data must be preserved.
• Notify affected users or internal teams if email, orders, or account access were interrupted.
• Record the cause and revise the migration plan before attempting another switch.

When to revisit this checklist

Revisit the checklist before every hosting change, major domain or DNS change, platform upgrade, infrastructure redesign, or seasonal planning cycle. It is also worth reviewing when the website begins handling more traffic, transactions, integrations, or geographic regions than the original migration plan assumed. A move from shared hosting to managed WordPress hosting, VPS hosting, or scalable cloud hosting may introduce different runtime, security, monitoring, and backup requirements.

Update the document whenever workflows or tools change. Record the current host, DNS provider, certificate process, backup location, deployment method, responsible contacts, and rollback steps. After the migration, compare uptime, response time, error rates, form delivery, email delivery, and resource usage with your baseline. The hosting performance guide provides a useful starting point.

Final action: do not schedule the DNS cutover until you can answer yes to these questions: Is there a tested backup? Has the new site been tested privately? Are DNS and email records documented? Are SSL and redirects working? Is monitoring active? Is the old host available for rollback? If the answer to any question is no, finish that item first. A careful migration is usually less about speed than about making each step observable, reversible, and deliberate.