Book a demo
Book a demo
Login

How to Migrate a Full Server from GridPane to xCloud

Updated September 25, 2026 · 16 min read

If you would rather have it done for you, the xCloud team migrates sites for free: see free website migration. This guide shows you how to move the WordPress sites on an eligible GridPane-managed server to a fresh xCloud server. It is for server owners who control the source VPS and can grant xCloud root SSH access. xCloud’s full-server workflow discovers selected WordPress sites and copies their files and databases. It does not clone the operating system, DNS zones, mailboxes, custom server packages, or non-WordPress applications.

Choose the correct migration method

Use full-server migration only when the GridPane source meets every xCloud requirement below. Otherwise, migrate each WordPress site separately.

Source condition Recommended xCloud path
Ubuntu 20.04 or 24.04 LTS x64, NGINX or OpenLiteSpeed, root SSH on port 22 Full-server migration in this guide
Ubuntu 22.04 Site-level WordPress migration, because xCloud’s current full-server prerequisites do not list Ubuntu 22.04
Root SSH is unavailable, blocked, or moved away from port 22 Site-level WordPress migration
The server contains one WordPress site only Site-level migration is usually simpler
The workload includes a non-WordPress application Migrate that application separately with its supported Git or container workflow

GridPane currently recommends Ubuntu 24.04 for new NGINX and OpenLiteSpeed servers. GridPane also supports Ubuntu 22.04 for sites that still need PHP 7.4, but that source does not satisfy xCloud’s published full-server operating-system requirement. Do not upgrade a GridPane server in place to make it eligible. GridPane recommends provisioning a new server and migrating instead.

Prerequisites

  • The GridPane source runs Ubuntu 20.04 or 24.04 LTS x64.
  • The source web server is NGINX or OpenLiteSpeed.
  • You control the source VPS and can add a public SSH key for the root account.
  • Root SSH is reachable on port 22.
  • You can temporarily disable source-side security rules that would block xCloud’s connection.
  • You have a complete inventory of production sites, staging sites, domains, databases, cron jobs, email delivery, CDN settings, and custom server configuration.
  • You have a current provider snapshot or full-server backup, a local website backup, and a remote off-server backup.
  • You have tested that at least one recent backup can be restored.
  • You can provision a fresh xCloud destination server. The full-server workflow does not use a destination that already hosts sites.
  • The destination has at least 1 GB of free storage beyond the combined size of the selected sites.
  • You control the production DNS records and can schedule a short write freeze for stateful sites.
  • You have agreed on a rollback window and will keep the GridPane source available until it ends.

Before you migrate

Record what xCloud will not copy

A full-server migration copies the selected WordPress files and databases. Record anything that must be recreated or replaced on xCloud:

  • server-level cron jobs and background processes;
  • custom NGINX or OpenLiteSpeed configuration;
  • packages or services installed directly on the VPS;
  • GridPane-specific security, cache, SendGrid, and must-use plugin integrations;
  • DNS zones, CDN origin settings, firewall allowlists, and email or SPF configuration;
  • non-WordPress applications and data stored outside the selected sites.

GridPane’s own migration checklist says server-wide configuration, added software, and server-level cron jobs require manual recreation. Do not assume xCloud copies them because GridPane’s internal clone tool can copy some site-specific settings.

Avoid GridPane’s beta outward-migration command for this flow

GridPane documents gpmigrate-away for manual exports, but the command is marked beta, can modify GridPane-specific WordPress configuration, and still requires a separate database export.You do not need it for xCloud’s normal full-server workflow. Use it only as part of a separately tested manual migration plan.

Step 1: Confirm that the source is eligible

Check the actual GridPane server’s operating system, architecture, web server, SSH port, and root access. Compare them with the eligibility table above.

Expected result: You can confirm Ubuntu 20.04 or 24.04 LTS x64, NGINX or OpenLiteSpeed, and root SSH on port 22. If any item differs, stop and use site-level migration.

Step 2: Inventory every WordPress site and server dependency

Use the GridPane account’s site list to record every production and staging site you intend to move. For each site, record its primary domain, aliases, PHP requirements, database, scheduled tasks, email delivery, CDN, redirects, and any custom configuration. Also record server-level jobs and packages separately.

