Book a demo
Book a demo
Login

How to Migrate a WordPress Website from Kinsta to xCloud

Updated September 25, 2026 · 13 min read

If you would rather have it done for you, the xCloud team migrates sites for free: see free website migration. This guide moves one WordPress website from Kinsta to xCloud while keeping the Kinsta copy available for rollback. It is for site owners and administrators who can manage WordPress plugins, Kinsta backups, DNS records, and an xCloud destination. Use xCloud’s migration flow first. If its token-based plugin cannot connect to the Kinsta site, use Migrate Guru, which both Kinsta and xCloud currently document.

Do not cancel Kinsta or remove the source site until the xCloud copy, DNS, HTTPS, forms, scheduled tasks, and recent content all pass verification.

Choose the migration method

Method Use it when Boundary
xCloud migration plugin You can install a plugin on the Kinsta source and want to create the destination from xCloud’s migration wizard. If the plugin or token cannot connect, review security controls and use Migrate Guru instead of repeatedly changing production settings.
Migrate Guru The xCloud token flow fails, or you prefer a migration method that both providers document. Kinsta says Migrate Guru is compatible with Kinsta but may not work with every WordPress site. Kinsta Bot Protection set to block automations can also block the transfer.
Manual files and database transfer Neither plugin route can complete the copy, and you are comfortable moving files and SQL directly. Kinsta supports SFTP, not plain FTP. A downloadable Kinsta backup does not include MyKinsta settings, redirects, custom Nginx rules, blocked addresses, PHP or MySQL configuration changes, or add-ons. Recreate required platform configuration separately.

Prerequisites

  • Administrator access to the source site’s WordPress dashboard.
  • Access to MyKinsta → Sites → site name → Backups.
  • Permission to install and activate WordPress plugins on the Kinsta site.
  • An xCloud account with a ready destination server and enough storage for the site.
  • Control of the authoritative DNS zone for the production domain.
  • A record of existing A, AAAA, CNAME, MX, TXT, SPF, DKIM, and verification records.
  • A maintenance or read-only plan for orders, memberships, comments, form submissions, and other stateful data.
  • A rollback window during which the Kinsta site and its backup remain available.

Step 1: Inventory the Kinsta site

Record the current WordPress and PHP versions, active theme and plugins, domain variants, redirects, cron-dependent features, transactional email path, CDN or proxy configuration, and any custom platform rules.

Kinsta’s downloadable backup contains the WordPress files and a SQL database file, but it does not contain MyKinsta settings or custom server-side configuration. Copy those settings into a private migration worksheet before you move the site.

Expected result: You have a component list that can be checked against the xCloud copy, including configuration that a plugin migration will not reproduce.

Step 2: Create and download a Kinsta backup

In MyKinsta, open Sites → site name → Backups → Download, select Create backup now, and wait for the archive to become available. Download the resulting ZIP file to a secure location.

Kinsta documents that the archive contains the site’s files in the public directory and an SQL file for the database. Kinsta currently allows one downloadable backup per week, and the generated download remains available for 48 hours. Keep this archive even if you use a plugin for the transfer.

Expected result: You have a readable ZIP archive containing the source files and SQL file, plus a separate record of redirects and platform-specific settings.

Step 3: Prepare the source for migration

Clear Kinsta’s server cache at MyKinsta → WordPress Sites → site name → Caching → Server Caching and pause any nonessential security rule that blocks the migration connection. Do not disable security controls preemptively. Change only the control identified by a failed connection, keep the change brief, and restore it after the copy.

The Kinsta MU plugin is designed for Kinsta’s platform and manages features such as full-page caching and CDN integration. Keep it on the live Kinsta source while that site is serving traffic. After the copy completes, review the xCloud destination for Kinsta-specific must-use plugin files and settings that are not applicable outside Kinsta.

If you use Migrate Guru and Kinsta Bot Protection is set to Block automations or a stricter mode, Kinsta says to change it to Block malicious traffic before the migration. Restore your intended protection level after the transfer finishes.

Expected result: The source remains functional and backed up, while the selected migration plugin can make outbound and inbound migration requests.

Step 4: Start the xCloud migration on a demo site

Sign in to xCloud, select Add New Site, choose the destination server, and select Migrate An Existing WordPress Website. Enter the Kinsta source URL. Use xCloud’s demo-site option for the first copy so you can inspect the site before changing production DNS.

On the settings screen, choose the required PHP version, database prefix, and site-user options. Match the source PHP version initially unless you have already confirmed that the theme and plugins support a newer version.

Expected result: xCloud creates a migration job for a temporary destination and shows the plugin download and authentication-token step.

Step 5: Connect the Kinsta source with the xCloud migration plugin

