Book a demo
Book a demo
Login

How to Migrate a WordPress Website from Hostinger 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 Hostinger to xCloud with xCloud’s existing WordPress website migration workflow. It is for site owners and administrators who can access Hostinger dashboard, sign in to WordPress, create a destination site in xCloud, and update the domain’s authoritative DNS. You will back up the Hostinger site, migrate it to a temporary xCloud destination, validate the copy, control new writes during the final migration window, switch DNS, verify HTTPS, and keep Hostinger available for rollback.

Choose the correct migration method

Use xCloud’s existing WordPress website migration workflow as the primary method. It creates a destination, supplies a migration plugin and authentication token, and lets you select the database content and files to copy.

Situation Recommended method
One standard WordPress site with administrator access xCloud’s existing WordPress website migration workflow
The xCloud token workflow cannot complete after documented preparation Migrate Guru on xCloud
A non-WordPress application or several unrelated services Use the matching Git, Docker, or application migration workflow instead of this guide
Mailboxes hosted by Hostinger Keep the mail service and its DNS records separate. This guide migrates the WordPress website, not mailbox contents

Do not use full-server migration for this task unless xCloud has confirmed that the source server meets its full-server access and stack requirements. Managed WordPress customers normally have the WordPress-level access needed for the site migration method described here.

Prerequisites

  • Administrator access to the source WordPress dashboard on Hostinger.
  • Access to Hostinger dashboard for the correct website.
  • An xCloud account and a destination server with enough storage for the site’s files, database, backups, and working space.
  • Access to the authoritative DNS provider for the production domain. If Hostinger manages the DNS, you need permission to edit it under Domains → DNS.
  • A current source backup stored separately from both hosting platforms.
  • A list of critical pages, forms, checkout flows, users, redirects, scheduled actions, outbound email, webhooks, and integrations to validate.
  • A record of the current DNS values, including web, mail, and verification records.
  • A maintenance window for a short write freeze if the site accepts orders, comments, form submissions, memberships, uploads, or content edits.
  • A rollback owner who can restore the previous DNS records and re-enable the Hostinger site if needed.

The public xCloud migration guide does not document incremental synchronization or automatic reverse synchronization for this plugin workflow. If the source will continue changing after a rehearsal migration, confirm a supported final-copy plan with xCloud Support before the cutover window. Do not assume that rerunning a migration merges newer records safely.

Step 1: Create and download a Hostinger backup

In Hostinger dashboard, open Websites → Dashboard, search the sidebar for Backups, and open Restore and download. Select Website backup to download a backup for the specific WordPress site. Hostinger sends the file and database backup links to the account owner’s email.

If the website-level option is unavailable, Hostinger also documents separate Files backups and Database backups downloads. Keep both parts together and label them with the same backup date.

Expected result: You have a complete, dated copy of the source WordPress files and database outside Hostinger. You can identify the backup you would restore during rollback.

Step 2: Record the source site’s current state

In Hostinger dashboard, open Websites → Dashboard → WordPress Overview. Record the WordPress and PHP versions, active theme, active plugins, cache settings, permalink structure, administrator access, and the database associated with the site. If WordPress was installed manually and WordPress Overview is unavailable, use the normal /wp-admin login and record the same information there.

Also record the current authoritative DNS values before you change anything. Include apex and www web records, MX records, mail-related TXT records, and third-party verification records.

Expected result: You have a source inventory and a DNS rollback record for the exact site being migrated.

Step 3: Prepare the Hostinger site for migration

Clear the WordPress cache and review active caching, security, firewall, and must-use plugins. Keep the source site working and do not remove a component merely because it is host-specific.

If the xCloud token cannot connect, follow xCloud’s documented preparation steps narrowly: clear caches, temporarily disable a blocking security or cache plugin, and retry. xCloud advises disabling two-factor authentication or stronger bot protection only when token migration fails. Restore every temporary security change after the copy completes.

Expected result: The source site remains healthy, and WordPress can accept the xCloud migration plugin connection without leaving security controls disabled longer than necessary.

Step 4: Create a temporary destination in xCloud

Sign in to xCloud and select Add New Site. Choose the destination server, then select Migrate An Existing WordPress Website. Enter the Hostinger site’s source URL and use xCloud’s demo or temporary domain rather than assigning the production domain immediately.

Review the destination settings, including the PHP version, database prefix, and site user choices, before continuing.

Expected result: xCloud creates a migration destination that you can test without directing production visitors away from Hostinger.

Step 5: Install the xCloud migration plugin on Hostinger

