Migrate WordPress to Hostinger: Zero-Downtime Step-by-Step Guide

A botched WordPress migration drops carts, spits 502 Bad Gateway errors, and tanks search rankings. You can avoid all of it by treating the move like a blue-green deployment instead of flipping your DNS records blindly and praying a plugin handles the rest.

I recently moved a 14GB WooCommerce store over to Hostinger without dropping a single HTTP request. We staged the database first, trimmed DNS TTLs days ahead of time, and audited the whole build locally against Hostinger’s edge before touching production routing.

The Migration Strategy

Most folks reach for an all-in-one backup plugin, run an export, and watch PHP hit an execution timeout or run out of memory at 512MB. If you’re running a real site with any amount of traffic, you treat static files and relational data as two separate problems.

Here is the roadmap:

• Drop your DNS TTL so record updates resolve in seconds, not days.
• Dump database tables cleanly and rsync wp-content straight to Hostinger.
• Hardcode Hostinger’s IP in your local hosts file to run integration tests on the live domain.
• Flip production DNS and run a quick delta sync for any orders or comments that came in mid-flight.

If you’d rather run the whole migration over an SSH tunnel from the command line, check out my guide on migrating WordPress to Hostinger via SSH and Rsync. Today, we’re focusing on the staged, zero-downtime workflow.

Step 1: Lower Your DNS TTL

DNS caching causes 90% of migration headaches. If your root A record has a default TTL of 86400 (24 hours), resolvers worldwide will keep serving your old server’s IP for a full day after you point traffic away.

Log into your DNS provider (Cloudflare, Route 53, Namecheap, etc.) at least a day before you plan to migrate. Drop the TTL on your apex (@) and www records from Automatic or 86400 down to 300 seconds (5 minutes).

If your domain is with Namecheap, take a look at our guide to pointing Namecheap domains to Hostinger without breaking email so you don’t accidentally clobber your MX and DKIM records while editing zone files.

Step 2: Provision the Destination on Hostinger

Head into hPanel to set up your destination container. Go to Websites > Add Website, select WordPress, and hit Skip, create an empty website. Don’t use the one-click installer here—you want an empty directory so there are no file conflicts with your existing install.

Grab these credentials from your hPanel dashboard before moving on:

• Server IP Address: Listed right on the main hosting panel.
• SSH / SFTP Details: Port 65002, hostname, username, and password.
• MySQL Credentials: Create a new database and user under Databases > Management.

Make sure your target database collation matches your old host. In almost every modern WordPress installation, you’ll want utf8mb4_unicode_ci.

Step 3: Export the Database Without Locking Tables

Exporting a production database through phpMyAdmin is asking for timeouts and corrupt serialized strings. Pull the dump over SSH using WP-CLI or raw mysqldump on your current host.

Run this to dump the database in a single transaction:

mysqldump -u source_db_user -p  --single-transaction  --quick  --skip-lock-tables  source_db_name > backup_production.sql

The --single-transaction flag is critical for InnoDB tables. It reads a consistent snapshot of your database without locking writes, meaning customers can still browse and submit orders while the dump writes to disk.

Gzip the SQL dump immediately to speed up transfer times:

gzip -9 backup_production.sql

If the dump is massive and gives you trouble on the import side, see our guide on importing large WordPress databases via SSH on Hostinger.

Step 4: Sync wp-content Files

Don’t waste bandwidth transferring core WordPress files like wp-admin and wp-includes. You only care about wp-content, your wp-config.php, and any custom assets sitting in your document root (like Google verification files).

From your source server, rsync straight to Hostinger’s SSH endpoint:

rsync -avz -e "ssh -p 65002"  --exclude 'cache/'  --exclude 'updraft/'  ./wp-content/ hostinger_user@your_hostinger_ip:public_html/wp-content/

We explicitly exclude cache directories here. Copying stale object caches or pre-rendered HTML files into Hostinger will only collide with their LiteSpeed caching layer later.

Step 5: Import the Database and Update wp-config.php

SSH into Hostinger, or jump into phpMyAdmin from hPanel. If you have terminal access, importing the gzipped archive directly is much faster:

gunzip < backup_production.sql.gz | mysql -u hostinger_db_user -p hostinger_db_name

Now open wp-config.php inside public_html/ on Hostinger. Plug in the database name, username, and password you created in Step 2:

