How to migrate a website to a new host with low downtime

The principle: build first, switch last

A low-downtime migration is simple in outline. You build a working copy on the new host while the old site carries on serving visitors, test it privately, and only then change DNS. During the switch, the old and new sites both work, so visitors reach one or the other. Most trouble comes from doing this out of order, or cancelling the old hosting too early.

Moving hosting and moving a domain are separate jobs. You can change where a website is hosted without transferring the domain, and it is best not to do both at once. Transfer the domain afterwards if you want to.

If you are moving to a hosting plan with us, migration of website files, databases and email accounts is included. Raise a ticket after checkout, share the old panel access, and we will schedule it. The steps below are still useful for understanding the process or doing it yourself.

Step 1: Take stock and back up

Write down everything the old host provides, because the things people forget are the things that break a day later:

• Domains, subdomains and redirects, plus the PHP version and extensions in use
• Databases, and which site uses which one
• Mailboxes, forwarders and where mail is actually hosted
• Cron jobs, and any custom settings in .htaccess or php.ini
• A copy of every DNS record: A, CNAME, MX, TXT, including SPF, DKIM and DMARC
• A full backup of files and databases, downloaded to your own computer

Step 2: Lower the DNS TTL

TTL tells DNS resolvers how long they may keep an answer before asking again. If your record has a TTL of 14400 seconds, some visitors may keep seeing the old server for up to four hours after you switch. So 24 to 48 hours before the cutover, or at least as long ahead as the current TTL, lower the TTL on your A, CNAME and MX records to 300 seconds. Do this at wherever your DNS is currently hosted.

This only works for records. A change of nameservers is controlled by the registry’s own TTL, which you cannot lower, so it takes longer to spread. If you can, keep the nameservers and change only the A record during the cutover.

Step 3: Restore on the new host

Add the domain to the new account and set the same PHP version as the old one. Upload the files, for example as a ZIP in File Manager, then extract them in the site’s folder. Create a database and user, import the SQL file with phpMyAdmin, and update the site’s configuration file with the new database details; in WordPress, that is wp-config.php. A full cPanel backup generally needs an administrator to restore in one piece, so on shared hosting restore home folder and database backups separately.

WordPress owners can use a migration plugin such as Duplicator, which packages the site and database into one file. Since the domain is not changing, you should not need to search and replace any addresses.

Step 4: Test privately with your hosts file

Your computer can be told to use the new server for your domain, while the rest of the world still reaches the old one. Add a line to your hosts file with the new server’s IP address followed by your domain names. On Windows, open Notepad as administrator and edit C:\Windows\System32\drivers\etc\hosts, then run ipconfig /flushdns. On macOS or Linux, edit /etc/hosts with sudo. The line looks like the example below, with your own IP and domain.

Browse the site thoroughly: home page, inner pages, login, forms, checkout, image uploads. A certificate warning is normal at this point, because the new server may not be able to get a certificate until DNS points to it. Remove the line when you finish, or you will not see what real visitors see.

• 203.0.113.10 yourdomain.in www.yourdomain.in

Step 5: Cut over

Pick a quiet time at the start of a working week. Tickets are answered Monday to Friday, 10:00 to 19:00 IST, so a Friday-night switch leaves you alone with any problems until Monday. Then proceed as follows:

• Put the old site in maintenance mode, or stop publishing and taking orders, so that nothing new is written to the old database
• Export the database once more, and import this final copy on the new host
• Copy across any files uploaded since the first backup
• Change the A records for the root and www to the new IP address
• If you must change nameservers, first recreate every DNS record on the new nameservers, since records do not travel with the change
• Check the new address with an online DNS checker, or nslookup yourdomain.in
• Confirm that SSL has been issued on the new server, and test the live site again

Step 6: Handle email separately

If your mail is with a separate service such as Google Workspace or Titan Mail, leave it alone. Keep the MX, SPF and DKIM records exactly as they are, and take care that they exist on the new nameservers if you change those. Forgetting this step is the classic way a website migration takes email down with it.

If mailboxes live on the old hosting, create the same addresses on the new host, with passwords, before the switch. Copy old mail across using IMAP sync, either with a tool such as imapsync or by adding both accounts to an email client and dragging folders. Change the MX records at cutover and update SPF if the sending server has changed. For a few days, also check the old mailboxes for mail delivered by servers still holding the previous records, and move it over.

Step 7: Watch, then tidy up

Keep the old hosting active for at least a week, and do not delete anything. It is your fallback: if something serious appears, point DNS back at the old IP address while you fix it. Test forms, scheduled tasks and outgoing mail, and check Search Console and your error logs. Recreate cron jobs on the new host and confirm that backups are running there.

Once all is stable, raise the TTL back to a normal value such as 3600 seconds, take one final backup from the old host and only then cancel it. Check its renewal date ahead of time, so you are not billed for another term while waiting.