How to migrate a website to a new host without downtime

The principle

Never move a site. Copy it, verify the copy, then redirect traffic. At no point should there be only one working version.

Every migration horror story starts with someone doing it in the other order.

Before you touch anything

• Take a full backup and download it to your own machine. Not to the old host, not to the new one — somewhere neither can lose.
• Write down what exists. Every domain and subdomain, every email account, every cron job, every DNS record, every SSL certificate, every database. The inventory is where the forgotten items get caught.
• Note your current DNS TTL. You will need it in step four.
• Check your PHP and MySQL versions so the new host matches. A site on PHP 7.4 will not necessarily start on 8.3.

Step 1 — Copy everything to the new host

cPanel to cPanel is the easy case: a full account transfer moves files, databases, email accounts, cron jobs and DNS zones in one operation. Otherwise, move each by hand:

• Files, over SSH or FTP, preserving permissions.
• Databases, as a mysqldump restored on the other side.
• Email accounts and their mailboxes — see the warning below.
• Cron jobs, copied out of crontab -l.
• Any .htaccess rules, redirects and custom server config.

Step 2 — Test on the new host before DNS moves

Two ways to reach the new server while the domain still points at the old one:

• A hosts-file entry on your own machine, mapping the domain to the new IP. Your browser sees the new site; the rest of the world does not.
• A preview URL or a temporary subdomain, which most hosts provide.

Then actually test: the homepage, a deep page, a form submission, login, checkout if you have one, image loading, and the 404 page. Click as a customer would, not as someone hoping it works.

Step 3 — Sort SSL out now, not after

Issue a certificate on the new host before cutover. Let's Encrypt can validate over HTTP once DNS points at the new server, so on a well-run host this happens automatically within minutes of the switch — but confirm it rather than assume it. A browser security warning on cutover day undoes a lot of goodwill.

Step 4 — Lower the TTL a day ahead

TTL tells resolvers how long to cache a record. If yours is 86400 seconds, some visitors will keep hitting the old server for a day after you switch.

At least 24 hours before the move, set the TTL on your A and MX records to 300. Wait for the old TTL to expire, then make the change. Most resolvers will pick it up inside five minutes.

Step 5 — Switch, at a quiet hour

Update the A record — and the MX records, if mail is moving too — to the new IPs. For an Indian audience that means late evening or early morning IST. Keep both servers running.

Watch for an hour: check the site resolves to the new IP, that SSL is valid, that a form arrives, and that the new server's error log is quiet.

Step 6 — Wait a week, then cancel

Keep the old hosting for at least seven days. It costs one month of a cheap plan and it is the only real rollback you have. Restore the TTL to a normal value once you are settled.

The four things people forget

Email

The one that causes real damage. Moving MX records without moving the mailboxes means mail arrives at a server with no accounts on it and bounces. Create every account on the new host first, copy the mailboxes with IMAPsync, then move MX. Warn users that mail may arrive in either place for a few hours.

Cron jobs

Silent when missing. The site works perfectly and the nightly backup, the invoice run and the feed import simply stop. Copy crontab -l before you leave, and verify each job has run once on the new server.

DNS records that are not A or MX

SPF, DKIM, DMARC, TXT verification records for Google or Microsoft, CNAMEs for a CDN or a help desk, SRV records. Export the whole zone rather than transcribing the records you remember.

Search engines

If URLs change — and they should not, in a host migration — set up 301 redirects before anyone notices. Afterwards, check Search Console for a crawl-error spike, and resubmit sitemap.xml.

WordPress in particular

Do not use a migration plugin if you can help it; copying files and the database directly is faster and does not leave plugin artefacts. Afterwards, update the site URL if it changed, flush permalinks by re-saving the permalink settings, and check wp-config.php for the new database credentials.

Or let someone else do it

We migrate free on every plan, including VPS and dedicated, and we do it non-destructively: we copy, you test, we cut over when you say so, and nothing at the old host is deleted until you confirm. Typical downtime is under five minutes, at a time you pick.

Send the details to support@bigdomainhost.com or call +91 75994 50220.