Skip to content

Migrate WordPress to Cloudways

Two honest paths for moving a WordPress site to Cloudways: let their engineers migrate your first site free, or run it yourself with backup, copy, DNS cutover and a week-long rollback window. Plus what to verify before you call the move done.

What you will build: an existing WordPress site moved from its current host to Cloudways with content intact, a DNS cutover measured in minutes, and the old host kept for a week as the rollback.

A removal van crossing a bridge between two houses with boxes stacked, one carried box in vermilion.

What you will build

What you will build: an existing WordPress site moved from its current host to Cloudways with content intact, a DNS cutover measured in minutes, and the old host kept for a week as the rollback.

By Sam Moreton

First-hand testing

What you will build

A WordPress site that already has content, history and an audience, moved to Cloudways with nothing lost, a cutover measured in minutes, and a rollback that stays available for a week afterwards. Fresh installs are covered in how to deploy WordPress on Cloudways; this page is for sites that cannot start again.

Path one: their engineers do the first one free

The first website migration into your account is done for you, free, by Cloudways support engineers, from whatever host the site currently sits on. You provide access to the current host, they move the files and the database, and they tell you when the copy is ready. For additional WordPress sites beyond the first there is migration tooling you run yourself, and a managed migration add-on exists for awkward cases where you want experienced hands again.

Use this path if the thought of exporting a database makes you sweat, or if your afternoon is worth more than the time the move takes. It is the fastest route and it is included. One part stays yours regardless of who does the moving: verification. Somebody must click through the migrated site before DNS switches, and if the engineers moved it, that somebody is still you. The checklist below tells you what to click.

Path two: do it yourself

The manual path, in the order I run it.

Inventory the source before anything moves. How big are the files and the database, which plugins are installed, what PHP version does the old host run, and does anything live outside the WordPress tree, cron jobs, mail forwarding, a forum in a subdirectory. This inventory decides everything downstream, including whether you want help after all.

Take a full backup at the old host and keep it somewhere you control. Whatever else happens this week, this backup is the floor under the whole operation.

Create the destination: a server and a fresh WordPress application on Cloudways. The deploy walkthrough covers that part.

Copy the site across by whichever of the two standard routes fits. A migration plugin pulls everything from the old host and suits most straightforward sites. The manual route, database export, file copy, import, then a URL search-and-replace for the paths, earns its keep on large media libraries and unusual setups.

Preview before anyone else does. Reach the new site while DNS still points at the old one, using the application's temporary URL or a hosts-file entry on your own machine, and click through it like a visitor. This is the step that catches broken imports, and it happens while the old site is still serving everyone.

Lower the DNS TTL a day before the cutover, so the switch propagates in minutes instead of whenever the record's old lifetime expires.

Cut over. Freeze edits at the old site, sync anything that changed since the copy, recent orders, comments, new uploads, then switch the DNS record. Watch propagation from a few vantage points instead of assuming it.

What to verify before you call it done

Pages render, including interior pages, and permalinks do not 404. The media library opens and recent uploads display. Forms submit and their mail arrives. The admin logs in and works. If the site sells anything, walk the checkout end to end and confirm the order lands. Mail the site sends, password resets, contact notifications, receipts, gets delivered. Check the certificate after DNS settles, and check Search Console for crawl errors once the new site has been live for a day.

Keep the old host for a week

This is the part people skip to save one month of old hosting, and it is the cheapest insurance in the whole operation. The old site stays untouched, which keeps the DNS switch reversible for as long as the overlap lasts. Something usually surfaces late: a form that emailed a list nobody monitored, an importer that missed a directory, a plugin that stored absolute paths. A week of overlap turns each discovery from an emergency into a sync.

When the week is up, take one final export of the old site and archive it somewhere you control, then cancel. Old hosts do not keep your data out of politeness.

Which path

First site, standard WordPress, no oddities: let the engineers do it, then verify like it was your own work, because after the move it is your site again. Many sites, an unusual stack, or a cutover window you control to the minute: run it yourself with the sequence above, or pay for the managed migration add-on and lean on them for the awkward parts. The full picture of how these servers get structured once several sites are across is in how we host multiple production sites.

Start on Cloudways (opens in new tab)

Affiliate link