In xCloud’s Plugin step, download the migration plugin file and copy the authentication token. Open the source WordPress dashboard on Hostinger, then go to Plugins → Add New → Upload Plugin. Upload and activate the plugin, paste the token into the plugin, and save it.

Return to xCloud, confirm that the token has been added, and continue to the database step.

Expected result: xCloud recognizes the Hostinger WordPress site and allows you to configure what the migration will copy.

Step 6: Set the write freeze for the definitive copy

If the site stores changing data, stop new orders, comments, form submissions, memberships, uploads, and content edits immediately before the definitive migration. Pause source-side scheduled actions, cron jobs, or queue workers that can write to the database or uploads directory.

Do not enable equivalent production processing on xCloud yet. If you ran an earlier rehearsal migration and the Hostinger site has changed since then, use the final-copy method that xCloud Support confirmed for your case before changing DNS.

Expected result: The Hostinger copy is the known authoritative source, but it is no longer accepting writes that could be omitted from the final destination.

Step 7: Start the migration in xCloud

In xCloud’s Database step, choose the data needed for the migration. The current xCloud workflow offers migration of all database tables or a filesystem-only copy. For a complete WordPress migration, select the option that includes the required database tables and site files, review the selection, and start the migration.

Keep Hostinger and the downloaded backup available. Do not change DNS while the copy is running.

Expected result: xCloud reports that the migration completed, and the temporary destination loads without depending on the production domain.

Step 8: Validate the temporary xCloud site

Open the temporary xCloud URL and check:

  • The homepage, representative posts, pages, archives, and custom post types.
  • WordPress administrator login, expected users, and role permissions.
  • Media Library items and direct upload URLs.
  • Forms, search, comments, checkout, memberships, and other write paths.
  • Permalinks, canonical URLs, redirects, and mixed-content warnings.
  • Theme output, plugin features, REST API consumers, and webhooks.
  • Transactional email through the destination’s intended mail configuration.
  • Scheduled actions and cron-dependent features without allowing duplicate production execution.

Replace or reconfigure Hostinger-specific cache or platform integrations on the destination only when they do not apply to xCloud. Keep the source unchanged and available.

Expected result: The xCloud copy matches the frozen Hostinger source for required content and behavior, and every blocking issue has a recorded resolution.

Step 9: Create an xCloud backup before cutover

Configure an xCloud site backup after the restored files and database pass validation. The current xCloud backup workflow starts under Backup → Backup Settings, where you select and configure a storage provider. Run the destination backup and confirm that it appears in the site’s backup history.

Expected result: You have a known-good xCloud recovery point from before production traffic and background processing begin.

Step 10: Prepare the domain and DNS cutover

At least one existing TTL interval before the maintenance window, lower the TTL for only the web records you expect to change. Confirm that authoritative DNS now returns the lower TTL before relying on it.

In xCloud, open the demo site’s Domain → Go Live flow, enter the production domain, and use the target records shown under DNS Setup. If Hostinger is authoritative for the domain, open Domains → DNS, select the domain, and update the required web records. Preserve unrelated MX, TXT, verification, and mail records.

Expected result: Authoritative DNS returns the xCloud destination values. Cached resolvers may still send some visitors to Hostinger until their previous records expire.

Step 11: Verify HTTPS and production traffic

After DNS points to xCloud, open the site’s SSL/HTTPS tab and select the appropriate certificate option. For xCloud-managed TLS, select Use free SSL certificate issued & managed by xCloud and enable HTTPS. Then test every production hostname you use, including the apex domain and www when applicable.

Repeat the critical validation checklist through the production domain. Check HTTP-to-HTTPS behavior, redirects, secure cookies, mixed content, forms, checkout, logins, email, webhooks, and recent content.

Expected result: The production domain serves the validated xCloud site over HTTPS without certificate warnings, redirect loops, or missing recent data.

Step 12: Resume destination processing

When production DNS and HTTPS checks pass, enable the intended xCloud scheduled actions, cron jobs, queues, and other background processing. Keep the Hostinger copy read-only while cached DNS traffic drains.

Do not run equivalent write-producing processors on both hosts at the same time.

Expected result: xCloud handles production traffic and background work, while Hostinger remains available only as a rollback source.

Verify the migration

The migration is complete only when all of these checks pass:

  • The production domain resolves to the xCloud destination from more than one network or DNS resolver.
  • HTTPS works for every production hostname without a browser warning.
  • WordPress administrator login works, and expected users and roles are present.
  • Recent posts, orders, comments, form entries, memberships, and uploads match the frozen Hostinger source.
  • Forms, checkout, search, redirects, email, webhooks, scheduled actions, and queues behave as expected.
  • xCloud has a verified destination backup.
  • Hostinger remains read-only and available during the agreed rollback window.