Expected result: Every intended site has an owner and a validation checklist, and every non-site dependency has a named recreation task.

Step 3: Create and verify source backups

Follow GridPane’s three-tier backup approach:

  1. Create a provider snapshot or full-server backup.
  2. Create a local website backup for each selected site.
  3. Create or confirm a remote off-server backup.

Verify that the backups completed and that the recovery instructions are available to the migration operator. A backup that has never been checked is not a reliable rollback point.

Expected result: Each selected site has a current, restorable copy outside the migration process, and the source VPS has a recoverable server-level checkpoint.

Step 4: Prepare the GridPane sites for a clean copy

After the backups are complete, schedule a short preparation window before each copy. Clear application caches, then:

  • turn off GridPane’s must-use security hardening and WP Fail2Ban controls;
  • disable Wordfence or other WordPress security plugins that could block the migration;
  • disable cache plugins and object caching;
  • disable GridPane’s SendGrid integration after you have a destination email plan;
  • remove GridPane’s NGINX Helper and Redis Object Cache plugins from the copy when they are present.

These are source-side changes, so time them carefully. For a rehearsal copy, re-enable any production control that the source still needs after copying finishes. For the final copy, keep the GridPane-specific controls disabled and replace them with the corresponding xCloud configuration before production traffic moves.

Expected result: xCloud can read a clean WordPress copy without a host-specific must-use plugin, security rule, cache layer, or email integration blocking or conflicting with the destination.

Step 5: Provision a fresh xCloud destination server

Create a new server in xCloud for the migration. Do not place production sites on it before starting the full-server flow. Open Server Overview → Disk Usage and confirm that free storage exceeds the selected sites’ combined size by at least 1 GB.

Expected result: The destination is empty, reachable in xCloud, and has enough free storage.

Step 6: Start the full-server migration in xCloud

Open the fresh destination server, then select New Site → Migrate Full Server. Enter the GridPane source server’s connection details:

  • source server address;
  • port 22;
  • SSH username root;
  • public-key authentication.

Copy the public key displayed by xCloud. In GridPane, add that public key to your account’s SSH keys and apply it to the source server. GridPane states that keys attached to a server are installed for root access, regardless of the organizational label used for the key.

Never paste or upload a private key to either platform.

Expected result: xCloud connects to the GridPane source and displays the WordPress sites it discovered.

Step 7: Reconcile the discovered site list

Compare xCloud’s discovered sites with your inventory. Select only the production and staging sites that belong in this migration.

If a site is missing, confirm that it is a WordPress installation on this source server and that root can read its files and database. Do not continue until every expected site is either selected or assigned to a separate site-level migration.

Expected result: The xCloud selection matches the approved migration inventory, with no unexplained omissions.

Step 8: Create Demo Sites for the first copy

Choose Demo Site for each selected site, then start the migration. A demo site gives you an xCloud-hosted test address without changing production DNS. Reserve Go Live for a migration that is already validated and ready for immediate DNS cutover.

Expected result: xCloud completes the initial copy and each selected WordPress site opens on an xCloud demo address.

Step 9: Validate every migrated site

Test each demo site as both a visitor and a WordPress administrator. Check:

  • pages, posts, menus, media, downloads, and redirects;
  • administrator login and role permissions;
  • forms, search, checkout, membership, and other write paths;
  • recent database records and uploaded files;
  • plugins, themes, PHP compatibility, and scheduled WordPress events;
  • transactional email and any external API or webhook integration;
  • caching, Redis or object caching, CDN behavior, and security controls;
  • any custom configuration that you recreated on xCloud.

Use a controlled hosts-file override if you must test the production hostname before DNS changes. Do not expose the demo site to production traffic.

Expected result: Every site’s checklist passes on xCloud, or the site remains on GridPane while you resolve the difference.

Step 10: Choose the final-copy path and freeze writes

Lower the relevant DNS time to live at least one existing TTL interval before cutover. Then choose one of these paths:

  • The source has not changed since the Demo Site copy: keep the validated xCloud copy and continue to step 11.
  • The source is stateful or has changed: provision another fresh xCloud destination server. Put the GridPane sites into maintenance or read-only mode, pause cron jobs, queues, and workers on both platforms, repeat steps 5 through 7, and choose Go Live for this new authoritative copy.

