From shared hosting to VPS — the migration playbook we now give every client

The client was a real estate portal with about 900 property listings, a contact form on every listing page, and a Google Ads campaign driving about 400 sessions per day. They were on a shared hosting plan that cost them ₹2,400 per year. Their site took 8 seconds to load on a good day. During peak traffic, pages sometimes did not load at all.

We had the same conversation we have had with several clients: shared hosting is fine for low-traffic brochure sites with no transactional value. If you are running ads to a site and every second of load time costs you money, you should not be on shared hosting.

Moving them to a managed VPS took four hours and cost them ₹1,800 per month more than what they were paying. Their LCP went from 7.8 seconds to 1.4 seconds. The conversation rate on their landing pages improved. The VPS paid for itself in the first week.

The migration process

We do every migration in a fixed sequence and we do not skip steps. First, full backup of the existing site including database, uploads, and all files. We store this in three places before we touch anything on the new server. Second, new server provisioning, installing the stack we standardized on: Nginx, PHP 8.1 or 8.2, MariaDB, Redis, SSL. We use a baseline server config that we have tuned for WordPress specifically.

Third, we set up the site on the new server without making it live. We update the hosts file on our own machines to point to the new server IP and test everything, the site, admin, forms, checkout if there is one, page speed. We find problems at this stage, not after go-live.

Fourth, go-live. We update DNS with a low TTL 24 hours before the migration window. During the migration window itself, we put the old site into maintenance mode, do a final database export, import to the new server, update DNS to the new IP, and then monitor for 30 minutes. The maintenance window is usually under 10 minutes.

What clients get wrong about this

The most common mistake is not testing the new environment before going live. People migrate to a new server, flip DNS, and then discover that a plugin that worked on shared hosting does not work on the new stack, usually because of PHP configuration differences or directory permissions. Test first, always.

The second mistake is not having a rollback plan. Before we flip DNS, we know exactly how to roll back if something breaks. The old server stays up until we are confident. You need a plan for what to do if it does not work, not just a plan for what to do when it does.