How to Migrate a Website to a New Host Without Downtime

Overview

If you want website migration without downtime, the main goal is simple: make the new host ready before the domain starts sending visitors there. That means no “move now, fix later” mindset. Instead, you prepare both environments in parallel and cut over only after validation.

A no-downtime migration usually depends on five ideas:

• Inventory first: know exactly what you are moving, including files, databases, cron jobs, SSL, email routing, redirects, and third-party integrations.
• Back up everything: keep a restorable copy of both site files and databases before any changes.
• Test before DNS changes: preview the migrated site on the new host without pointing the public domain yet.
• Reduce DNS TTL in advance: lower the time-to-live value early so the cutover happens faster when you update records.
• Run old and new hosts in parallel briefly: do not cancel the old hosting account until you confirm stable traffic, working forms, and no missing content.

This process applies whether you are switching from shared hosting to cloud hosting, moving from one managed wordpress hosting platform to another, or consolidating several small business sites into a faster web hosting environment. If you are still evaluating providers, it helps to compare performance and deployment workflows before you migrate. See How to Benchmark Web Hosting Speed Before You Switch and Cloud Hosting vs VPS Hosting: Performance, Cost, and Control.

Before you begin, define the scope of the move:

• Is this a full hosting migration, including web files, database, DNS, and email?
• Are you moving only the website while keeping domain hosting and DNS elsewhere?
• Are you changing IP addresses, server stack, PHP version, database version, or caching layer?
• Do you have dynamic content such as orders, comments, user accounts, or form submissions that can change during the cutover window?

The more dynamic the site, the more carefully you need to schedule the final sync.

Checklist by scenario

Use the scenario that best matches your site. In all cases, the principle is the same: prepare, test, sync, switch, verify.

Universal pre-migration checklist

• List all domains and subdomains involved.
• Export current DNS records: A, AAAA, CNAME, MX, TXT, SPF, DKIM, and any verification records.
• Document the current application stack: runtime version, database version, web server, cache, scheduled jobs, SSL setup.
• Create full backups of site files and databases.
• Confirm you can restore from those backups.
• Lower DNS TTL for the records you will change, ideally well before migration day.
• Set up the destination hosting account, server, or container.
• Install required runtime versions, extensions, and system packages.
• Provision SSL if your host supports free ssl hosting or automatic certificate issuance after cutover.
• Set up logs, error reporting, backups, and basic website uptime monitoring.

Scenario 1: WordPress site migration

If you are planning how to migrate web hosting for WordPress, the common failure points are plugin conflicts, wrong file permissions, hard-coded URLs, and missed background jobs.

• Copy wp-content, core files if needed, and the database.
• Check wp-config.php for database credentials, salts, table prefix, and custom settings.
• Match PHP and MariaDB/MySQL compatibility as closely as practical.
• Recreate cron behavior. If the old host used server cron instead of WP-Cron, replicate it.
• Test plugins that interact with payments, memberships, forms, SMTP, caching, and image optimization.
• Review permalink structure and confirm redirects still work.
• Search for hard-coded domain references in the database or theme settings.
• Flush application and server caches after import.

If the destination is specialized wordpress hosting, compare staging, SSH, Git, and CLI access before switching. Useful references: Best Web Hosting for Developers: SSH, Git, Staging, and CLI Access and WordPress Hosting Requirements Checklist for 2026.

Scenario 2: WooCommerce or other dynamic ecommerce site

This is the highest-risk scenario because orders and customer actions may happen at any time.

• Schedule the cutover during a lower-traffic period if possible.
• Reduce the time between final database sync and DNS cutover.
• Temporarily pause major catalog edits during the migration window.
• Put the site in a controlled maintenance or checkout-restricted mode only if absolutely necessary for final sync integrity.
• Verify payment gateway webhooks, transactional email, taxes, shipping plugins, and order status automation.
• Confirm file uploads, product images, and cache exclusions are preserved.
• Test checkout end to end on the new host before cutover.

For store-specific hosting considerations, see Best Hosting for WooCommerce Stores: What to Look For.

Scenario 3: Static site or simple brochure site

If you are trying to move website to new host for a static project, the process is simpler because there is usually no live database.

• Upload the site to the new host or redeploy from version control.
• Confirm asset paths, redirects, and custom error pages.
• Test forms or contact handlers if they rely on external services.
• Validate SSL, compression, caching headers, and canonical URLs.
• Switch DNS after confirming the new deployment is identical.

If you are moving to a platform with one click deployment or Git-based workflows, compare how it handles previews and rollbacks. See One-Click Deployment Platforms Compared for Simple Web Projects.

Scenario 4: Custom app or developer-managed stack

For applications with background workers, environment variables, queues, or containerized services, your hosting migration checklist should include operational dependencies, not just the web root.

• Export and securely re-import environment variables and secrets.
• Recreate worker processes, process managers, queue consumers, and scheduled jobs.
• Check writable directories, storage mounts, and object storage credentials.
• Confirm firewall rules, allowed IPs, and database access controls.
• Test API callbacks, OAuth redirect URIs, and webhook endpoints.
• Review any dependency on local disk versus persistent volumes.
• Prepare a rollback path that can restore traffic to the old host quickly.

DNS cutover checklist

