Migrate WordPress to Hostinger Without Downtime: Step-by-Step

Most botched WordPress migrations fall apart for two reasons: an unmanaged DNS TTL that leaves visitors hitting the dead server for two days, or a reckless SQL search-replace that mangles serialized PHP strings. The result is always the same: broken forms, dumped WooCommerce carts, and an urgent phone call.

Here is how I move live WordPress sites over to Hostinger using SSH, rsync, and WP-CLI without a single second of downtime. We will stage everything on Hostinger first, test it privately through your local hosts file, pull a quick delta sync for last-minute changes, and flip the switch cleanly.

The Zero-Downtime Rule: Drop Your DNS TTL First

DNS propagation is not instant because recursive resolvers cache your records based on their Time to Live (TTL). If your current TTL is set to 86400 (24 hours), DNS caches around the world will happily keep routing users to your old host for a full day after you update your IP.

You want to cut this down 24 to 48 hours before touch day. Log in to your registrar or DNS provider—whether that is Namecheap, Cloudflare, or Route 53—and check your apex (@) and www A records. Drop the TTL down to 300 seconds (5 minutes).

Leave the records pointing to your current host for now. Doing this early guarantees that when you repoint the domain to Hostinger later, resolvers dump their cache within 300 seconds. If you manage your domain outside Hostinger, check out our walkthrough on creating DNS records for Hostinger on Namecheap to see how records should line up.

Exporting the Source Database and Core Files

Skip the all-in-one migration plugins on any database or site over 2GB. They routinely choke on PHP execution timeouts, balloon your disk usage with uncompressed zips, and fail silently mid-transfer. Stick to the terminal where you can see what is happening.

SSH into your source host and dump the MySQL database. If you have WP-CLI installed there, run it directly. If not, plain old mysqldump works fine:

# If WP-CLI is installed
wp db export live_backup.sql --add-drop-table # Or using standard mysqldump
mysqldump -u db_user -p db_name --single-transaction --quick > live_backup.sql

The --single-transaction flag keeps InnoDB tables readable while dumping, so active visitors will not run into locked database errors. Once it is finished, compress it to keep the network transfer fast:

gzip live_backup.sql

Next, pack up your wp-content directory. Do not waste time archiving WordPress core folders like wp-admin or wp-includes—Hostinger spins up fresh core files anyway, and keeping old core files around just risks migrating outdated or patched files. All you really need are your uploads, themes, and plugins:

tar -czf wp-content.tar.gz -C wp-content .

Staging the Files on Hostinger via SSH

Head to Hostinger hPanel and add your domain as an empty website container (or an empty WordPress install). Grab your SSH credentials under Advanced > SSH Access. Pay attention to the port: Hostinger usually runs SSH on port 65002 on shared and cloud packages, not the default port 22.

Push the tarballs straight from your old host (or your local box) to Hostinger using rsync:

rsync -avz -e "ssh -p 65002" live_backup.sql.gz wp-content.tar.gz u123456789@your-hostinger-ip:domains/yourdomain.com/public_html/

Now SSH into Hostinger to unpack everything directly into your web root:

cd ~/domains/yourdomain.com/public_html/
tar -xzf wp-content.tar.gz -C wp-content/
rm wp-content.tar.gz

If you need to pull an entire archive down or sort through permissions in detail, check out our guide on restoring WordPress backups via SSH on Hostinger for specific directory tips.

Importing the Database and Fixing File Permissions

Before touching the database dump, spin up a new MySQL database and user in hPanel under Databases > Management. Copy down the database name, username, and password.

Edit wp-config.php in your Hostinger web root and drop in the new credentials:

define( 'DB_NAME', 'u123456789_dbname' );
define( 'DB_USER', 'u123456789_dbuser' );
define( 'DB_PASSWORD', 'YourSuperSecretPassword123!' );
define( 'DB_HOST', 'localhost' );

Decompress your SQL archive and import it via the CLI:

gunzip live_backup.sql.gz
mysql -u u123456789_dbuser -p u123456789_dbname < live_backup.sql
rm live_backup.sql

Now sort out your file permissions. Hostinger runs standard Linux file perms: 755 for folders and 644 for files. If these are out of sync, you will run into instant 403 Forbidden or 500 Internal Server errors. Run this quick cleanup block from your web root:

find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;

The Serialized Data Trap: Use WP-CLI, Never Raw SQL

If you are switching domains or moving from HTTP to HTTPS during the migration, do not run raw SQL search-and-replace queries like UPDATE wp_options SET option_value = .... WordPress stores widgets, theme settings, and plugin options as serialized PHP strings with rigid byte counts (like s:5:"value").

Swapping a string with a different length via raw SQL breaks the serialization length index. When WordPress tries and fails to parse that broken data, widgets disappear, theme builders break, and plugins deactivate without a trace. Hostinger comes with WP-CLI installed out of the box, so run the official WP-CLI search-replace tool to handle serialized structures safely:

wp search-replace "http://example.com" "https://example.com" --all-tables --dry-run

Look over the dry-run output to verify the affected tables. If the matches look right, run the command for real:

wp search-replace "http://example.com" "https://example.com" --all-tables

If you run into assets trying to load over insecure connections after the run, read our guide on how to fix WordPress mixed content warnings and force HTTPS to clean up stubborn hardcoded URLs in your templates.

Testing Hostinger Before Touching Public DNS

Do not touch public DNS until you know the site boots cleanly. You need to verify that WordPress connects to the database, stylesheets render, and the admin panel works on Hostinger before any real user hits the box.

You can test this by pointing your local machine’s hosts file directly to Hostinger’s IP. This lets your browser load the new server while public traffic continues hitting the old host uninterrupted.

