How to Migrate a WordPress Site to Cloud Hosting: A Step-by-Step Checklist

Overview

A WordPress cloud hosting migration usually involves moving three connected parts: the website files, the WordPress database, and the domain’s traffic routing. The files include WordPress core files, themes, plugins, media uploads, and configuration files. The database contains posts, pages, settings, users, comments, orders, and other site data. DNS determines where visitors are sent, while SSL ensures that the destination serves the site securely over HTTPS.

The safest workflow separates preparation from the final DNS change. First, document the existing environment and create recoverable backups. Then prepare the new cloud server, copy the site, test it privately, and only afterward point the domain to the new host. Keep the old hosting account available until the new installation has passed functional checks and the expected DNS transition period has elapsed.

Cloud hosting can provide a useful foundation for sites that need more control over resources, deployment, backups, or scaling. However, the hosting label alone does not guarantee a faster or more reliable WordPress site. Review storage, database support, PHP configuration, backup options, monitoring, SSL handling, and support responsibilities before you begin. For context on hosting trade-offs, see Shared Hosting vs Managed WordPress Hosting and Best CMS Hosting Options.

Checklist by scenario

Before moving any WordPress site

• Record the current host, server details, WordPress version, PHP version, database type, active plugins, theme, cron jobs, email configuration, and DNS records.
• Confirm that the new cloud environment supports the site’s WordPress requirements and has enough storage for the current files, database, logs, and temporary backup files.
• Lower the DNS record’s time to live before the change if your DNS provider allows it. This may help resolvers update sooner, but it does not provide a guaranteed switchover time.
• Pause nonessential site changes during the migration window. For stores, memberships, forums, and other active sites, plan how you will capture transactions or new submissions created during the copy.
• Create at least one complete backup of the files and database. Store a copy outside the current server and verify that the archive can be opened and the database can be read.
• Note the current site’s key URLs, redirects, robots.txt behavior, XML sitemap, analytics configuration, forms, checkout flow, and integrations.

For a manual file and database transfer

• Provision the destination server, web server, database, PHP runtime, system user, document root, and firewall rules according to the host’s instructions.
• Copy the WordPress files, including wp-content and any customized configuration or server files. Avoid assuming that hidden files are unimportant; review files such as .htaccess where applicable.
• Export the database using a suitable tool, then create the destination database and user with the required permissions.
• Import the database and update the destination configuration with the correct database name, username, password, host, and table prefix.
• Check the site URL settings. If the domain name is staying the same, avoid unnecessary search-and-replace changes. If the domain or protocol is changing, use a method that handles serialized WordPress data correctly.
• Set file ownership and permissions according to the cloud provider’s documented setup. Do not make the entire site writable as a shortcut.

For a managed WordPress migration

• Confirm what the provider’s migration process includes: files, database, SSL, DNS assistance, staging, redirects, email records, and post-migration support may be handled separately.
• Ask whether the temporary destination URL is suitable for testing and whether it is protected from search indexing.
• Check whether caching, image optimization, security rules, object caching, or a content delivery network will be enabled automatically. Record the settings so you can compare behavior after launch.
• Keep your own backup even when the provider offers migration assistance. A provider backup and an independently stored recovery copy serve different purposes.

For an ecommerce or high-traffic site

• Schedule the final synchronization during a low-activity period and define a brief content or order freeze if necessary.
• Take a fresh database backup immediately before the final transfer.
• Test login, product search, cart, checkout, payment handoff, order notifications, tax or shipping logic, and administrator access on the new environment.
• Monitor both hosts during the DNS transition. Some visitors may continue reaching the old server while cached DNS information expires.

What to double-check

DNS: Identify the record that controls the website, usually the domain’s A or AAAA record, or a CNAME for a subdomain. Do not change mail-related records casually. MX, SPF, DKIM, and DMARC records may be needed for business email and are separate from web hosting. If you also need to connect a domain or set up email, document every existing record before editing DNS. The guide on subdomains and subdirectories can help when the migration includes a staging or application subdomain.

SSL and redirects: Install or activate the certificate on the new host before sending normal traffic there. Test both HTTP and HTTPS, confirm that HTTP redirects to the intended HTTPS URL, and check that images, scripts, stylesheets, fonts, forms, and embedded resources do not create mixed-content warnings. A practical reference is the SSL Certificate Setup Guide.

WordPress behavior: Browse representative pages, categories, search results, author pages, media files, and pagination. Test the WordPress dashboard, scheduled publishing, contact forms, password resets, comments, and any external API integrations. Re-save permalink settings only if needed, and check the resulting redirects rather than assuming they are correct.

Performance: Compare page response time, cache behavior, image loading, database-heavy pages, and mobile rendering with the old site. Confirm that the new cache is not serving stale administrator pages or private content. Review the website speed optimization checklist for cloud hosting after the site is stable, rather than changing many performance settings during the migration itself.

Search visibility: Make sure the production site is not blocked by a staging noindex setting, password protection, or an unintended robots.txt rule. Check canonical URLs, XML sitemaps, redirect destinations, and the preferred protocol. Keep URL paths unchanged unless there is a clear reason to change them; if paths do change, create and test permanent redirects.

Rollback: Write down the exact steps for pointing DNS back to the old host, restoring the previous configuration, and communicating the decision. A rollback plan is useful only if the old site and its data remain available and the person responsible has access to the DNS account.

Common mistakes

• Changing DNS before testing: A cloud server can appear healthy while a plugin, form, database query, or rewrite rule is broken. Test through a temporary hostname, hosts-file entry, staging domain, or provider preview method first.
• Using an incomplete backup: Exporting only the database or only wp-content may omit configuration, uploads, custom code, or server-specific files. Confirm what the recovery procedure requires.
• Overlooking email: Website migration does not automatically move mailboxes. Preserve MX and authentication records unless email is intentionally moving, and verify sending and receiving separately.
• Ignoring active data: A simple file copy can miss orders, comments, registrations, or form entries created afterward. Use a final database sync or a planned maintenance window for sites with ongoing activity.
• Forgetting scheduled tasks: Review WordPress cron behavior and any server-level scheduled jobs. Duplicate jobs on both hosts can send repeated emails or process the same task twice.
• Deleting the old host too soon: Keep the old environment intact until DNS behavior, SSL, site functions, backups, and monitoring have been checked from more than one network.
• Changing too much at once: Avoid combining a host migration with a theme redesign, major plugin changes, URL restructuring, and a new caching system. Smaller changes make faults easier to locate.

When to revisit

Use this checklist before each planned WordPress host change, especially before seasonal traffic periods, product launches, major campaigns, or organizational changes that affect DNS and account access. Revisit it when the hosting provider changes its migration tools, backup model, PHP support, SSL workflow, firewall defaults, or deployment process.

It is also worth reviewing the checklist when the site’s risk profile changes. A brochure site, an ecommerce store, and a membership platform do not need identical migration windows or rollback procedures. Reassess backup frequency, recovery objectives, monitoring, staging, and access controls as traffic and business importance grow. For broader infrastructure planning, compare your requirements with the guidance on choosing hosting for Core Web Vitals.

Before acting, turn this article into a migration worksheet: assign an owner to each task, record the current DNS values, save backup locations, define the test list, and write the rollback trigger. After launch, check the site at intervals rather than relying on one successful page load. When every critical function works on the new cloud host and the recovery copy is confirmed, document the final configuration and only then retire the old environment.