How to Move Your Website to Hostinger Without Downtime

Disclosure: we are a verified Hostinger partner. The Hostinger links in this article are referral links, and we earn a commission if you sign up through one. Your price is the same either way, and nothing below is written differently because of it.

Nearly every website migration that goes wrong goes wrong for the same reason: somebody pointed the domain at the new server before the new server was properly ready. Do it in the right order and a migration is invisible. Visitors keep seeing the old site right up until the new one is serving correctly, then they see that instead, and nobody notices the moment it changed.

Before you touch anything

• Take a full backup of the current site — files and database — and download it somewhere off the server. Not a backup plugin's copy sitting on the same disk.
• Write down your DNS records. Screenshot the zone. You will need the MX records for email especially, and losing those is how a migration takes the company's mail down.
• Lower your DNS TTL to 300 seconds at least a day before the move. This is the step people skip, and it is the difference between a switch that propagates in five minutes and one that drags on for two days.
• Note your PHP version and any server-level settings the site depends on.

Step 1: build it on the new host first

Upload the files and import the database to Hostinger while the domain still points at the old host. Nothing is live yet. Set the PHP version to match, install the SSL certificate, and get the site running there completely.

Step 2: test it properly, before DNS

You can reach the new site before the domain moves, either through a temporary URL or by editing your own machine's hosts file so only you resolve the domain to the new server. Then actually test:

• Every top-level page loads, and so do a handful of deep ones.
• Forms submit, and the email genuinely arrives.
• If there is a shop, complete a test order end to end.
• Images resolve. Broken paths after a migration are extremely common.
• The admin logs in and saves changes.

Step 3: switch DNS, last

Only now do you point the A record at the new server. With a low TTL set in advance, most visitors move across within minutes. Leave the old hosting active for at least a week afterwards. It costs one more month and it is your fallback if something surfaces on day three.

Step 4: the hour after

• Force HTTPS and confirm there is exactly one address per page: one host, one protocol, no trailing-slash twin.
• Submit the sitemap again in Google Search Console and watch the coverage report for a fortnight.
• Send a test email from the site and from a mailbox, and check it does not land in spam. SPF, DKIM and DMARC records need to follow the mail, and this is the most commonly forgotten part of a move.
• Run a speed test and compare it against the numbers you took before.

The three mistakes that cause most outages

1. Switching DNS first and fixing the site afterwards, in public, while it is down.
2. Forgetting MX records, which takes email down even when the website is perfect.
3. Cancelling the old hosting immediately. Keep it a week. It is the cheapest insurance in this whole process.

Doing it yourself, or not

If you are comfortable with DNS and databases, the above is a genuinely manageable afternoon. If the site earns money and you would rather not be the person holding it, we do Hostinger migrations as a fixed-scope service: staged, tested, switched, and monitored for a week afterwards.