Moving a WordPress Site to New Hosting in India: A Low-Downtime Checklist

Moving a WordPress site to a new host is mostly a copying job. The risk sits in the gaps: orders placed while the database is being copied, email that stops when DNS changes, and visitors who still reach the old server for hours.

This checklist is for small businesses and website owners in India moving a WordPress site to Z.com hosting while keeping the live site, email and checkout working.

Executive summary

Quick answer

What "low downtime" really means

Downtime during a host move usually comes from DNS, not from copying files. DNS resolvers cache your domain's records for the time set in the TTL (time to live). Z.com's DNS guidance notes that updated records can take up to 48 hours to spread, and that some internet providers ignore TTL values. For a while, some visitors reach the old server and others reach the new one.

That split is harmless only if both servers hold the same data. For a store or booking site, anything written to the old database after your copy will be missing on the new server, so the checklist includes a content freeze and a final database re-export. For background on how caching works, see Z.com's DNS propagation overview.

Before you start: preparation checklist

• Inventory what you are moving. List WordPress files, the database, media uploads, email accounts, redirects, scheduled tasks and custom configuration. Note your PHP version and active plugins.
• Check plan fit. Z.com's site transfer page says the staging subdomain step is available on the Personal and Business shared plans, not on Starter or free hosting. Confirm eligibility on the site transfer page before you buy.
• List services tied to your server. Payment gateways, GST invoicing tools, courier plugins, SMS or WhatsApp widgets and security plugins may use webhook URLs or IP allow-lists. Ask each provider whether a hosting change affects them.
• Check server location if it matters. Z.com's hosting page does not list a data centre city. If latency for customers in India or data-protection planning matters, confirm with Z.com first; the US storefront does not make a site locally hosted in India. Our DPDP guide for Indian small business websites covers the privacy side.
• Pick a cutover window. Use your analytics to find the quietest hours in India Standard Time (IST). Avoid sale days and festive campaigns, which our Diwali website checklist covers.
• Lower the DNS TTL. If you will edit records at your current DNS provider, lower the TTL on the A record (and any AAAA) to about 300 seconds at least one old-TTL period ahead. This does not shorten a nameserver change (see step 11).
• Take a full backup and store it off the server. Download files, a .sql database export and any hosted mail data to your computer or cloud storage.

Step-by-step migration checklist

1. Back up the old host. Download the WordPress directory (often public_html), export the database as a .sql file and back up the mail folder if mailboxes are hosted there. Label each file with the date.
2. Add your domain to Z.com. Z.com's transfer page says to choose the option for a domain you already own. Adding it does not affect your live site until you change DNS.
3. Upload the files. Upload the site over FTP and extract it in the new site's directory. Z.com's guide to uploading website contents via FTP shows how.
4. Create the database and import it. In cPanel, create a database and a user with privileges, then import the .sql file in phpMyAdmin. Z.com's database migration guide says files under 64 MB can be imported this way, larger ones must be split, and a database cannot be renamed after creation.
5. Update wp-config.php. Enter the new database name, user and password. The official WordPress guide to moving a site lists this as a required step when credentials change.
6. Decide how email moves. If mail stays external, keep its MX and TXT records, recreate them in any new DNS zone, and check cPanel email routing still sends mail to the external provider. If mailboxes move, create each on Z.com first, then restore the mail data. Z.com's email import guide applies when the old provider also uses cPanel.
7. Preview before DNS changes. Use a hosts-file entry on your computer, as described in Z.com's hosts file guide, or the staging subdomain if your plan includes one. Our staging site guide explains safe testing habits.
8. Test the copy. Work through the verification table below while the old site is still live.
9. Freeze and re-sync. Switch off all writes on the old site and keep them off. Re-export and re-import the database and copy new media uploads. If mailboxes are moving, copy mail once more before it reaches Z.com; Z.com's import guide overwrites the mail folder.
10. Check HTTPS for the production hostname. Confirm a certificate covers the bare domain and www. Z.com's hosting page says its free SSL may need Z.com's nameservers, so it may appear only after DNS points to Z.com; timing is not documented, so ask Z.com support. If not ready first, test HTTPS after the change.
11. Switch DNS. Z.com's transfer page recommends changing nameservers; updating A records is the alternative. If you edit records at your DNS provider, point A (and any AAAA) to Z.com; your lowered TTL applies. A nameserver change ignores that TTL, since Z.com's DNS page says it must be reflected higher up in the DNS hierarchy. If mailboxes are moving, switch MX after the pre-cutover copy. Verify that the MX target resolves to the intended mail server. First make sure the new zone holds every record you need, including TXT and the intended MX, and handle any DNSSEC DS record at your registrar: if you remove it, wait for its cached TTL to expire before changing nameservers, or validating resolvers may reject the domain, then re-enable DNSSEC with the new DS record (or follow your DNS provider's migration steps). Our SPF, DKIM and DMARC guide explains the email records.
12. Reopen, monitor, then retire the old host. Once your network resolves to Z.com, remove your hosts-file entry, confirm HTTPS, forms, a test order and GST invoices, then reopen orders there only. Check DNS from several networks, including mobile. If mailboxes moved, test delivery both ways after the MX change and copy late old-host mail message by message, because the import guide's method overwrites new mail. Retire the old hosting only when its traffic and mail logs are quiet and the final sync is done, not merely after 48 hours.

Cutover day plan

On the day, start inside your quiet IST window, announce a short maintenance notice if you run a store, and switch off old-site writes before the final database copy.

Keep the old hosting active but closed to writes through the overlap. If you roll back, stop writes on the new site first, then reconcile everything it accepted (orders, bookings, form entries) into the old database before pointing DNS back and reopening the old site.

What to verify after the switch

If the padlock is missing or shows a warning, check the certificate covers the bare domain and www, fix http:// mixed content, and contact Z.com support if none is issued once DNS points to Z.com.

Common mistakes to avoid

Frequently asked questions

Key takeaways