Rollback guidance

Rollback is a traffic and data decision, not only a DNS reversal.

  1. Stop writes and background processing on xCloud.
  2. Keep Hostinger read-only while you inspect any data created after cutover.
  3. Choose which database is authoritative. Reconcile the xCloud write delta back to Hostinger with a supported application-specific process, or explicitly accept that discarding it can lose data.
  4. Restore the previous authoritative DNS records from your saved record.
  5. Wait for xCloud traffic to drain according to DNS TTLs and resolver caches.
  6. Re-enable source-side writes, scheduled actions, and queues only after Hostinger serves production traffic again.

Do not allow both copies to accept writes during rollback. Neither the xCloud migration guide nor the Hostinger sources checked for this page document automatic reverse synchronization from xCloud to Hostinger.

Troubleshooting

Symptom Likely cause Fix
xCloud does not accept the plugin token A cache, security plugin, two-factor check, or bot-protection layer blocks the request Clear caches first. Temporarily disable only the blocking control described by xCloud, retry, then restore it immediately after migration
Migration completes but the temporary site is missing content The migration was set to filesystem only, or required database tables were excluded Review the xCloud database selection and run the supported migration again with the required files and tables before cutover
The destination shows stale pages Cached HTML, object cache, or a CDN still serves the old response Purge the relevant source and destination caches. Test the temporary xCloud domain directly before changing DNS
Recent orders, forms, or comments are missing The Hostinger site accepted writes after the definitive copy started Restore the write freeze. Do not merge records manually without an application-safe plan. Use the supported final-copy or reconciliation method agreed for the site
The production domain still reaches Hostinger DNS changed at the wrong provider or cached records have not expired Confirm the authoritative nameservers, check the records there, and wait for the previous TTL to expire
HTTPS cannot be issued The domain does not yet resolve to xCloud, the wrong hostname was configured, or a conflicting DNS record remains Verify the authoritative apex and www records, remove only conflicting web records, then retry the xCloud SSL/HTTPS workflow
Mail stops after DNS cutover Mail-related DNS records were replaced during the web cutover Restore the saved MX and mail-related TXT records. Change only the web records required by xCloud
Two copies process the same scheduled task Scheduled actions or workers are active on both hosts Pause processing on both sides, choose the authoritative database, reconcile any duplicate effects, then enable processing only on xCloud

Common mistakes

  • Changing DNS before validating the copy. Use a temporary xCloud domain first so visitors do not see an incomplete migration.
  • Skipping the external Hostinger backup. A platform restore point is useful, but a separately downloaded copy reduces your dependence on either host during recovery.
  • Leaving security controls disabled. xCloud recommends disabling stronger controls only when the token migration fails. Restore them after the copy.
  • Assuming mailboxes move with WordPress. Keep Hostinger mail service and mail DNS records intact unless you are running a separate mailbox migration.
  • Changing every DNS record. The web cutover usually requires specific records shown by xCloud. Preserve unrelated MX, TXT, and verification records.
  • Letting both sites accept writes. Split-brain data cannot be repaired by reversing DNS alone.
  • Running cron jobs on both hosts. Duplicate scheduled actions can send messages twice or process an order more than once.
  • Cancelling Hostinger immediately. Keep the source and backup until DNS caches drain, production validation passes, and the rollback window closes.

Frequently asked questions

Do I need SSH access to Hostinger for this migration?

No. The primary workflow in this guide uses WordPress administrator access and xCloud’s migration plugin and token. It does not require source root SSH.

Should I use Migrate Guru instead?

Use xCloud’s existing WordPress website migration workflow first. Migrate Guru is a documented xCloud-compatible alternative when you can access both WordPress dashboards and the primary token workflow cannot complete.

Will the migration have zero downtime?

Do not assume zero downtime. A site with changing data needs a short write freeze unless xCloud confirms a supported final synchronization method for your case. DNS caching can also send some visitors to the source after records change.

Can email stay at Hostinger after the website moves?

Yes, if the Hostinger mail service remains active and you preserve its MX and mail-related TXT records. The WordPress site migration does not replace a separate mailbox migration.

When can I remove the Hostinger site?

Remove it only after production DNS, HTTPS, content, logins, forms, email, scheduled work, and backups are verified, the rollback window has closed, and no production traffic remains on the source.

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