How to Move a WordPress Website to Cloud Hosting Without Downtime

Overview

A WordPress cloud hosting migration usually has four separate parts: preparing the destination server, transferring the site, switching traffic, and confirming that the live site works as expected. Treating these as separate stages makes it easier to find problems and avoids making irreversible changes too early.

“Without downtime” does not mean that every migration is risk-free. It means the old site remains available while the new site is prepared, and that the DNS change is made only after the destination has passed testing. During the final cutover, recent orders, form submissions, comments, bookings, or user registrations may still be written to the old database. Sites with frequent database activity need a short content freeze, database synchronization step, or a migration method designed for ongoing changes.

Before choosing a cloud plan, record the current environment. Note the WordPress version, PHP version, database type and version, active plugins, theme, cron jobs, scheduled tasks, storage use, upload directories, caching layers, CDN settings, DNS records, and email services. Confirm that the target cloud host supports the software versions required by the site. Do not upgrade WordPress, PHP, the theme, and several plugins at the same time as the migration unless there is a tested reason to do so; too many simultaneous changes make troubleshooting harder.

For a broader comparison of infrastructure choices, see Cloud Hosting vs Shared Hosting vs VPS. If you are still evaluating the move, also review Cloud Hosting vs Shared Hosting.

Checklist by scenario

Scenario 1: Preparing the new cloud environment

• ☐ Create the destination server, application, or managed WordPress site.
• ☐ Configure the intended PHP, database, web server, storage, and caching settings.
• ☐ Create a temporary hostname or protected staging URL for testing.
• ☐ Restrict access with authentication, an IP allowlist, or another suitable control while the site is private.
• ☐ Confirm disk capacity and upload limits are sufficient for the existing site and expected growth.
• ☐ Prepare a separate database user with only the permissions the application requires.
• ☐ Confirm how SSL certificates, redirects, backups, logs, and scheduled tasks will be managed.

A staging environment is especially useful when the site has custom code, a large plugin set, ecommerce features, or integrations with external systems. The guide How to Set Up a Website Staging Environment Before Publishing Changes provides a separate workflow for creating and testing that environment.

Scenario 2: Backing up and copying WordPress

• ☐ Take a complete backup of the original files and database.
• ☐ Store at least one backup outside the current hosting account.
• ☐ Verify that the archive can be opened and that the database can be restored to a test location.
• ☐ Record the backup time and identify any content created after that point.
• ☐ Copy WordPress core files, themes, plugins, uploads, configuration files, and required custom directories.
• ☐ Import the database and confirm that table prefixes, character settings, and user records are intact.

You can use a migration plugin, a host-provided migration tool, or a manual file and database transfer. Plugin instructions differ by product and may change after platform updates, so follow the tool’s current documentation and test the result rather than assuming a completed transfer is a working transfer. For manual migrations, preserve the original database export and keep configuration values such as database name, user, password, host, and table prefix available for review.

Never treat the migration copy as the only backup. Use the separate Website Backup Strategy for Small Businesses checklist to plan retention and recovery testing.

Scenario 3: Testing before the DNS cutover

Use a temporary hostname, hosts-file override, or staging URL to test the destination without changing public DNS. Check both anonymous and authenticated areas of the site.

• ☐ Open the home page, key landing pages, navigation, search, and category or archive pages.
• ☐ Test contact forms, logins, password resets, comments, checkout, bookings, or other important workflows.
• ☐ Confirm images, downloads, embedded media, redirects, and canonical URLs.
• ☐ Review the browser console, application logs, PHP errors, and web server logs.
• ☐ Confirm scheduled tasks and background jobs run on the new host.
• ☐ Check caching behavior and purge any stale cache before final testing.

Be careful with search indexing while the copy is private. A temporary site should not become an unintended duplicate of the public site. Keep access restricted and review the site’s indexing controls before launch.

Scenario 4: Planning and executing the DNS cutover

Lower the DNS time-to-live, or TTL, before migration if the DNS provider allows it. This can help resolvers notice the new address sooner, but it does not force every resolver or browser to update immediately. Keep the old hosting account active until the new site is confirmed across the expected DNS transition period.

At cutover, take a final backup, perform any required final database synchronization, update the web and www records, and note the exact time. Avoid changing nameservers and individual records at the same time unless you have deliberately planned a registrar or DNS-provider move. Separating those changes makes failures easier to isolate.

Scenario 5: Enabling SSL and completing launch checks

• ☐ Issue or attach an SSL certificate for every required hostname.
• ☐ Confirm HTTPS loads without certificate warnings.
• ☐ Test HTTP-to-HTTPS redirects and the preferred www or non-www version.
• ☐ Look for mixed-content warnings caused by hard-coded HTTP resources.
• ☐ Recheck forms, payment or booking integrations, webhooks, and API callbacks.
• ☐ Confirm analytics, search tools, uptime monitoring, and CDN settings.

SSL configuration and renewal differ by host and control panel. Keep the SSL Certificate Renewal and Troubleshooting Checklist with the migration record so future certificate problems do not become an avoidable outage.

What to double-check

Most migration failures come from details that are outside the visible page content. Use this post-launch verification table after DNS begins resolving to the cloud host.

Preserve email records carefully. Moving website hosting does not automatically mean moving email hosting. MX, SPF, DKIM, DMARC, and verification records may belong to a separate provider. Removing them because they were not needed by the web server can interrupt mail delivery or domain-based authentication.

Common mistakes

• Skipping backup verification: A downloaded archive is not proof of recoverability. Open it and perform a test restore.
• Changing DNS too early: Cut over only after the destination has been tested and the rollback owner is known.
• Forgetting writable directories: WordPress may need to write to uploads, cache, or temporary locations. Check ownership and permissions without making broad, unsafe permission changes.
• Using the wrong site URL: Search-and-replace operations can damage serialized WordPress data if performed with unsuitable tools. Use a migration tool that understands WordPress data or follow a tested database procedure.
• Ignoring background work: Cron jobs, queues, webhooks, scheduled publishing, and external API callbacks may still point to the old environment.
• Deleting the old host immediately: Keep it available until DNS behavior, content, transactions, and backups have been checked.
• Combining migration with upgrades: First reproduce the existing site. Upgrade components afterward in a controlled staging workflow.

When to revisit

Revisit this checklist before every infrastructure change, domain or DNS-provider move, major WordPress upgrade, hosting-plan change, seasonal traffic period, or rollback exercise. It is also worth reviewing twice a year and whenever the hosting control panel, migration plugin, PHP support, SSL process, or DNS workflow changes.

After launch, keep a short migration record containing the backup location, DNS values, SSL method, database credentials owner, monitoring URL, rollback steps, and final verification time. Review it during routine maintenance and update it when responsibilities or tools change. The Monthly Maintenance Checklist for Cloud-Hosted Small Business Websites can help fold these checks into regular operations.

When the next migration is scheduled, start with a dry run on a staging copy, confirm that backups restore, lower DNS TTL where appropriate, and assign one person to approve the cutover and one person to validate the live site. That preparation turns a risky hosting change into a controlled cloud deployment with a clear path back if a problem appears.