Download the migration plugin file from the xCloud migration wizard and copy the displayed authentication token. In the Kinsta WordPress dashboard, open Plugins → Add New Plugin → Upload Plugin, upload the file, and activate it. Paste the token into the plugin screen on the source site.

Return to xCloud, confirm that the token has been added, and continue. In the database step, select all database tables for a complete migration. Use the file-system-only option only when you intentionally do not want to copy the database.

Expected result: xCloud accepts the token and starts copying the selected WordPress files and database tables to the demo site.

Step 6: Use Migrate Guru if the xCloud token flow cannot connect

Create a destination or demo WordPress site in xCloud. Install and activate Migrate Guru on both the Kinsta source and xCloud destination. On the xCloud destination, open Migrate Guru and copy its Migration Key.

On the Kinsta source, open Migrate Guru, enter the notification email, select Migrate Site, and choose Other Hosts. Paste the destination Migration Key and start the migration. Do not run the xCloud plugin migration and Migrate Guru at the same time.

Expected result: Migrate Guru reports a completed transfer, and the migrated site accepts the original source site’s WordPress administrator credentials.

Step 7: Validate the xCloud demo copy

Test the temporary xCloud site before attaching the production domain. Check at least the following:

  1. Open the home page and representative posts, pages, archives, search results, and 404 page.
  2. Sign in to /wp-admin/ with the source site’s WordPress credentials.
  3. Confirm that the expected users, recent posts, comments, orders, memberships, and form entries are present.
  4. Submit each important form and confirm its notification or downstream action.
  5. Test checkout, login, password reset, downloads, webhooks, scheduled publishing, and external API integrations that apply to the site.
  6. Check media files, redirects, canonical URLs, robots directives, and sitemap output.
  7. Review the destination for Kinsta-specific must-use plugins, cache integration, CDN references, or server paths that should not remain active on xCloud.
  8. Confirm that destination cron jobs, background tasks, and transactional email work, but pause state-changing background work again before the final synchronization.

Expected result: The xCloud demo copy matches the Kinsta source for content and required behavior, with provider-specific configuration identified and corrected.

Step 8: Create an xCloud rollback checkpoint

Before production cutover, configure an xCloud site backup. Open Backup → Backup Settings, select Manage Your Storage Provider, and configure a supported storage destination. Then open Backup → Previous Backups, choose the local or remote backup tab, select Backup Now, and create a full backup.

Verify that the backup appears with a successful status before continuing. This checkpoint protects the validated destination from changes made during final synchronization and cutover.

Expected result: xCloud lists a successful full backup containing the validated destination files and database.

Step 9: Prepare DNS and the write freeze

Identify the authoritative DNS provider before editing records. If Kinsta DNS hosts the zone, keep access to MyKinsta until all required records have been reproduced at the long-term DNS provider or updated in the existing zone. Preserve mail and verification records. Do not replace the whole zone just to change the website destination.

Lower the web record’s TTL at least one existing-TTL interval before the planned cutover. Kinsta’s DNS documentation uses a default TTL of one hour, but your live record may differ. Verify the authoritative response shows the lower value before starting the write freeze.

At cutover time, place both the Kinsta source and temporary xCloud copy into maintenance or read-only mode. Pause checkout, forms, comments, publishing, workers, and scheduled jobs on both sides. Record the freeze start time.

Expected result: The DNS change can propagate according to the confirmed TTL, and no new production data can split between Kinsta and xCloud during the final copy.

Step 10: Perform the final synchronization

Compare the validated xCloud copy with the Kinsta source for changes made since the first migration. For a low-change brochure site, a fresh plugin migration may be the safest complete recopy. For a store, membership site, or other stateful workload, choose a supported final-copy method that preserves the authoritative database. Do not merge two independently writable databases.

The public xCloud plugin guides do not document an incremental database merge. If the migration method cannot safely perform a final recopy, keep the source read-only and contact xCloud support before cutover rather than assuming a rerun will merge changes.

After the final copy, repeat the recent-content and database checks. Keep destination workers and schedules paused until traffic has switched.

Expected result: The xCloud database and files match the frozen Kinsta source, and both environments remain read-only.

Step 11: Point the production domain to xCloud

Add the production domain to the xCloud site, then update only the required web DNS records at the authoritative DNS provider with the values shown for the xCloud destination. Preserve MX, TXT, DKIM, SPF, and unrelated subdomain records.

Check the authoritative DNS response from more than one network or resolver. Do not use a browser cache alone as proof that the DNS change completed.

Expected result: New authoritative DNS responses direct the website domain to xCloud, while email and unrelated services retain their existing records.

Step 12: Enable HTTPS and reopen writes

After the production domain resolves to xCloud, open the xCloud site’s SSL/HTTPS tab and enable HTTPS. Choose the certificate method that matches your setup: xCloud-managed free SSL, your own certificate, or Cloudflare-managed SSL.

