How to move your website to cloud hosting in India, safely

Plan the move before you touch anything

Write down what is moving: the domain, the site files, every database, any scheduled tasks, environment settings for apps, and where email is hosted. Email is often hosted somewhere else — moving the website should not move email, so leave the MX records alone unless you mean to change them.

Then check where the domain actually points today. We have found domains whose live site was already elsewhere while an old copy sat on the host being cancelled; moving the wrong copy loses months of changes.

Take a full backup — and download it

Before anything else, take a full backup of the old site: files, every database, and any configuration that lives outside the web folder. Download it to your own computer. If anything goes wrong in the move, this is the copy you return to.

Copy and clean

Copy the files and import the databases into the new account. This is also the moment to leave rubbish behind: old backup archives in the web folder, database dumps anyone could download, and files that should not be there. When we move sites, we scan them first and do not copy planted scripts — random-named PHP files, web shells and search-engine cloaking rules are more common than people expect.

For WordPress, a clean core of the same version replaces the old one, and the configuration gets a new database password and new security keys.

Test before DNS changes

Test the new copy before visitors see it. Open the site against the new server's IP address (your hosts file, or a temporary address), click through the main pages, sign in to the admin, submit a form and place a test order. Compare the pages with the live site. Nothing should be different except the speed.

Switch DNS with little or no downtime

A day before, lower the TTL on the domain's A record to a few minutes so the change spreads quickly. When you are ready, change the A records for the domain and www to the new server's IP address. Visitors move over as their DNS caches expire. If you use Cloudflare, you can keep proxying on; use SSL mode Full while the new certificate is issued, then Full (strict).

• Lower the TTL a day before
• Point @ and www at the new IP
• Leave MX and email records untouched
• Issue free SSL once DNS points to the new server

Catch up on anything that changed

Between the copy and the DNS switch, the old site may have taken orders, bookings, comments or sign-ups. Compare the old database with the new one and bring across anything new before you close the old account. For busy stores, freeze changes for the hour of the switch or copy the database again right after it.

After the move

Check the site over HTTPS and turn on "Always use HTTPS". Test forms and payments again. Watch the access and error logs for a day. Then take a fresh backup on the new host, download it, and only then cancel the old account. Keep the old host's final backup somewhere safe for a few months.

Special cases: stores, apps and email

Online stores and booking sites take new data all the time, so the database changes between the copy and the DNS switch. For these, plan a short change freeze — or copy the database a second time immediately after the switch — and compare order numbers on both sides before closing the old account. Apps built on Node.js, Python or Java move with their code, their environment variables and their scheduled tasks; check that the app starts on the new server and that background jobs run before you switch.

Email is the most common accident. Moving the website does not require moving email. If your mail is with Google Workspace, Microsoft 365 or another provider, leave the MX, SPF, DKIM and DMARC records exactly as they are, and change only the A records for the website.

A rollback plan, just in case

Before you change DNS, write down the old A record values and keep the old account running. If something unexpected appears after the switch — a payment page that fails, a missing upload folder — you can point the A records back within minutes while you fix it, and visitors return to the old site as caches expire.

Once the new site has run cleanly for a few days, take a fresh backup on the new host, download it, and only then close the old account. Keep the old host's final backup somewhere safe for a few months in case a forgotten file turns up later.

A short timeline

For a typical business site the move fits in two or three days. Day one: plan, take and download the backup, set up the new account. Day two: copy, clean, test on the new server, lower the TTL. Day three: switch DNS at a quiet hour, issue SSL, check everything, and copy any late orders or comments across. The old host stays available for a week as a safety net.

Checking the old host for problems first

Older hosting accounts often carry things nobody remembers: test copies of the site, abandoned installs in sub-folders, old backups in the web folder, and sometimes files planted by an attacker years ago. Moving them across moves the problem with them. Before copying, list the folders, look for files with random names or recent dates you cannot explain, and scan for known malware patterns.

When our engineers move a site, we copy only what the site needs, install a clean copy of WordPress core of the same version where it applies, check files against published checksums and leave planted files behind. We tell you what was found, so you can change passwords that may have been exposed.

After the move

Once the site is live on the new host, finish the details. Submit the sitemap in Google Search Console if it changed, check that the site still appears correctly in search results, and watch the error log for a few days. Update any contact pages or scripts that mention the old server. Then take a fresh backup on the new host, download it, and keep it alongside the old host's final backup.

Key takeaways

The short version, for anyone skimming:

• Confirm where the domain really points before you start.
• Take and download a full backup first.
• Leave planted files and exposed backups behind; clean while you copy.
• Test on the new server before switching DNS; lower the TTL first.
• Copy late orders and comments across before closing the old account.