Migrate WordPress to Hostinger via SSH and Rsync Without Downtime

Plugin migrations fail the moment your wp-content/uploads folder crosses a few gigabytes. PHP execution timeouts kill the backup script halfway through, leaving you with corrupt zip archives, half-written database tables, and unexpected downtime.

Today you will move a live WordPress production site from your existing server straight to Hostinger using native command-line tools: SSH, mysqldump, and rsync. We will stage the files in the background, sync the database during a two-minute quiet window, test everything locally, and switch DNS without dropping a single visitor transaction.

Preparation: Enable SSH and Generate Keys

Before moving any data, you need direct shell access on both machines. Shared hosting panels often leave SSH toggled off by default.

In Hostinger hPanel, head to Advanced > SSH Access. Enable the SSH toggle. Take note of the connection details: your SSH username (usually something like u123456789), the server IP address, and the non-standard port. Hostinger defaults to port 65002 rather than the standard port 22.

Generate an SSH key pair on your current origin server so it can push files directly to Hostinger without prompting for passwords on every batch.

ssh-keygen -t ed25519 -C "migration-key"
cat ~/.ssh/id_ed25519.pub

Copy the output string. Back in hPanel under SSH Access, paste this public key into the Public Key field and click Add Key. Test the connection from your origin server terminal:

ssh -p 65002 u123456789@YOUR_HOSTINGER_IP "echo 'Connection successful'"

If you see Connection successful, your tunnel is ready. If it hangs, verify that your source host firewall allows outbound connections on port 65002. For help configuring remote access and host requirements, review the Hostinger SSH setup documentation.

Lowering DNS TTL Days in Advance

Downtime during migrations happens when half your visitors query the old server while the other half query the new one over a 24-hour propagation lag. You can eliminate this problem by lowering your Time to Live (TTL).

Log in to your DNS manager (like Cloudflare or your registrar). Locate the root A record pointing to your old host. Change the TTL from automatic or 86400 (24 hours) down to 300 (5 minutes).

Do this at least 24 to 48 hours before you plan your final cutover. If you use Namecheap for your nameservers, check out our guide on how to point Namecheap DNS to Hostinger without breaking email to prevent lost inbox routing during the transition.

The Initial Heavy File Transfer with Rsync

The biggest bottleneck in any migration is the media library. On a client site I moved recently, the media folder was 28 GB across 90,000 files. We copy all these static assets while the live site remains completely operational on the old server.

On Hostinger, find your website root path. For a primary domain, this lives at /home/u123456789/domains/yourdomain.com/public_html. Run your initial rsync pass from the root directory of your existing WordPress installation:

rsync -avzP -e 'ssh -p 65002' 
--exclude 'wp-content/cache/*' 
--exclude 'wp-content/uploads/cache/*' 
--exclude '*.log' 
/var/www/html/ u123456789@YOUR_HOSTINGER_IP:/home/u123456789/domains/yourdomain.com/public_html/

Here is what these flags handle:

• -a (archive): Preserves symlinks, modification times, permissions, and directory hierarchies.
• -v (verbose): Outputs active files to your terminal so you can monitor progress.
• -z (compress): Compresses file data during transit over the network.
• -P: Combines --progress (shows transfer speed and ETA) and --partial (resumes interrupted files if the connection drops).
• -e 'ssh -p 65002': Directs rsync through the SSH wrapper on Hostinger’s custom port.

Because you excluded transient cache directories, this step runs cleanly without copying thousands of useless cached HTML files. Keep working while it syncs; nothing has changed on the live site yet.

Exporting and Staging the MySQL Database

Never migrate a bloated database without cleaning out expired transient caches first. Unused sessions and old transients can add hundreds of megabytes of junk to your wp_options table. If your table is swollen, run through our tutorial to clean up bloated wp_options autoload data with WP-CLI before exporting.

Once clean, export the live database using mysqldump. We use the --single-transaction flag to ensure data consistency without locking tables or taking your live site offline:

mysqldump -u OLD_DB_USER -p'OLD_DB_PASSWORD'  --single-transaction  --quick  --default-character-set=utf8mb4  OLD_DB_NAME | gzip > /tmp/wordpress_dump.sql.gz

Check the size of your compressed dump file:

ls -lh /tmp/wordpress_dump.sql.gz

Transfer this dump file directly to your home directory on Hostinger:

scp -P 65002 /tmp/wordpress_dump.sql.gz u123456789@YOUR_HOSTINGER_IP:/home/u123456789/

Create the Database and Import Data on Hostinger

Now jump into hPanel to prepare the new database container.

1. Go to Databases > Management in hPanel.
2. Enter a new database name, username, and generate a strong password.
3. Click Create. Hostinger prefixes both your database name and user with your account tag (for example, u123456789_dbname).

SSH into your Hostinger account directly to unpack and import the database dump:

ssh -p 65002 u123456789@YOUR_HOSTINGER_IP
cd /home/u123456789
gunzip wordpress_dump.sql.gz
mysql -u u123456789_dbuser -p'YOUR_STRONG_PASSWORD' u123456789_dbname < wordpress_dump.sql
rm wordpress_dump.sql

The import process streams directly through standard input into MySQL. For a 250 MB uncompressed SQL file, this takes roughly 15 to 30 seconds on Hostinger’s NVMe storage clusters. Always remove the raw SQL dump immediately after importing to avoid leaving exposed database backups in accessible directories.

Update wp-config.php on Hostinger