The second option is a new full copy to a fresh server, not an incremental merge. xCloud’s public full-server guide does not document incremental final synchronization, so do not rerun the workflow against an existing destination or assume newer records will merge safely. If a second fresh-server copy is not practical, request a supported final-copy plan from xCloud before the window.

Expected result: No conflicting writes can occur, and the final xCloud copy matches the frozen GridPane source.

Step 11: Map each production domain in xCloud

If you kept the validated Demo Site copy, open each site and select Domain → Go Live. In Domain Setup, enter the production domain, review the DNS Setup values, and save. Follow xCloud’s Go Live guide for the current screen sequence.

If you made a new authoritative full-server copy, use the production domain selected with Go Live during that migration. Confirm the domain appears on the final xCloud site before changing DNS.

Expected result: Every production hostname is assigned to the correct final xCloud site, and xCloud displays the DNS values required for cutover.

Step 12: Switch DNS and verify HTTPS

Update each production domain’s authoritative DNS records to the final xCloud destination. Follow xCloud’s DNS guide for the required records. Wait for the authoritative response to show the new destination, then confirm that xCloud issues a valid certificate. If it does not, use xCloud’s SSL troubleshooting guide.

Update CDN origin settings, firewall allowlists, webhook destinations, and any integration that depended on the old server address.

Expected result: Production DNS resolves to xCloud, HTTPS is valid for every hostname, and external integrations reach the new server.

Step 13: Create and confirm a destination backup

Create a backup of every final xCloud site before enabling production processing. Confirm that each backup job completed successfully, appears in xCloud, and has the expected site and timestamp. Keep the independently verified GridPane backups as the recovery source until the rollback window ends.

Expected result: Every final xCloud site has a completed destination restore point, and the verified source backups remain available.

Step 14: Enable xCloud processing and monitor the cutover

Enable destination cron jobs, queues, scheduled events, and background workers only after traffic reaches xCloud and final validation passes. Keep corresponding GridPane processing paused to prevent duplicate work.

Monitor application logs, error rates, form delivery, orders, email, scheduled tasks, and resource use throughout the rollback window. Keep the GridPane source and its backups unchanged.

Expected result: xCloud is the only environment accepting production writes and running asynchronous processing.

Verification

The migration is complete only when all of the following are true:

  • Every intended WordPress site exists on xCloud.
  • Production DNS resolves to xCloud from more than one public resolver or network.
  • HTTPS presents a valid certificate for every production hostname.
  • Visitor and WordPress administrator checks pass.
  • Recent database records and uploaded files match the final source state.
  • Forms, checkout, login, email, redirects, plugins, scheduled tasks, and external integrations work.
  • Required server-level jobs and custom configuration have been recreated.
  • GridPane no longer accepts writes or runs duplicate processing.
  • The destination backup completed successfully and appears with the expected site and timestamp.
  • The GridPane source and source backups remain available for the agreed rollback window.

Troubleshooting

Symptom Likely cause Fix
xCloud cannot connect to the GridPane source Root SSH is not reachable on port 22, the xCloud public key is missing, or a firewall blocks the connection Confirm port 22 and root access, add the exact public key shown by xCloud to the source server, and review provider or server firewall rules. Do not expose SSH more broadly than necessary.
Public-key authentication fails The key was added to the wrong GridPane server, was copied incompletely, or is not active Recopy the complete public key as one line, attach it to the correct source server, and retry. Never provide xCloud with a private key.
The GridPane server runs Ubuntu 22.04 The source does not meet xCloud’s published full-server OS requirement Use site-level WordPress migration. Do not upgrade the source operating system in place.
A WordPress site is missing from xCloud’s list The site is on another server, is not detectable as WordPress, or root cannot read its files or database Reconcile the GridPane inventory, permissions, and database location. Move that site separately if it remains undiscovered.
Migration stops because of storage The destination does not have enough free capacity Increase destination storage or reduce the selected scope. Keep at least 1 GB free beyond the total selected-site size.
A demo site redirects to the production domain WordPress settings, a plugin, a theme, cached rules, or custom configuration forces the old hostname Clear caches and inspect WordPress URLs, redirects, CDN settings, and hard-coded configuration before cutover.
The site works on the demo address but fails after cutover DNS still points partly to GridPane, the CDN uses the old origin, or HTTPS is not ready Verify authoritative DNS, update CDN origin settings, wait for the published TTL, and check certificate issuance.
Orders, form entries, or accounts are missing Writes continued after the point-in-time copy Put both environments into maintenance or read-only mode, identify the authoritative data set, and contact xCloud for a supported recopy plan. Do not merge databases manually without an application-specific reconciliation plan.
Email stops after migration A GridPane SendGrid integration, old SPF record, or source-address allowlist was not replaced Configure the destination mail path, update DNS authentication and allowlists, then test transactional delivery before resuming normal traffic.
Cron jobs run twice Source and destination schedules are active at the same time Pause both sides, reconcile any duplicate work, then enable only the xCloud schedule after cutover.