Verify the certificate covers every production hostname, including the www variant when used. Recheck the home page, admin login, forms, checkout, callbacks, redirects, and mixed-content warnings over HTTPS. Then enable destination workers and scheduled tasks, remove maintenance mode on xCloud, and keep the Kinsta source read-only.

Expected result: The production domain serves the verified xCloud copy over a valid HTTPS connection, and writes occur only on xCloud.

Verification checklist

  • The production domain resolves to the intended xCloud destination.
  • HTTPS is valid for every production hostname.
  • WordPress administrator login works.
  • Recent source content and stateful records match the destination.
  • Forms, checkout, transactional email, webhooks, search, media, and redirects work.
  • Cron jobs and background workers run only on xCloud.
  • Kinsta-specific must-use plugin behavior and CDN or cache references are absent from the destination where they are not applicable.
  • An xCloud full backup completed after destination validation.
  • The Kinsta source remains intact and read-only throughout the rollback window.

Troubleshooting

Symptom Likely cause Fix
xCloud does not accept the migration token A security control, bot rule, cache layer, or plugin policy blocks the connection. Clear cache, inspect the failed request, and briefly relax only the identified control. If it still fails, restore security settings and use Migrate Guru.
Migrate Guru cannot start or stalls Kinsta Bot Protection blocks automation, or the site is not compatible with the plugin transfer. If Bot Protection is set to block automations or higher, temporarily change it to Block malicious traffic as Kinsta documents. Retry once, then use the manual path or xCloud support if it still fails.
The migrated site shows stale pages Kinsta cache, a WordPress cache plugin, a CDN, or browser cache serves old content. Clear source cache before the final copy, remove provider-specific cache integration from the destination, and purge the destination cache after cutover.
Images or downloads return 404 Files did not copy, paths differ, or an offload integration still points to the old provider. Compare the source and destination wp-content/uploads content, review offload settings, and recopy missing files before reopening writes.
Admin works, but forms or checkout fail Email, webhook, cron, callback, or API configuration was not recreated. Compare the inventory from step 1 with the xCloud destination and update provider-specific endpoints and credentials. Test each state-changing flow again.
HTTPS cannot be issued DNS does not yet resolve to xCloud for every requested hostname, or a proxy configuration interferes with validation. Verify authoritative A, AAAA, and CNAME responses, correct stale records, then retry from SSL/HTTPS.
Some visitors still reach Kinsta DNS caches still hold the old record. Keep Kinsta read-only and available, verify the authoritative record, and wait through the previous TTL. Do not allow writes on both copies.

Common mistakes

  • Cancelling Kinsta before cutover verification. This removes the safest rollback target.
  • Treating a Kinsta downloadable backup as a complete platform export. It omits MyKinsta settings and custom server-side configuration.
  • Changing every DNS record. A website migration usually changes web records, not mail and verification records.
  • Leaving both sites writable. Orders, forms, comments, and scheduled tasks can diverge across two databases.
  • Leaving Kinsta-specific integration active on xCloud. The Kinsta MU plugin is designed for Kinsta’s hosting platform.
  • Skipping a destination backup. Create and verify the xCloud checkpoint before production traffic reaches the site.
  • Assuming migration means zero downtime. A short write freeze and careful DNS cutover reduce risk, but this guide does not promise uninterrupted service.

Rollback guidance

If a critical problem appears after cutover, place xCloud into maintenance or read-only mode and keep Kinsta read-only. Capture any writes that reached xCloud after the switch. Decide which database is authoritative and reconcile or explicitly discard the destination-only delta before changing DNS.

Restore the prior web DNS records, verify authoritative responses, and wait for xCloud traffic to drain. Only then reopen writes and background processing on Kinsta. Do not operate both copies as writable production sites. Keep the xCloud backup and failed destination intact for investigation.

Frequently asked questions

Can I migrate directly to the production domain?

You can, but a demo destination is safer because it lets you validate the copy before changing DNS. The current xCloud migration guide recommends using a temporary domain first.

Does the Kinsta backup include redirects and server rules?

No. Kinsta states that downloadable backups exclude MyKinsta settings and custom server-side configuration, including redirects and custom Nginx rules. Record and recreate required behavior separately.

Can I use Migrate Guru from Kinsta?

Yes, as an alternative. Kinsta documents Migrate Guru as compatible with Kinsta, and xCloud documents the destination Migration Key workflow. Kinsta also warns that Migrate Guru may not work with every site.

When can I delete the Kinsta site?

Delete it only after the rollback window ends, xCloud backups are verified, DNS and HTTPS are stable, and the site has handled real traffic without missing data or provider-specific failures.

If you run into any issues migrating from Kinsta, feel free to reach out to our support team for help.