Migrating WordPress to a Cloud Server

What a WordPress move involves

A WordPress site is four things: a directory of files, a database, a DNS configuration and a set of assumptions baked into the database about where it lives. Move the first three and forget the fourth, and you get a site that half works in ways that are maddening to debug.

The technical work is not difficult. What makes these migrations go wrong is skipping the inventory, changing DNS too early, or discovering after cutover that the new PHP version disagrees with a plugin last updated years ago.

This walkthrough assumes a self-managed cloud server running Nginx, PHP-FPM and MariaDB, which is the most common destination and the one that gives the most control.

Take stock before you touch anything

Record the details that determine whether the new environment will actually run the site.

• PHP version and enabled extensions on the current host, plus the WordPress and database versions.
• Full plugin and theme list with versions, flagging anything commercial with a licence tied to a domain or a server.
• Total size of the uploads directory, which is usually the bulk of the transfer.
• Database size, and whether tables are InnoDB or the older MyISAM engine.
• Anything configured outside WordPress: server-level redirects, caching rules, hotlink protection, IP blocks.
• Scheduled tasks, including whether WordPress cron runs on page loads or from a system scheduler.
• Email: which plugin sends transactional mail, and through which service.

Take a full backup before starting, and verify it restores somewhere else. A backup you have not tested is a file, not a safety net.

Build the destination stack

Provision the instance, harden it, then install the stack. Nginx with PHP-FPM is the common pairing, and it wants a server block configured for WordPress permalinks, sensible upload size limits and a PHP-FPM pool sized to the instance's memory rather than left at defaults.

Match the PHP major version to what the site runs today. Upgrading PHP and changing servers in the same step doubles the number of possible causes when something misbehaves. Move first, upgrade PHP afterwards, and test the upgrade separately.

Install MariaDB or MySQL, create the database and a dedicated user with access only to that database, and set the character set and collation to match the source exactly. A mismatch here is how accented characters turn into question marks.

The reverse proxy configuration deserves care, particularly around caching headers and the handling of the admin area. Our guide to Nginx as a reverse proxy on a cloud server covers the patterns, and the underlying server setup follows the shared hosting migration path if you are coming from a control panel.

Moving files and the database

Copy files with rsync over SSH, preserving permissions and timestamps. Run it once well ahead of the cutover for the bulk of the data, then again on the day for the delta, which will be small because uploads change slowly.

Export the database with a tool that handles large tables gracefully. A plain dump is fine for most sites, and WP-CLI provides a convenient wrapper. Import it on the new server, then confirm the table count and a few row counts against the source.

Set file ownership to the web server user and apply conservative permissions: directories readable and traversable, files not writable by the web server except where WordPress genuinely needs it, such as the uploads directory.

Keep wp-config.php as a fresh file on the new server rather than copying the old one wholesale. Carry across the database credentials, the table prefix and the security salts, and leave behind host-specific constants that no longer apply.

The serialized data problem

WordPress stores absolute URLs throughout the database, including inside PHP serialized arrays used by plugins and page builders. A naive find and replace in a SQL dump corrupts those structures, because the serialized format records the length of every string.

Use a tool that understands serialization. WP-CLI's search and replace command walks the data structures properly and can be run in dry-run mode first to show what would change.

If you are keeping the same domain, which is the usual case, you may need no replacement at all. If you are testing on a temporary hostname first, remember to replace back before going live, or set the site and home URLs in wp-config.php for the duration of the test instead.

Cutover and certificates

Lower the DNS time-to-live for the relevant records a few days in advance so the change propagates quickly. Then, on the day, put the site into maintenance mode, run the final rsync and database export, import, and switch the A record.

Handle certificates in advance where possible. Let's Encrypt supports a DNS-based challenge that issues a certificate for a domain still pointing elsewhere, so the new server can serve HTTPS from the first request. If you use the HTTP challenge instead, issue the certificate immediately after the DNS change and before announcing the move.

Expect a tail of traffic at the old server while caches expire. Leaving the old site in read-only maintenance mode rather than deleting it means late visitors see a holding page instead of an error, and the record behaviour is explained in DNS setup for cloud servers.

The checklist after the switch

Work through the specific things that break on WordPress migrations, in this order.

1. Resave permalinks from the settings screen, which regenerates rewrite rules on the new server.
2. Confirm media files load, including older uploads in year and month folders.
3. Disable WordPress internal cron and run it from the system scheduler instead, so scheduled posts and plugin jobs fire reliably.
4. Send a test transactional email and confirm it arrives, since mail configuration is host-specific and rarely carries over.
5. Check the contact forms, the search function and any plugin that talks to an external service with an address allowlist.
6. Configure automated backups of files and database to storage outside the server, following cloud backup strategies.
7. Enable automatic security updates for the operating system, and set a reminder to review plugin updates.

Only after all of that should you plan the PHP upgrade you deferred earlier, on staging first.

Key takeaways

• Inventory PHP version, extensions, plugins and server-level rules before provisioning anything.
• Match the runtime version on the new server; upgrade PHP as a separate, later exercise.
• Match database character set and collation exactly, and build a fresh configuration file rather than copying the old one.
• Replace URLs with a tool that understands PHP serialization, never with a plain find and replace.
• Test through a hosts file entry, issue certificates ahead of time, and lower DNS time-to-live days in advance.
• After cutover, resave permalinks, move cron to the system scheduler, verify mail, and set up off-server backups.

For destination options, developer clouds suit WordPress hosting well and the two most common are compared in Hetzner versus Vultr, with details in the Vultr account listings. The tooling references are the Nginx beginners guide and the Let's Encrypt challenge type documentation.