Your files on Hostinger still contain the database credentials from your old server. Open wp-config.php in your Hostinger site root:

nano /home/u123456789/domains/yourdomain.com/public_html/wp-config.php

Update the database name, username, and password constants to match your new Hostinger database settings:

// ** Database settings - Hostinger ** //
define( 'DB_NAME', 'u123456789_dbname' );
define( 'DB_USER', 'u123456789_dbuser' );
define( 'DB_PASSWORD', 'YOUR_STRONG_PASSWORD' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', '' );

Verify that DB_HOST is set to localhost. Hostinger co-locates the MySQL instance on the shared environment. If you migrated between different domains or switched from staging to production, follow our guide on how to safely update URLs after WordPress migration with WP-CLI.

The Delta Sync: Eliminating File Drift

Between your initial heavy rsync pass and setting up the database, visitors might have uploaded images or plugins might have generated temporary assets. We run a delta sync.

Rsync compares file sizes and modification timestamps. It only sends files that were created or modified since our first run:

rsync -avzP --delete -e 'ssh -p 65002' 
--exclude 'wp-config.php' 
--exclude 'wp-content/cache/*' 
--exclude '*.log' 
/var/www/html/ u123456789@YOUR_HOSTINGER_IP:/home/u123456789/domains/yourdomain.com/public_html/

Notice two adjustments in this command:

• --delete: Removes files on Hostinger that were deleted on the source server during our staging run.
• --exclude 'wp-config.php': Prevents overwriting the new Hostinger database credentials you just configured.

Because 99% of your assets are already on the destination server, this delta pass finishes in seconds rather than hours. Read the full rsync manual to customize include/exclude patterns for custom directory setups.

Test the Destination Site Locally Before Changing DNS

Do not switch public DNS blind. You should confirm that your theme renders, plugins execute, and the database connects on Hostinger before altering public records.

You can force your local development laptop to resolve your live domain directly against the new Hostinger IP address using your local hosts file.

On macOS or Linux, open your terminal and edit /etc/hosts:

sudo nano /etc/hosts

On Windows, edit C:WindowsSystem32driversetchosts with administrative privileges. Append this line at the bottom:

# Hostinger migration test
YOUR_HOSTINGER_IP yourdomain.com www.yourdomain.com

Save the file. Flush your local DNS cache:

# On macOS:
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # On Linux (systemd-resolved):
sudo resolvectl flush-caches

Open an Incognito or Private browser window and navigate to https://yourdomain.com/wp-admin. Log in, check post edits, add an item to your cart, or preview pages. Everything you interact with now executes directly on Hostinger.

If you see a mixed content warning or your browser throws an SSL error because the certificate isn’t installed yet, check our guide on how to fix WordPress mixed content errors on Hostinger after SSL activation. Once confirmed, remove that line from your hosts file.

Switch DNS and Install Let’s Encrypt SSL

With testing complete, you are ready for the switch.

1. Log in to your DNS provider.
2. Change the root A record from your old server IP to your Hostinger Server IP.
3. Ensure the www record (whether a CNAME or A record) points to the correct destination.

Because you reduced your TTL to 300 seconds earlier, global DNS resolvers will drop their cached records and discover the new Hostinger IP within 5 minutes. If you want to check propagation across worldwide nodes, inspect your domain on whatsmydns.net.

Once DNS points to Hostinger, navigate to Security > SSL in hPanel. Click Install SSL. Hostinger provisions an automatic Let’s Encrypt certificate. Because DNS is already answering from Hostinger’s edge, the ACME HTTP-01 challenge will pass immediately.

Post-Migration Fixes: Permissions and Cron

Migrations between servers often scramble POSIX file ownership and permission bits. Run these commands from SSH inside your Hostinger web root to ensure WordPress can write uploads, run auto-updates, and generate security tokens:

cd /home/u123456789/domains/yourdomain.com/public_html
find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;

Default WordPress triggers background tasks via wp-cron.php on page requests, which adds execution latency for visitors. Now that you have SSH access, turn off the pseudo-cron and configure an operating system cron job. Add this line to your wp-config.php file:

define( 'DISABLE_WP_CRON', true );

Then review our walk-through on how to disable WP-Cron and set up a real cron job in Hostinger to schedule system-level executions every 10 or 15 minutes.

Frequently Asked Questions

What if my existing host does not provide SSH access?

If your old host locks down SSH, you cannot run rsync directly between hosts. You must create an archive on your old server using cPanel File Manager or SFTP, download it to your local machine, and then run rsync from your local terminal pushing up to Hostinger’s port 65002.

Why did my images throw 403 Forbidden errors after migrating?

This is almost always a file permissions mismatch. Directories require 755 permissions so the web server process can enter and list files, while media files require 644. Run the find commands outlined in the post-migration section to reset all permissions recursively.

How do I handle active WooCommerce orders during the DNS window?

To avoid lost orders, place your store in maintenance mode right before the final database export. Export the database,

Can I run WP-CLI commands on Hostinger shared hosting?

Yes. WP-CLI is pre-installed on Hostinger cloud and shared platforms. Type wp --info in your SSH session to verify the binary path and running PHP version. You can execute wp search-replace, plugin updates, and cache flushes directly from the command line.

Next Steps for Your Hostinger Stack

Now that your site runs on Hostinger with clean directory permissions and low-latency database access, optimize your background processing. Set up a system cron job to handle scheduled tasks efficiently using our guide on disabling WP-Cron and setting up real system crons on Hostinger.