Migrating a WordPress Site from Hostinger to Getwebup

If your site is currently on Hostinger and you're moving to Getwebup, the usual "just restore the cPanel backup" advice doesn't apply — Hostinger runs on hPanel, not cPanel, so there's no one-click account transfer between the two. That's not a dealbreaker, but it does mean a few extra steps, and skipping them is how people end up with a broken site, missing emails, or a few hours of downtime they didn't plan for.

Here's the process we actually use for these migrations, including the parts hPanel's own export tool doesn't warn you about.

Why this migration is different from a cPanel-to-cPanel move

When both the old and new host run cPanel, you can generate a full account backup and restore it directly — files, databases, email accounts, cron jobs, everything, in one archive. Hostinger doesn't give you that option because hPanel isn't built on the cPanel/WHM stack.

What you get instead is a WordPress-level export (files + database) through hPanel's own tools, or a migration plugin. That's fine for the website itself, but it means:

• Email accounts are not included in a WordPress export — you have to move mailboxes separately.
• Server-level settings (PHP version, cron jobs, redirects set in Hostinger's panel rather than .htaccess) won't carry over automatically.
• Hostinger's built-in LiteSpeed caching can mask problems until you disable it, so a site that "looks fine" on Hostinger can show stale or broken pages right after the move.

What to have ready before you start

• A Getwebup hosting account already provisioned, with the PHP version matched to what's running on Hostinger (check hPanel → Advanced → PHP Configuration).
• Admin login to your WordPress dashboard on the Hostinger site.
• Registrar or DNS login for the domain — you'll need it for the cutover.
• A list of every mailbox on the domain, since these move separately from the site.
• Either the All-in-One WP Migration plugin, or 20–30 minutes for a manual files + database export.

Step 1: Lower your DNS TTL early

Do this at least 24 hours before touching anything else. In hPanel, go to Domains → DNS / Nameservers and drop the TTL on your A record to something short:

Type: A
Name: @
TTL: 300

A low TTL means that when you flip the record at cutover, most resolvers pick up the change within minutes instead of hours. This is the step people skip and then blame the "slow" migration on — it isn't slow, the old TTL is just still cached.

Step 2: Export the site from Hostinger

Two ways to do this, pick based on site size:

Plugin method (sites under ~500MB)

Install All-in-One WP Migration on the Hostinger site, run an export, and download the .wpress file. It's the least error-prone route because it packages files, database, plugins, and themes into one archive and handles the URL search-replace for you on import.

Manual method (larger sites)

In hPanel's File Manager, zip public_html and download it. Then export the database from phpMyAdmin (hPanel → Databases → phpMyAdmin), selecting the WordPress database and exporting as a compressed .sql.gz file.

Step 3: Set up WordPress on Getwebup and import

Create the site on your Getwebup hosting (via Softaculous or a manual WordPress install), then:

• Plugin route: install All-in-One WP Migration on the new site and import the .wpress file.
• Manual route: upload and extract the public_html zip in File Manager, create a new database in cPanel → MySQL Databases, import the .sql file via phpMyAdmin, and update wp-config.php with the new database name, user, and password.

If you went the manual route, the domain in the database still points to the old Hostinger URL. Fix it with WP-CLI over SSH rather than a find-and-replace plugin — it's faster and handles serialized data correctly:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables

Step 4: Test on a temporary URL before touching DNS

Don't point the domain yet. Use your Getwebup temporary URL, or add a line to your local hosts file so your browser resolves the domain to the new server while everyone else still sees the old one:

203.0.113.10   yourdomain.com

Check the homepage, a blog post, the checkout flow if it's WooCommerce, and the admin dashboard. Pay attention to mixed-content warnings — Hostinger's forced HTTPS redirect settings sometimes don't carry over, so double-check your SSL is actually issued and active on Getwebup (AutoSSL usually handles this within a few minutes of the domain resolving, but not before).

Step 5: Move email before you cut over

This is the step most migration guides skip, and it's the one that generates support tickets. If you're using Hostinger's built-in email, those mailboxes exist only on Hostinger's mail servers — moving the website doesn't move them.

Step 6: Cut over DNS

Once the new site checks out and email is sorted, update the A record (and MX records if applicable) at your DNS provider to point to Getwebup. Because you lowered the TTL in Step 1, propagation should be mostly done within 15–30 minutes, though some resolvers can take a few hours.

Keep the Hostinger account active for 48–72 hours after cutover. Any visitor or crawler still hitting the old server should see the same content, not a "hosting expired" page — this is your safety net if something needs a last-minute fix.

Common snags with Hostinger migrations specifically

• LiteSpeed Cache plugin left active: it ships enabled on Hostinger and can serve cached pages after the move. Purge and deactivate it before importing, or clear the cache immediately after.
• Hostinger's custom redirects don't transfer: any redirects set through hPanel's redirect manager (rather than in .htaccess or a plugin) need to be recreated manually in cPanel's Redirects tool.
• .htaccess conflicts: Hostinger's default .htaccess sometimes includes LiteSpeed-specific rules that Apache on Getwebup won't recognize. If the site 500s right after import, rename .htaccess and let WordPress regenerate a clean one from Settings → Permalinks.

Prevention: what to check a week later

• Confirm Google Search Console still shows the site as indexed under the same URL structure — no accidental protocol or www/non-www mismatch.
• Test outbound email (order confirmations, password resets) actually lands in an inbox and isn't going to spam from the new server's IP.
• Cancel the old Hostinger plan only after DNS has fully propagated and a full week has passed with no issues.

None of this is hard on its own — it's just more steps than a same-panel migration, and the email piece is the one that catches people off guard. Do the DNS TTL drop early, test on a temporary URL before cutover, and handle email as its own task, and the move is genuinely boring, which is exactly what you want from a migration.