Finding Your Hostinger Server IP

In hPanel, check the left sidebar under Hosting Details. Look for your Server IP (something like 195.35.42.12).

Editing Your Local Hosts File

On macOS or Linux, open your terminal and edit the hosts file with sudo:

sudo nano /etc/hosts

On Windows, launch Notepad as Administrator and open C:WindowsSystem32driversetchosts. Add these lines at the bottom:

195.35.42.12 example.com
195.35.42.12 www.example.com

Save the file and clear your local resolver cache so your machine picks up the override immediately:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # Windows
ipconfig /flushdns

Open an incognito browser window and head to https://example.com. You are now testing directly on Hostinger. Run through this sanity checklist:

• Log into /wp-admin/ with your regular admin account.
• Add an item to the cart or fire off a test form submission.
• Click through category and archive pages, checking DevTools (F12) for 404 assets or script errors.
• Go to Settings > Permalinks and hit Save Changes to generate a clean .htaccess file.

Once everything looks good, delete those two lines from your local hosts file and save it.

The Delta Sync: Capturing Last-Minute Changes

Between your initial export and staging, users may have placed orders, posted comments, or registered accounts on your old server. We need to capture that delta so no data gets lost during the switch.

Throw a temporary maintenance mode banner on the old host or run a fast final database pull. On the old server, run one final dump:

wp db export final_delta.sql --add-drop-table && gzip final_delta.sql

Sync any newly uploaded media files over with rsync using the --update flag. This only transfers files that are newer on the source server, skipping files you already sent over:

rsync -avzu -e "ssh -p 65002" wp-content/uploads/ u123456789@your-hostinger-ip:domains/yourdomain.com/public_html/wp-content/uploads/

Import that final database dump directly on Hostinger:

gunzip final_delta.sql.gz
mysql -u u123456789_dbuser -p u123456789_dbname < final_delta.sql
rm final_delta.sql

This whole delta step takes less than a minute on most sites, bringing the Hostinger environment into full parity with production.

Flipping the DNS Records

Now that Hostinger is staged, verified, and updated, point your public DNS over. Because you dropped the TTL to 300 seconds earlier, the switchover will be nearly instant worldwide.

Head to your DNS provider (Cloudflare, Namecheap, Route 53, etc.) and update your records:

• A Record: Set @ to your Hostinger server IP (e.g., 195.35.42.12).
• CNAME or A Record: Set www to @ or directly to the Hostinger server IP.

Hostinger includes free Let’s Encrypt certificates. Go to hPanel under Security > SSL and install the certificate. If it complains that DNS has not propagated yet, give it 5 to 10 minutes for that 300-second TTL to clear globally, then retry. For more background on zero-downtime database strategies, consult the WordPress.org site migration documentation.

To verify which IP public resolvers are returning, run a quick DNS lookup from your terminal:

dig +short example.com @8.8.8.8
dig +short example.com @1.1.1.1

Once both queries return your Hostinger IP, the migration is complete.

Gotcha: Fixing LiteSpeed Cache and Object Cache Collisions

Hostinger runs on LiteSpeed Web Server across their shared and cloud infrastructure. If your old server was running Nginx with FastCGI cache or Apache with W3 Total Cache, lingering cache drop-ins in wp-content will trigger fatal PHP errors the second you boot the site.

I ran into this exact headache on a client migration: hitting the homepage threw a white screen with Fatal error: Cannot redeclare class WP_Object_Cache. The culprit was an old wp-content/object-cache.php file left behind by Redis from the previous host.

To fix it, SSH into Hostinger and check your drop-ins:

cd ~/domains/yourdomain.com/public_html/wp-content
ls -la | grep -E "advanced-cache.php|object-cache.php"

If you see those files pointing to old plugins or missing Redis sockets, remove them:

rm -f advanced-cache.php object-cache.php

Next, remove the old caching plugin folders in wp-content/plugins/ and install LiteSpeed Cache instead:

wp plugin install litespeed-cache --activate

This lets WordPress plug directly into Hostinger’s LiteSpeed server-level cache without crashing. Check the official Hostinger migration manual if you need to double-check their specific server limits.

Frequently Asked Questions

How long does the old hosting plan need to stay active?

Leave your old hosting account active for at least 72 hours after flipping DNS. While a 300-second TTL handles almost all traffic, rogue ISP resolvers occasionally ignore TTL headers and cache old IPs for days. Keeping the old server online prevents visitors stuck on stale caches from seeing 502 Bad Gateway errors.

Can I use the built-in Hostinger automated migration tool instead?

Hostinger has an automated migration tool in hPanel that accepts WordPress admin logins or backup archives. It works fine for basic blogs under a gigabyte. For anything with custom tables, large media libraries over 5GB, or active WooCommerce checkouts, the manual SSH method is vastly more reliable because it avoids gateway timeouts and gives you precise control over the delta sync.

What should I do if my site gets stuck in a redirect loop after migration?

An ERR_TOO_MANY_REDIRECTS loop usually points to an SSL termination mismatch. Check your wp-config.php file for conflicting reverse proxy headers. If you have Cloudflare running in front of Hostinger, make sure your Cloudflare SSL/TLS encryption mode is set to Full or Full (Strict), not Flexible.

Do I need to regenerate permalinks after moving files?

Yes. Even if your permalink structure did not change, saving your settings under Settings > Permalinks forces WordPress to generate a fresh .htaccess file on the new server. This prevents 404 errors on custom post types and REST API endpoints.

Once your DNS has fully settled and SSL is active, your production site is ready. If you plan to make major template or code tweaks down the road, check out our guide on creating a WordPress staging site in Hostinger hPanel and deploying to production.