define( 'DB_NAME', 'u123456789_live' );
define( 'DB_USER', 'u123456789_admin' );
define( 'DB_PASSWORD', 'YourStrongGeneratedPasswordHere' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

Check the $table_prefix variable below the database block. It must match the table prefix in your SQL dump (whether that’s standard wp_ or something like wp_9f8s_).

Step 6: Test Locally via the Hosts File

Do not touch your live DNS yet. You need to prove that assets load, plugins boot without fatal errors, and admin sessions work before anyone else hits this server.

Override your local machine’s DNS resolution by editing your hosts file:

• macOS/Linux: /etc/hosts (run sudo nano /etc/hosts)
• Windows: C:WindowsSystem32driversetchosts (open Notepad as Administrator)

Append a line mapping your production domain to Hostinger’s IP address:

# Format: [Hostinger Server IP] [domain.com] [www.domain.com]
185.199.110.153 example.com www.example.com

Save it, then flush your local DNS cache so your machine picks it up immediately:

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

Fire up a private browsing window and navigate to your site. You’re now browsing the site on Hostinger while everyone else is still hitting the old server.

What to Validate Locally

1. Log in at /wp-login.php to confirm session cookies and auth salts work.
2. Drop a dummy comment or submit a form to verify write permissions on the database.
3. Open DevTools (F12) to catch any 403 Forbidden assets, broken scripts, or mixed-content errors.
4. Make sure your object cache isn’t throwing errors. If you’re setting it up fresh, follow our guide to enable Redis Object Cache in Hostinger hPanel.

Step 7: Cut Over DNS and Generate SSL

Once you’ve confirmed everything looks and functions as expected, remove the test line from your local hosts file.

Go back to your DNS manager and update your A records to point to Hostinger’s IP:

Type Name Value TTL
A @ 185.199.110.153 300
A www 185.199.110.153 300

Since you dropped the TTL to 300 seconds back in Step 1, traffic will start swinging over to Hostinger within five minutes.

Hop over to Hostinger hPanel and go to Security > SSL. Click Install SSL. Hostinger’s Let’s Encrypt integration will spot the updated DNS records, verify the domain, and spin up your certificate automatically. If you’re locking down certificate authorities on your domain, check our walkthrough to configure CAA records to restrict SSL issuance.

Step 8: Perform a Final Delta Sync

If you run an active store or high-traffic blog, someone probably placed an order or left a comment on the old server during the five-minute DNS shift. Leave your old hosting running for 48 hours to handle this tail.

To grab that delta data, toggle maintenance mode on the old server using WP-CLI:

wp maintenance-mode activate

Dump the database on the old host one last time using Step 3 and re-import it on Hostinger. Then re-run the rsync command from Step 4. Because rsync only pushes modified and newly created files, it will finish in seconds.

Make sure maintenance mode is turned off on Hostinger:

wp maintenance-mode deactivate

Troubleshooting Migration Gotchas

1. Redirect Loops (ERR_TOO_MANY_REDIRECTS)

If you’re using Cloudflare in front of Hostinger, make sure your SSL/TLS encryption mode is set to Full (Strict). If it’s set to Flexible, Cloudflare talks to Hostinger over port 80 (HTTP), while Hostinger’s web server tries to force HTTPS—bouncing the request back and forth forever.

You can also force your domain values directly in wp-config.php to rule out bad database entries:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

2. Missing Images or 404 Errors on Media Assets

If media uploads throw 404s, rewrite rules are usually missing. Hostinger runs a LiteSpeed/Nginx stack, so verify your .htaccess has standard WordPress directives:

# BEGIN WordPress

RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

# END WordPress

If your uploads fail outright due to file sizes, see our guide on how to fix 413 Request Entity Too Large on Hostinger WordPress.

Frequently Asked Questions

How long does a WordPress migration to Hostinger take?

For sites under 5GB, copying files and importing the database takes roughly 15 to 30 minutes. If your DNS TTL was lowered ahead of time, the cutover itself takes less than 5 minutes.

Can I use Hostinger’s automated migration tool instead?

Yes. Hostinger has a migration assistant in hPanel that pulls data using your WP admin credentials. But on massive media directories, custom cron jobs, or busy WooCommerce stores, a manual sync with mysqldump and rsync gives you full control and zero dropped transactions.

Will my business email stop working during the migration?

Not if you only touch your A records. Leave your MX, TXT (SPF), and CNAME (DKIM) records alone on your DNS provider, and your mail routing won’t even notice the move.

When should I cancel my old hosting plan?

Keep your old host active for at least seven days. It’s your fallback if you realize an unmigrated subdomain, scheduled backup, or standalone database was left behind.

Next Steps

Now that your site is running cleanly on Hostinger, sort out your scheduled jobs. WordPress relies on site visits to trigger scheduled tasks by default. Read our tutorial to replace WP-Cron with a true Linux system cron on Hostinger so your background tasks execute reliably on time.

Official resources

• WordPress developer documentation
• OpenAI API documentation