xCloud WordPress Migration: My 2-Day VPS Move (and What I’d Do Differently)

I didn’t plan another server move this soon, but here we are. This post is my real-world xCloud WordPress migration story, including what went wrong on day one, what fixed it on day two, and how I ended up with a setup that’s now genuinely fast.

In April 2025, I moved from shared hosting to a VPS and documented the journey using a different panel. Since then, my requirements changed. I wanted tighter WordPress integration for server-side caching, plus an easier path to Cloudflare edge caching. That’s what pushed me to try xCloud.

At the same time, I also moved my VPS location:

• Old VPS provider: HostHatch (New York)
• New VPS provider: RackNerd (Dallas)
• Panel: xCloud (panel only, not managed hosting)
• DNS and CDN: Cloudflare
• Migration tool: Duplicator Pro

Why I moved again: caching and Cloudflare integration

The short version: I wanted server-side caching that does not depend on a WordPress caching plugin.

xCloud made that part simpler for me:

• Enabling Nginx page caching was easy, and Nginx Helper was automatically installed for purging.
• Redis object caching was straightforward once I had the correct credentials.
• xCloud also offered a Cloudflare edge-caching integration via a plugin.

For front-end tweaks, I still use Perfmatters for things like CSS and JS minification and performance toggles. But I don’t use a WordPress caching plugin. My preference is to keep caching at the server level and at Cloudflare’s edge, and keep WordPress itself lean.

Day 1: the demo domain workflow and the “push to live” surprise

xCloud offers a convenient-looking workflow:

• Install WordPress on a demo domain
• Migrate your site
• Push it to your real domain later

On paper, it sounds perfect. In practice, it can turn into a trap if you assume “push to live” updates everything.

What I did

• xCloud installed WordPress on a demo domain.
• I restored my full site backup to that demo domain with Duplicator Pro.
• I used xCloud’s “push” feature to switch the site to my live domain.
• I switched DNS to point the live domain to the new server.

What went wrong

Right after cutover, my live domain redirected back to the demo domain.

At first, I blamed Nginx, but it was not an Nginx redirect. WordPress was doing it because the database still had the demo domain saved as the site URL.

I fixed the redirect quickly in phpMyAdmin by updating home and siteurl in the wp_options table. That got me back into the site.

Then I noticed the bigger issue: internal links and assets still pointed to the demo domain. Some URLs were in post content, others in plugin settings, and some were probably buried in builder data.

Since DNS had already been switched, I didn’t want a half-broken site for hours while waiting for support. So I rolled DNS back to my old server and paused the migration.

Lesson from day 1

A “push to live domain” feature does not guarantee every URL in your database is updated. If your site is more than a simple blog, you need to plan for cleanup.

Day 2: the safer xCloud WordPress migration method

On day two, I did the same migration, but changed one key thing: I staged using my real domain from the start.

Step 1: install WordPress on the live domain (HTTP only)

I created a new WordPress install in xCloud using my real domain on plain HTTP, no SSL yet.

Then I added a hosts file entry on my computer to point the domain to the new server’s IP address. This let me access and test the new server using the correct domain, while everyone else still hit the old server.

This single change removed most of the “sticky URL” risk.

Step 2: restore with Duplicator Pro again

With the environment set to the correct domain, I restored my latest Duplicator Pro backup.

Now the site was already on the correct domain during restore, which made the migration much cleaner.

Step 3: switch DNS and enable Let’s Encrypt

Once everything looked good, I switched DNS to the new server.

After configuring DNS to point to the xCloud server, I let xCloud issue a Let’s Encrypt certificate. That worked as expected.

xCloud also automatically updated WordPress to HTTPS. Browsing the site looked fine, and at this point, many people would stop.

I didn’t.

featured blog

My Website was build with Elementor Pro

A comparison between Free and Pro

Click here

The step that caught hidden HTTP links: WP-CLI search replace

Even when a site looks fine, it can still contain old HTTP links inside plugin tables. That can lead to mixed content warnings, subtle redirects, or broken resources later.

So I SSH’d into the VPS and ran WP-CLI search-replace:

• I did a dry run first
• Then I ran the live replacement

The dry run found many HTTP references that weren’t obvious from browsing the site. After the live run, my database was clean and consistent.

# Run this from anywhere, it uses --path to target the right WordPress install
# 1) Optional safety net: export the database first
sudo -u u4_edywerder -i -- wp --path=/var/www/edywerder.ch db export before-search-replace.sql
# 2) Dry run: shows how many replacements would happen (no changes made)
sudo -u u4_edywerder -i -- wp --path=/var/www/edywerder.ch \
  search-replace 'https://edywerder.ch' 'https://edywerder.ch' --all-tables --precise --dry-run
# 3) Live run: actually replaces the URLs
sudo -u u4_edywerder -i -- wp --path=/var/www/edywerder.ch \
  search-replace 'https://edywerder.ch' 'https://edywerder.ch' --all-tables --precise

# Run this from anywhere, it uses --path to target the right WordPress install
# 1) Optional safety net: export the database first
sudo -u u4_edywerder -i -- wp --path=/var/www/edywerder.ch db export before-search-replace.sql

# 2) Dry run: shows how many replacements would happen (no changes made)
sudo -u u4_edywerder -i -- wp --path=/var/www/edywerder.ch \
  search-replace 'https://edywerder.ch' 'https://edywerder.ch' --all-tables --precise --dry-run

# 3) Live run: actually replaces the URLs
sudo -u u4_edywerder -i -- wp --path=/var/www/edywerder.ch \
  search-replace 'https://edywerder.ch' 'https://edywerder.ch' --all-tables --precise

Replace u4_edywerder with your site user
Replace /var/www/edywerder.ch with your WordPress path

You can also use the command with a demo (temporary) domain.

This was the moment the migration finally felt “done”.

Final performance stack: Redis, Nginx cache, Cloudflare edge caching

Once the site was stable, I moved to performance.

Redis object cache

Redis was running on the server, PHP had the Redis extension, and xCloud provided credentials. The only tricky part was getting authentication right. If you run into the Redis Object Cache error with Cloudflare proxy enabled, this guide shows the fix I use.

Nginx page cache with purge support

Enabling Nginx page cache was easy, and xCloud installed the Nginx Helper plugin for cache purge events. That matters because caching is only useful if updates invalidate correctly.

Cloudflare edge caching

Finally, I enabled Cloudflare edge caching. Combined with Nginx page cache and Redis object cache, the site became noticeably faster.

For front-end cleanu,p I still rely on Perfmatters for minifying CSS and JS and disabling a few things I don’t need. But the heavy lifting is server-side caching plus Cloudflare at the edge.

Result: my site is now blazing fast, but it was a real project.

My practical takeaways

If you’re planning an xCloud WordPress migration, here is the process I recommend:

1. Avoid demo-domain “push to live” for full migrations
   It can work, but you should assume URLs can remain stuck in the database.
2. Stage with the hosts file using the real domain
   You can test the new server without touching DNS and without introducing a second domain into the database.
3. Do SSL after DNS cutover
   Let’s Encrypt is simplest once the domain resolves publicly to the new server.
4. Use WP-CLI search replace even if the site looks fine
   It finds leftover HTTP links in places you won’t notice manually.
5. Add caching layers last
   First, make it correct. Then make it fast.

I’d love to hear from you. Was this article helpful? Share your thoughts in the comments below. If you prefer, you can also reach me by email or connect with me on Reddit at Navigatetech.