How to Migrate a Website to New Hosting Without Downtime

Overview

A hosting migration changes more than the server that delivers your pages. Depending on the site, you may also be moving databases, uploaded files, email settings, scheduled jobs, SSL configuration, PHP or application versions, and deployment processes. The safest approach is to separate the work into two phases: prepare and test the new host while the current site remains live, then make a short, controlled DNS change.

“Without downtime” should be treated as a practical operational goal rather than a promise that every request will behave identically during propagation. A correctly staged migration can keep the old site available while visitors gradually begin reaching the new server. The key is to avoid making the old environment dependent on the new one before you have verified the cutover.

Before choosing a destination, compare its resource limits, runtime versions, backup options, access methods, security controls, and support model. A web hosting comparison checklist can help you assess whether the new plan fits the site rather than focusing only on headline features.

Migration inventory

• Domain names, subdomains, and DNS providers.
• Website files, media, themes, plugins, and private uploads.
• Databases, database users, connection settings, and character sets.
• PHP, Node.js, Python, or other runtime versions and required extensions.
• SSL certificates, redirects, canonical settings, and security headers.
• Email accounts, forwarding rules, SPF, DKIM, and DMARC records.
• Cron jobs, queues, webhooks, API integrations, and external callbacks.
• Deployment credentials, environment variables, logs, monitoring, and backups.

Record the current configuration before changing anything. Screenshots can help with control panels, but exportable configuration and a written list are easier to audit and reproduce.

Checklist by scenario

For a static website

1. Export the complete site, including generated assets and files that are not visible in the main repository.
2. Recreate the build process or upload the production output to the new host.
3. Test internal links, forms, downloads, images, scripts, and custom error pages on a temporary hostname or hosts-file override.
4. Confirm that redirects and clean URLs work on the new server.
5. Check the final directory and file permissions, then prepare the DNS cutover.

For WordPress or another database-backed CMS

1. Put the site into a controlled maintenance or content-freeze window if new orders, comments, accounts, or edits could be lost during the final sync.
2. Copy the files and import a recent database backup into the new hosting account.
3. Update the application configuration with the new database name, user, password, host, and table settings.
4. Verify the supported PHP or runtime version and required extensions. If the versions differ, test plugins, themes, forms, payment flows, and administration screens before switching traffic.
5. Use a temporary URL, staging domain, or local hosts-file entry to test the migrated copy. Avoid changing public URLs unless the site structure is intentionally being redesigned.
6. Run a final database and uploads sync immediately before the DNS change, then repeat the checks after cutover.

For WordPress specifically, review cache settings, scheduled tasks, writable directories, permalink behavior, and image generation. The WordPress hosting performance checklist is useful after the site is stable and serving real traffic.

For an online store or application

1. Identify every transaction, login, webhook, and background process that must remain consistent.
2. Choose a low-risk cutover window based on your traffic and operational calendar.
3. Freeze content or put the application into a controlled read-only or maintenance state for the final synchronization.
4. Confirm payment, authentication, email, inventory, search, and third-party integrations on the new host.
5. Keep the old environment available until orders, jobs, logs, and customer-facing workflows have been verified.

For a developer-managed deployment

1. Recreate environment variables and secrets without committing sensitive values to the repository.
2. Confirm the build command, start command, runtime version, process manager, ports, and health checks.
3. Recreate cron expressions, workers, queues, storage mounts, and deployment hooks.
4. Run a production-like build and inspect logs for missing modules, permissions, or configuration errors.
5. Test the release and rollback process before changing DNS. Developer utilities such as a JSON formatter, regex tester, JWT decoder, or cron expression builder can support this verification work, but sensitive tokens should never be pasted into an untrusted tool.

What to double-check

DNS cutover plan

Lower the DNS TTL ahead of the migration if your DNS provider permits it, while recognizing that resolvers and cached records may not all change at the same moment. Do not rely on TTL reduction as an instant switch. Confirm the current DNS provider, authoritative nameservers, and every record that matters before editing anything.

For a domain-only change, keep nameservers and unrelated records unchanged where possible. For a nameserver migration, copy the complete DNS zone first and compare it record by record. If you are also transferring the domain, treat that as a separate project and review the domain transfer readiness checklist.

Rollback plan

Write the rollback steps before launching. A useful template is: identify the failure; stop writes or background jobs if data could diverge; restore the previous DNS values; confirm the old host is still intact; communicate the status; preserve logs; and investigate before trying again. Do not cancel the old hosting plan until the rollback window has passed and the new host has demonstrated stable operation.

Post-cutover verification

Check the site from more than one network or monitoring location. Confirm the expected IP address, HTTPS certificate, status codes, redirects, canonical URLs, robots directives, sitemap, forms, email delivery, logins, uploads, and scheduled tasks. Review application and server logs for errors that a basic page-load test will miss. An uptime monitoring and incident response workflow can provide an independent view after the change.

Common mistakes

• Changing DNS before testing: A copied site is not necessarily a working site. Test the destination privately first.
• Forgetting the final database sync: Orders, comments, form submissions, and account changes made after the first backup may be absent on the new host.
• Moving only visible files: Hidden configuration files, uploads, rewrite rules, and generated assets may be essential.
• Overlooking email: Website DNS and email DNS are often managed together. Record every mail-related entry before editing the zone.
• Ignoring version differences: A newer or older runtime can expose compatibility problems in plugins, extensions, libraries, or custom code.
• Running duplicate jobs: Keeping cron jobs or workers active on both hosts can send duplicate messages, process records twice, or create conflicting updates.
• Testing only the homepage: Important failures often appear in checkout, login, forms, redirects, media, search, or administration areas.
• Deleting the old host too early: Retain the old site and backups until traffic, data integrity, email, and monitoring have been confirmed.

Keep a timestamped migration log with DNS changes, backup locations, test results, errors, and decisions. It makes troubleshooting faster and creates a reusable record for the next move.

When to revisit

Revisit this checklist before every hosting migration, major seasonal planning cycle, infrastructure redesign, or change to the application runtime. Review it sooner when the site adds a store, new subdomains, transactional email, third-party integrations, background workers, or a different deployment method.

Hosting control panels, backup tools, migration assistants, supported runtime versions, and DNS interfaces can change. Before acting, confirm the current provider instructions for backups, restores, temporary URLs, SSL setup, and DNS editing. Also revisit the process after a failed migration or near miss: update the inventory, add the missed verification step, and test the rollback procedure while the current system is still healthy.

Action plan: choose a migration window; create and test a restorable backup; inventory DNS and application dependencies; build and privately test the new host; document the rollback; lower TTL where appropriate; perform the final sync; change DNS; monitor the site; and keep the old environment until verification is complete. For backup design, use the website backup strategy checklist. If HTTPS fails after the move, consult the SSL certificate troubleshooting guide before assuming the migration itself is the only cause.