TL;DR
Disable security plugins that change your WordPress login URL before migrating; Hostinger expects /wp-admin and may fail otherwise.
Fix SSL certificate issues on Cloudways first, or Hostinger’s tool may not be able to access your site over HTTPS.
After migration, update your Cloudflare A record to the new Hostinger IP; the migration does not change DNS.
Temporarily turn Cloudflare proxy OFF (orange → grey) so Hostinger can issue a fresh SSL without verification conflicts.
I just migrated a handful of sites from Cloudways to Hostinger, and honestly? The “official” process is about 60% of what you actually need to know. 🤙 The other 40% is troubleshooting why your migration failed, why your SSL is throwing errors, and why Hostinger’s tool can’t even find your login page because you were smart enough to change it from the default. 👊
If you’re using Cloudflare DNS on top of all that, there’s a whole extra layer of things that can go sideways if you don’t set them up right. I made these mistakes so you don’t have to and I’m going to walk you through exactly how to migrate from Cloudways to Hostinger with Cloudflare without losing your mind.
Before You Touch Anything: Prep Your Site on Cloudways
This is the part nobody talks about in the official docs, and it’s the part that caused me the most headaches. Automated migration tools break when your WordPress site has a bunch of security and performance layers that are great for daily operation but terrible for automated transfers.
I often don’t use wp-login or wp-admin to log into my websites for security. I add something different, like slash web-login. That custom login URL is going to break everything. Hostinger’s migration tool needs to log into your WordPress admin panel, and it’s looking for the standard /wp-admin or /wp-login.php endpoint.
If you’ve got a plugin like WPS Hide Login or Solid Security (formerly iThemes Security) changing that path, the tool just can’t get in.
I tried adding my custom login URL in the field Hostinger gives you for it. It still failed. The optional field didn’t work for me, even when I tried variations with /wp plus the custom login.
The fix is simple: go to your WordPress plugins on the Cloudways server and deactivate anything that modifies your login URL. While you’re in there, disable any caching plugins and other security plugins just to be safe.
You want your site as “vanilla” as possible for the migration, then reactivate everything after.
Caution
If you have Redis object caching enabled on Cloudways, it can cause issues during and after migration. Disable Redis object caching before you migrate so you don’t carry over stale cached data into a different Hostinger environment.
Fix Your SSL Certificate Before You Start
This one caught me off guard. I went to check my site in the browser before kicking off the migration and got hit with an “Invalid SSL certificate” error. That’s a migration blocker more often than people realize.
Turns out the SSL on my Cloudways server had either expired or was never properly installed. Hostinger’s migration tool needs to access your site over HTTPS to pull the files and database.
If your SSL is busted, the tool can fail silently or throw a vague error that tells you basically nothing useful.
So I went into Cloudways, generated a fresh Let’s Encrypt SSL certificate for the domain, and that cleared it right up. Check this before you start the migration and save yourself 30 minutes of confusion.
Critical
If it’s giving you an error because an SSL certificate could not be generated, don’t continue the migration. Go to your Cloudways application settings, find SSL Certificate, and install or renew it first—an invalid SSL on the source server can cause the entire migration to fail.
Running the Actual Migration in Hostinger
Once your site is prepped (security plugins off, SSL valid, caching disabled), the migration is straightforward.
Go to your Hostinger dashboard, click Websites, then Migrate Website in the top right. Enter your site URL (I use the full https:// format), and Hostinger will detect WordPress.
Use WordPress credentials (admin username and password), not your hosting/SFTP credentials.
It’s very important that you don’t remove the website from your old server yet. Leave Cloudways intact until Hostinger finishes pulling your documents and database, or there will be nothing to migrate.
Leave the login URL field blank or on the default. Don’t try to be clever here—if you disabled your custom login plugin, the default path will work fine.
| Step | What To Do | Common Mistake |
|---|---|---|
| 1. Enter URL | Use full https://yourdomain.com | Forgetting the protocol or adding www when your site doesn’t use it |
| 2. Select Platform | Choose WordPress | N/A |
| 3. Enter Credentials | Your WP admin username & password | Using hosting credentials instead of WordPress credentials |
| 4. Login URL | Leave blank / default | Entering a custom login path the tool can’t handle |
| 5. Wait | Could be 30 min to 24 hours | Deleting the site from Cloudways before migration finishes |
Once you submit, Hostinger kicks off the migration. I’ve done this with a few sites now and it’s taken roughly an hour each time. Expect some waiting; if there’s an error, they may attach a screenshot and a note, which makes me think a human sometimes gets involved.
Update Your Cloudflare DNS After Migration (This Is Critical)
Here’s where most people mess up. Your migration shows as “completed,” the site appears in your Hostinger panel, and you think you’re golden. You’re not.
The site is still not on Hostinger even if the migration worked. It’s still using the old server address, so we have to go into Cloudflare and change that manually. Otherwise you’re still on Cloudways.
Your domain is still pointing to Cloudways until you manually update the DNS.
To get your new Hostinger IP address, go to Websites → Your Site → Dashboard → Hosting, and you’ll see the Website IP Address. Copy the Hostinger IP.
Now head over to Cloudflare, find your domain, and go to DNS → Records. Update your A record for the root domain (@) to the new Hostinger IP. Double-check www too: if you have a www CNAME, make sure it points to your root domain.
Info
If you’re not using Cloudflare (for example, Namecheap DNS), the process is the same: update the A record wherever your DNS is managed.
Turn Off Cloudflare Proxy for SSL Setup
This is the step that separates people who have a smooth migration from people who spend three hours in Hostinger support chat. After you update your A record in Cloudflare, turn off the proxy (orange cloud to grey cloud).
I turned off the proxies to make sure that the SSL certificate is generated correctly on Hostinger’s side. You should too.
Why? Because Hostinger needs to verify your domain and issue an SSL certificate through Let’s Encrypt. If Cloudflare’s proxy is active, the verification request hits Cloudflare’s servers instead of Hostinger’s, and the SSL generation can fail.
This causes redirect loops and browser warnings that make it look like your entire site is broken.
Once Hostinger has successfully generated the SSL certificate, give it 15–30 minutes after flipping the proxy off, then you can turn the Cloudflare proxy back on. When you do, set Cloudflare SSL/TLS encryption mode to Full (Strict). This helps ensure the encrypted connection works properly between Cloudflare and Hostinger.
Cloudflare proxy during SSL setup
Do This
- Turn Cloudflare proxy OFF (grey cloud) before requesting SSL from Hostinger.
- Wait for SSL to generate, then turn proxy back on.
- Set encryption mode to Full (Strict).
Not This
- Leave the orange cloud proxy on while Hostinger verifies your domain.
- Ignore SSL validation failures and assume it’ll fix itself.
- Accept redirect loops as “normal” after a migration.
After Everything’s Live: Clean Up
Once DNS has propagated (often within minutes to an hour with Cloudflare, though it can technically take up to 48 hours), your site should be loading from Hostinger. Verify by checking the IP your domain resolves to; it should match the Hostinger IP you copied earlier.
Now you can reactivate your security plugins, re-enable your custom login URL, and turn your caching plugins back on. Undo the “vanilla” setup you used for migration.
And don’t forget: your old Cloudways server is still running. Cloudways won’t know you moved and will keep charging you until you cancel. Cancel Cloudways billing after you’ve confirmed everything works on Hostinger.
Frequently Asked Questions
In my experience, about an hour per site. Hostinger says it can take anywhere from a few minutes to 48 hours depending on the size and complexity of your site. Contact support after 48 hours if it’s still “in progress,” because something may have failed quietly. (Source)
Your email DNS records (MX, SPF, DKIM, DMARC) should not be proxied through Cloudflare; they should stay DNS only (grey cloud). Don’t touch email records when you update your website A record unless Hostinger tells you to.
Hostinger’s automated tool is designed for WordPress and other common CMS platforms. For a custom PHP app or non-standard setup, you’ll need a manual migration (SFTP files + database export/import). (Source)
Plugin-based migrations can have upload caps (for example, All-in-One WP Migration’s free version has historically capped uploads around 256MB; check current docs). Hostinger’s built-in migration request tool transfers files on their end, so the plugin cap doesn’t apply in the same way.
If your nameservers already point to Cloudflare, you only need to update the A record within Cloudflare. Don’t change nameservers to Hostinger’s unless you want to stop using Cloudflare entirely.
Final Thoughts
The actual migration from Cloudways to Hostinger isn’t complicated; it’s the stuff around the migration that’ll get you. Disable your security plugins and custom login URLs before you start, make sure your SSL is valid on the source server, and don’t forget DNS after the migration completes.
Once you’ve done this once, the whole process takes maybe 90 minutes including wait time. The hardest part is remembering to turn the Cloudflare proxy off long enough for Hostinger to generate that SSL certificate.
Do that, set encryption to Full (Strict), and you’re good. If you’re still stuck, drop a comment and I’ll try to point you in the right direction.