Common mistakes

  • Assuming every GridPane server is eligible. GridPane can run Ubuntu 22.04, but xCloud’s current full-server workflow lists only Ubuntu 20.04 and 24.04 LTS x64.
  • Treating full-server migration as a VPS clone. The xCloud workflow moves selected WordPress files and databases, not the operating system or every GridPane-managed service.
  • Runninggpmigrate-awaywithout a separate need. GridPane marks the command beta, it can alter source WordPress configuration, and it does not export the database.
  • Skipping remote backups. A same-server backup does not protect you from source-server failure.
  • Choosing Go Live for the first copy. Demo Sites provide a safer validation surface before production DNS changes.
  • Forgetting GridPane-specific integrations. Cache, Redis, security, SendGrid, CDN, email, and custom server configuration need explicit destination decisions.
  • Assuming demo data stays current. Stateful production sites can change after the initial copy, so plan a write freeze and supported final copy.
  • Enabling both environments. Duplicate cron jobs, queues, orders, and form submissions create split-brain data.
  • Deleting the source too early. Keep GridPane and its backups available until the rollback window ends.

Rollback guidance

Rollback must preserve one authoritative data set. If a blocking issue appears after DNS cutover:

  1. Put both the GridPane source and xCloud destination into maintenance or read-only mode.
  2. Pause scheduled jobs, queues, and background workers on both environments.
  3. Record any production writes that reached xCloud after cutover.
  4. Decide whether those destination-only writes can be reconciled into GridPane. Do not assume reverse synchronization is available.
  5. Restore the authoritative DNS records to the GridPane source.
  6. Wait until xCloud traffic has drained according to the DNS TTL and live checks.
  7. Verify the GridPane site’s frontend, administrator access, HTTPS, forms, checkout, email, and recent data.
  8. Resume source writes and processing only after xCloud no longer receives production traffic.

If destination-only writes cannot be reconciled, rollback can lose those changes. Make that decision explicitly with the site owner before resuming GridPane.

Frequently asked questions

Can every GridPane server use xCloud full-server migration?

No. The current xCloud requirements are Ubuntu 20.04 or 24.04 LTS x64, NGINX or OpenLiteSpeed, and root SSH on port 22. A GridPane server on Ubuntu 22.04 should use site-level WordPress migration unless xCloud publishes a supported path for that source.

Does this migrate everything managed by GridPane?

No. It migrates selected WordPress files and databases. DNS zones, mailboxes, server packages, custom server configuration, server-level cron jobs, and non-WordPress applications require separate work.

Should I run GridPane’s gpmigrate-away command first?

Not for xCloud’s standard full-server flow. GridPane marks that command beta, and its archive option prepares site files but still requires separate database exports. Use it only for a separately designed manual migration.

Does this provide zero downtime?

No. Demo validation reduces risk, but a stateful site may need a short write freeze for the supported final copy and DNS cutover. The duration depends on site size, the DNS TTL, and the final-copy method agreed with xCloud.

When can I remove the GridPane source?

Remove it only after the rollback window ends, DNS consistently resolves to xCloud, HTTPS is valid, application checks pass, destination backups are verified, and stakeholders confirm that rollback is no longer needed.

If you run into any issues during the migration, feel free to reach out to our support team.