How to Migrate From Shared Hosting to a Cloud Server Without Downtime

Most hosting migration horror stories share the same root cause: someone changed DNS before the new server was actually ready, or forgot email was hosted alongside the website and broke it silently for a week. None of that is necessary. A shared-hosting-to-cloud-server migration in Nepal, done in the right order, causes zero visible downtime and zero lost email. Here's the sequence we use.

Step 1: Set Up the Cloud Server Fully Before Touching DNS

Provision the new cloud server, install the same stack your site needs (PHP version, MySQL, any specific extensions), and get the site fully working there first, accessed by its temporary IP address or a test subdomain. Nothing about your live site changes yet. This is also where you right-size resources — check current shared hosting resource usage in cPanel first so you're not guessing at RAM and CPU needs on the new server.

Step 2: Migrate the Database and Files, Then Test Thoroughly

Copy the full file structure and export/import the database. For WordPress sites, update the `wp-config.php` database credentials to match the new server; for custom applications, update the relevant `.env` or config file. Test everything on the temporary URL: forms submitting correctly, images loading, checkout working if it's a store, admin login functioning. This is the stage to catch problems, while the live site is still untouched on the old host.

Step 3: Handle Email Separately (This Is Where Most Migrations Break)

If your business email runs through the same hosting account, plan its move independently. Either migrate mailboxes to the new server's mail service or, cleaner for most Nepali businesses, move email to a dedicated business email service so hosting migrations never touch email again. Confirm MX records and mail client settings before you touch anything else.

Step 4: Lower DNS TTL 24-48 Hours in Advance

Before cutover day, lower your domain's DNS TTL (time to live) to something short, like 300 seconds, through your DNS management panel. This makes the eventual switch propagate in minutes instead of the default 24-48 hours some registrars use, which is where most "downtime" during migrations actually comes from — not the migration itself, but slow DNS propagation.

Step 5: Cut Over and Verify Immediately

Point your domain's A record to the new cloud server's IP address. Within minutes, most visitors will resolve to the new server. Immediately check the live domain: SSL certificate active, site loading correctly, forms and checkout working, email flowing if it moved too. Keep the old shared hosting account active and untouched for at least a week as a fallback, don't cancel it same-day no matter how confident the migration went.

What This Protects You From

SEO rankings survive this because the URL structure and content don't change, only where they're hosted; Google doesn't penalize a same-domain hosting move. The real risks are self-inflicted: cancelling the old account too early, forgetting email lived there too, or cutting over before the new server was actually tested. Follow the order above and none of those happen.

WebsNP handles this exact migration for free when you move to one of our cloud server plans — our team does the file transfer, database move, and DNS cutover for you, scheduled at a low-traffic time, with the old host kept live as a safety net until you confirm everything works. Message us on WhatsApp with your current hosting details and we'll tell you honestly whether cloud is the right move yet.