DNS is often where migrations feel uncertain, so it helps to treat cutover as its own task list.

1. Lower TTL on the current DNS records before migration day.
2. Confirm the new host is fully tested on a temporary URL, preview domain, or local hosts-file mapping.
3. Provision SSL on the new host or ensure it can issue the certificate immediately after records change.
4. Update only the records required for the website cutover, usually A or CNAME records.
5. Do not accidentally overwrite MX, SPF, DKIM, or verification records if email is staying elsewhere.
6. Monitor logs, uptime, and real user activity as DNS propagates.
7. Keep the old server online during propagation and for a safety period afterward.

If you also need to connect domain to hosting for the first time, or untangle domain and DNS management from the web host, keep your registrar, DNS provider, and hosting roles clearly separated in your notes. That reduces accidental record loss during the switch.

What to double-check

This is the section to revisit right before launch. Most migration problems are not dramatic server failures; they are small omissions that are easy to miss in a rushed cutover.

Application checks

• URLs and redirects: confirm www and non-www behavior, HTTP to HTTPS redirects, and any old URL rewrite rules.
• Database connection: test both read and write operations.
• File permissions: uploads, cache directories, generated files, and backup folders should behave normally.
• Background tasks: cron jobs, queue workers, scheduled publishing, cleanup tasks, and imports should all run.
• Search and forms: onsite search, contact forms, newsletter signups, and captcha integrations need a live test.

Infrastructure checks

• SSL: the certificate should cover every production hostname you use.
• Caching: verify full-page cache, object cache, CDN settings, and cache exclusions for logged-in or cart pages.
• Compression and performance: confirm static assets load correctly and response times are reasonable.
• Error logging: enable access to server and application logs during launch.
• Backups: verify scheduled backups on the new host are active.

DNS and email checks

• Website records only: make sure changing the web record does not break email or other services.
• Subdomains: check blog, shop, api, staging, or support subdomains individually.
• Email deliverability: if email is hosted separately, preserve MX and sender authentication records.
• TTL reset: after the migration stabilizes, raise TTL again to a sensible long-term value.

Business checks

• Test your most important conversion path: lead form, booking flow, signup, or checkout.
• Confirm analytics, tag management, and conversion tracking still fire correctly.
• Check robots rules and indexing settings so the production site is crawlable and the staging site is not.
• Make sure the old host is not still serving mixed or stale content through a forgotten subdomain.

Common mistakes

If you want to avoid downtime prevention problems, these are the patterns to watch for.

• Cutting DNS before testing the new host. This is the fastest way to turn a manageable migration into a live incident.
• Canceling the old host too early. Keep it active until you have confirmed stable traffic, correct forms, and no missing media or database writes.
• Ignoring TTL timing. Lowering TTL after the change does not help the current cutover much. Plan ahead.
• Forgetting email records. Many site owners change nameservers or zone files and accidentally break email even though the website comes up fine.
• Skipping the final sync on dynamic sites. User data can diverge between old and new environments if you copy too early and switch too late.
• Changing too many variables at once. A host move is already a major change. Avoid redesigns, plugin replacements, or major version upgrades in the same window unless necessary.
• Not documenting rollback. Every migration plan should answer one question clearly: if validation fails after cutover, how do we restore service fast?
• Leaving staging open to search engines. Preview environments should be blocked from indexing and protected from public confusion.

If your real problem is not only migration but also provider fit, it may be worth reviewing hosting model differences before you move again. See Shared Hosting vs Cloud Hosting: Which Should You Choose? and How to Choose Hosting for High-Traffic WordPress Sites.

When to revisit

This checklist is worth revisiting any time the inputs change, not only on migration day. A site move that was safe last year can become risky if the stack, traffic pattern, or business workflow has changed.

Review and update your migration plan when:

• You are entering a seasonal sales or campaign period and cannot tolerate service interruptions.
• You add ecommerce, memberships, bookings, or other dynamic user data.
• You change DNS providers, registrars, or email routing.
• You move from shared hosting to cloud hosting or from a basic plan to a more developer-oriented environment.
• You introduce a CDN, reverse proxy, staging workflow, or automated deployment pipeline.
• Your team changes tools, such as switching backup plugins, deployment methods, or monitoring services.

A practical maintenance routine looks like this:

1. Quarterly: export and review your DNS zone, backup process, and uptime alerts.
2. Before seasonal planning cycles: confirm rollback steps, contact access, and test credentials are still current.
3. When workflows or tools change: re-check how SSL, previews, deployments, and cron jobs are handled on the target platform.
4. Before any new migration: turn this article into a runbook with owners, timestamps, and explicit validation steps.

For small business teams, the best website hosting for small business is not just the host with the lowest entry cost. It is the one that makes cutovers, backups, SSL, and recovery predictable. For technical teams, the best setup is one with enough access to test properly, inspect logs, and roll back cleanly.

Use this final action list before your next move:

• Create a written inventory.
• Take verified backups.
• Lower TTL early.
• Build and test the new host first.
• Perform a final sync for dynamic data.
• Switch only the required DNS records.
• Monitor closely after cutover.
• Keep the old environment live until everything is proven.

That is the core of how to launch a website move safely: prepare more than you think you need to, cut over only when the new host is ready, and give yourself a clean fallback if anything looks wrong.