The Complete WordPress & Site Migration Checklist: Move to Cloud Hosting with Minimal Downtime

Overview

A successful migration is a controlled change, not simply a file upload. The work has four goals: preserve the site’s data, reproduce its runtime environment, switch traffic safely, and prove that the new installation works before the old one is retired.

For WordPress, that usually means moving the application files and database, then checking themes, plugins, media, scheduled tasks, and administrative access. For a static or PHP site, the equivalent work includes copying files, recreating environment variables, configuring the runtime, and confirming database or external-service connections.

Use this order:

1. Inventory the current site and record a baseline.
2. Prepare the destination and confirm compatibility.
3. Create and test a complete backup.
4. Copy the site to the new host without changing the live DNS yet.
5. Test the copied site privately or through a temporary URL.
6. Reduce DNS TTL where appropriate and schedule the cutover.
7. Switch traffic, monitor results, and keep the old host available for rollback.

Before starting, identify who can access the hosting account, domain registrar, DNS provider, database, CDN, email settings, and deployment tools. If you cannot reach one of these systems, the migration plan is incomplete.

For backup details, use the WordPress Backup and Restore Checklist. It is also useful to record current response times, error rates, storage usage, PHP or application versions, and scheduled jobs. Those records give you a practical comparison after the move.

Checklist by scenario

Scenario 1: WordPress migration

• Inventory the installation: Record the WordPress version, active theme, plugins, media locations, custom code, redirects, forms, integrations, and administrator accounts.
• Check compatibility: Compare the source and destination PHP, database, web server, and caching configuration. Confirm that plugins and the theme support the destination environment before making the site live.
• Back up files and database: Keep at least one copy outside the current host. Include uploads, configuration files, custom themes or plugins, and the database. Do not assume that a hosting snapshot alone is a tested backup.
• Prepare the destination: Create the site, database, user credentials, runtime settings, file permissions, SSL configuration, and any staging or temporary hostname provided by the host.
• Copy the site: Transfer files and import the database. Update only the destination configuration needed to connect to the new database. Avoid changing URLs globally until you understand how the destination will be tested.
• Test privately: Check the homepage, representative posts, pages, images, search, login, admin screens, forms, checkout or other critical transactions, redirects, and robots.txt. Confirm that links do not point unexpectedly to a temporary hostname.
• Review scheduled tasks: WordPress cron events, server cron jobs, backups, email delivery, feeds, webhooks, and third-party API callbacks may need to be recreated or reauthorized.

Scenario 2: Static website

• Export the complete production build, including assets, fonts, downloadable files, redirects, and custom error pages.
• Recreate the build or deployment process on the new platform, including environment variables and repository access.
• Compare the generated output with the live site. Test asset paths, canonical URLs, forms, analytics, search engine directives, and redirects.
• Confirm that the destination serves the expected domain over HTTPS before switching DNS.

Scenario 3: PHP or database-backed site

• Document the application version, PHP extensions, database engine and credentials, writable directories, environment variables, and external services.
• Put the application into a maintenance or write-control mode during the final database export if users can create or change data.
• Import the database and test migrations, file uploads, sessions, email, queues, and background jobs.
• Confirm that permissions are narrow and intentional. Writable directories should not expose configuration files or private uploads.

Scenario 4: Low-downtime cutover

Several hours or a day before the planned switch, lower the DNS TTL if your DNS provider allows it and if doing so fits your operational plan. This may help resolvers refresh sooner, but it cannot force every cached response to expire at the same time.

Schedule a short change window. Freeze content publishing or application writes, take a final backup, synchronize changes made since the first copy, and then update the relevant DNS records. Keep the old host intact while you verify the new one. Do not cancel the old service immediately after seeing one successful page load.

What to double-check

DNS and domain settings

List every record that matters before changing anything: A, AAAA, CNAME, www, root domain, verification records, mail records, subdomains, and service-specific records. A web migration should not accidentally remove email or another active service. Use the domain and DNS connection guide when reviewing the cutover.

SSL and redirects

Confirm that the certificate covers every required hostname and that HTTP redirects to HTTPS as intended. Test the canonical host, www and non-www variants, important redirects, images, scripts, stylesheets, and embedded resources. Mixed-content warnings can make a site appear broken even when the page itself loads. See the SSL troubleshooting guide for a focused review.

Content, data, and SEO

• Open representative pages from every important content type.
• Search for broken internal links, missing images, incorrect file paths, and unexpected temporary URLs.
• Verify title tags, canonicals, XML sitemaps, robots.txt, structured data, and redirect rules.
• Submit test forms and confirm delivery, storage, and notifications.
• Check that user accounts, comments, orders, subscriptions, or other records are present where applicable.

For a complete performance comparison, review the website hosting performance audit checklist. Compare like for like: the same page, cache state, location, and test method.

Monitoring and rollback

Watch uptime, application errors, server logs, resource usage, certificate status, and form or transaction failures after the switch. An uptime monitor can reveal problems that a manual browser test misses; the uptime monitoring guide covers alert setup and response planning.

Define rollback before cutover. If the new site shows data loss, repeated errors, failed transactions, or a serious configuration problem, restore the previous DNS records, stop writes if necessary, preserve logs, and determine whether the old site contains newer data. Do not blindly restore an old database over records created during the migration window.

Common mistakes

• Changing DNS before testing: The destination should be verified privately before it receives production traffic.
• Forgetting hidden dependencies: Cron jobs, webhooks, email authentication, payment callbacks, CDN rules, and third-party API allowlists often sit outside the main site files.
• Copying files without the database: A WordPress media folder is not a complete WordPress backup, and a database without uploads is incomplete in the other direction.
• Using an untested backup: A backup is only useful if you can restore it and confirm that the restored site works.
• Replacing URLs carelessly: Broad search-and-replace operations can alter serialized data or unrelated text. Make a database backup first and use a method appropriate for the application.
• Closing the old host too soon: Retain the old environment until DNS behavior, traffic, forms, scheduled jobs, and error logs are stable through a reasonable observation period.
• Ignoring records created during cutover: New orders, registrations, comments, or uploads may exist on the old or new system. Reconcile them before finalizing the migration.

When to revisit

Run this checklist again before a major hosting-plan change, domain transfer, SSL renewal, WordPress core or plugin update, seasonal traffic period, or staging-to-production deployment. Revisit it whenever the hosting control panel, deployment workflow, DNS provider, PHP version, database engine, or application architecture changes.

At minimum, review the procedure quarterly and after a platform feature launch. Refresh screenshots, commands, runtime compatibility notes, and provider-specific DNS or SSL steps when those interfaces change. Keep the migration record with the backup location, DNS values, test results, cutover time, responsible owner, and rollback decision.

For the next migration, copy this final action list into your change ticket:

1. Confirm access and document the current environment.
2. Choose a maintenance window and define success and rollback criteria.
3. Create, download, and test the backup.
4. Build and privately test the destination.
5. Lower TTL if appropriate and record every DNS change.
6. Freeze writes, run the final sync, and switch traffic.
7. Test content, links, SSL, forms, jobs, email, redirects, and performance.
8. Enable monitoring and review logs.
9. Keep the old host available until the observation period is complete.

This process turns a rushed hosting move into a repeatable deployment workflow. The exact commands and control-panel labels may change, but the sequence—inventory, back up, test, switch, verify, and preserve rollback—remains a reliable foundation for moving sites to cloud hosting.