How to migrate from Hostinger to growhost in 30 minutes (zero downtime)

The trick to migrating a WordPress site without downtime is not technical wizardry. It is sequencing. Most migration disasters happen because someone changed DNS before the destination was ready, or restored a backup without testing it, or forgot that email was on the same server as the web hosting.

This guide is the version we hand to growhost customers who want to do their own migration from Hostinger. It is also the playbook our migration team uses internally when we do it for you. Whichever side you end up on, the steps are the same.

Total active time, assuming a vanilla WordPress site under 2 GB: about 30 minutes. Total wall-clock time, including DNS propagation: about an hour.

Before you start: the pre-flight (do this 24 hours early)

Two things to do the day before, while your site is still on Hostinger.

1. Drop your DNS TTL to 300 seconds

DNS records have a "time to live" — how long downstream resolvers can cache them. Most domains have TTLs of 3,600 or 14,400 seconds, which means when you change DNS, it can take several hours to propagate everywhere. Dropping the TTL to 300 seconds means the propagation window becomes five minutes.

Log in to your domain registrar (GoDaddy, Namecheap, BigRock, wherever your domain is registered — note that this is separate from where your site is hosted), find the DNS / Zone management section, and edit the TTL field for the A and AAAA records on your apex domain and www subdomain. Save. Wait 24 hours.

2. Confirm your email situation

If your email runs on Hostinger (you log into webmail at something like mail.yourdomain.in), the MX records point at Hostinger's mail servers. Web migration alone will not move email. You have two options: leave MX records pointing at Hostinger until you separately migrate mail, or migrate mail as part of this exercise (much more complex, allocate a full day).

If you use Google Workspace or Zoho Mail, your MX records already point at Google or Zoho. You can ignore email entirely. Web migration will not affect it.

Step 1: Generate the backup from Hostinger

Log into hPanel. Navigate to Files > Backups. Click Generate new backup for both the Files (site content) and the Database (MySQL dump). Wait for both to complete — for a typical 1 GB site, this takes a few minutes.

Download both archive files to your laptop. You should have:

• A .tar.gz or .zip for files (typically named something like files-backup-2026-05-15.tar.gz)
• A .sql.gz for the database (typically database-backup-2026-05-15.sql.gz)

Verify the file sizes are reasonable. A 1 GB WordPress site usually backs up to a 300-500 MB compressed archive. If yours is 1 KB, something went wrong; re-generate.

Step 2: Provision the destination host

Log into your growhost dashboard. Spin up a new WordPress site on your chosen plan. The dashboard gives you a temporary URL (something like your-site.growhost.in) and SFTP / SSH credentials.

Note these down. You'll need them in the next step.

Step 3: Upload and restore

This is the only part that can feel intimidating if you've never done it. There are two paths.

The simple path: cPanel restore

If your destination plan includes cPanel (the growhost WordPress Starter and Business plans do), log into cPanel, go to Backup Wizard > Restore, and upload both your Files and Database archives. cPanel handles the extraction and database import for you. Total time: 5 to 10 minutes.

The command-line path

For larger sites or if you prefer SSH, the commands look like this:

# Upload files to the new host
scp files-backup-2026-05-15.tar.gz user@new-host:~/

# SSH in
ssh user@new-host

# Extract files into the docroot
cd ~/public_html
tar -xzf ~/files-backup-2026-05-15.tar.gz

# Import the database
gunzip -c ~/database-backup-2026-05-15.sql.gz | mysql -u dbuser -p dbname

The database user and database name are in your destination dashboard. Replace dbuser and dbname accordingly.

Step 4: Update wp-config.php

The wp-config.php from Hostinger contains database credentials that won't work on growhost. SSH in (or use the file manager) and edit wp-config.php in your docroot.

Update these four constants to match the credentials growhost gave you:

define( 'DB_NAME', 'new_dbname' );
define( 'DB_USER', 'new_dbuser' );
define( 'DB_PASSWORD', 'new_password' );
define( 'DB_HOST', 'localhost' );

Save the file. Refresh the temporary your-site.growhost.in URL. If you see your WordPress site (even if some images are broken or links go to the old URL), the database is connected and the migration is fundamentally working. Don't worry about broken links yet — that's the next step.

Step 5: Pre-cutover test with /etc/hosts

This is the step everyone skips and then regrets.

Before you flip DNS for real, you want to pretend the DNS has already flipped, just on your own laptop, so you can verify the site works on the new host under its real domain name.

On macOS or Linux, edit /etc/hosts (you'll need sudo). On Windows, it's at C:\Windows\System32\drivers\etc\hosts.

Add a line like:

203.0.113.42  yourdomain.in www.yourdomain.in

Replace 203.0.113.42 with the IP address growhost gave you for the new server.

Save the file. Now when you visit yourdomain.in in your browser, your computer is sending you to the new server, but the rest of the internet still sees the old one. This means you can browse the site, test forms, click around, log into wp-admin — all on the new host, under the real domain, with zero risk to public traffic.

Spend 10 minutes here. Check:

• Homepage loads
• 2-3 inner pages load
• Contact form submits successfully
• wp-admin is accessible and you can log in
• Images load (this catches /wp-content/uploads path issues)

If anything is broken, fix it before the next step. Once DNS is live, fixing things gets stressful because real users are landing on the broken thing.

Step 6: Flip DNS for real

Go back to your registrar. Update the A and AAAA records on your apex domain and www subdomain to point to the new server IP. Save.

Because you dropped TTL to 300 seconds yesterday, propagation will be done within 5-10 minutes for almost everyone. Use dnschecker.org to watch propagation across regions in real time.

Now remove the /etc/hosts override on your laptop — you don't need it anymore, and leaving it can cause confusion later.

Step 7: Issue the SSL certificate

Once DNS has propagated, log into your growhost dashboard. The control panel should auto-issue a free Let's Encrypt certificate for your domain. If you're on a plan that uses cPanel, navigate to SSL/TLS Status and click Run AutoSSL if it hasn't run yet.

Visit https://yourdomain.in and confirm the padlock icon appears. If you get a "not secure" warning, the certificate may still be issuing — give it 5 minutes and refresh.

Step 8: Watch for 48 hours

Keep the Hostinger account live for at least seven days. Monitor Google Analytics (or your analytics tool) for any 404 spikes or traffic drops, both of which can indicate something didn't migrate cleanly. Check your contact form's notification email is still arriving.

After seven trouble-free days, cancel Hostinger. Save the cancellation confirmation email.

The list of things to verify after migration

A quick checklist for the post-cutover sanity check.

1. Site loads on https with a valid SSL certificate
2. wp-admin login works and password resets work
3. Permalinks resolve (Settings > Permalinks > Save flushes rewrite rules)
4. Contact forms submit and notification emails arrive
5. Search Console (if connected) shows no spike in crawl errors after 24 hours
6. Site speed (use PageSpeed Insights) is at least as good as before, ideally better
7. All images load correctly across multiple pages
8. Any membership / e-commerce / LMS plugin's login flow still works

If all eight items pass, you're done. Total time invested: 30 to 60 minutes of active work, plus a day of monitoring.

The point of this whole exercise, of course, is to land somewhere that doesn't triple your bill in year 2. That's the entire pitch behind our pricing: the price you sign up at is the price you renew at. We are not trying to be the cheapest in year one. We are trying to be the cheapest by year three. The renewal math is the math that matters.