Shared hosting works quietly until the moment it does not. Another tenant’s traffic spike eats your CPU allocation, a plugin crosses the memory ceiling, and support responds with “upgrade your plan.” Moving to a VPS resolves the resource contention, but the migration itself is where most site owners lose a weekend or, worse, take a live storefront offline. The process below is the same five-phase sequence used for small WordPress and custom sites, and it takes two to four hours of hands-on time if you prepare properly.
Before the first phase, decide what “done” looks like. A migration is not finished when the site loads on the new server – it is finished when DNS has propagated everywhere, the old host is still available as a fallback, and you have run a real transaction or form submission end to end on the new box. Setting that bar up front prevents the most common failure mode, which is declaring victory after seeing only the homepage render.
The reason to migrate at all is usually cost-per-resource rather than absolute price. A shared plan at $8/month gives you a fraction of a CPU core and no root access; a $6-$12 VPS gives you dedicated vCPU allocation, root, and full control over caching and the web server. For sites with real growth plans, the VPS is frequently cheaper per unit of actual capacity. Sizing that correctly is the first phase – our VPS comparison table maps plan tiers to realistic workload ceilings, which saves guessing at the provision step.
Phase 1: Size and inventory the current site
- Record current disk usage, database size, and peak concurrent visitors from your analytics.
- List every cron job, email account, DNS record, and subdomain the site depends on. Migrations fail on the details people forget to enumerate.
- Add 40% headroom to disk and RAM figures for growth and logs.
- Pick a plan with NVMe storage and at least 2 GB RAM for a typical WordPress site with caching enabled.
Phase 2: Lower TTL and stage the copy
Start 24-48 hours before cutover. Drop the DNS TTL on your A record to 300 seconds so the switch propagates quickly. Then take a clean copy: a database dump, a full file archive, and a note of the PHP and MySQL versions currently in use. Doing this early means you are copying a stable site rather than racing a live one later, and it gives you a rollback artifact if anything goes wrong.
Phase 3: Provision and harden the VPS
Build the server before touching the data. Create a non-root sudo user, disable password authentication for SSH, enable a firewall allowing only ports 22, 80, and 443, and install fail2ban. Install your web server, PHP-FPM, and database engine at the same major versions as the source site to avoid incompatibility surprises. Enable automatic security updates. This hardening takes about 20 minutes and prevents the most common VPS compromise scenario, which is an exposed SSH port with password login enabled.
Phase 4: Transfer and test before DNS moves
Import the database and files, then update the site URL in the database if the domain configuration requires it. The critical step is testing before the public switch: temporarily edit your local hosts file to point the domain at the new server’s IP, and browse the site as a visitor would. Check the homepage, a deep page, a form submission, login, and any checkout flow. Fix broken paths and permissions now, while your live site is still serving traffic from the old host.
Phase 5: Cut over, then verify and roll back if needed
Update the A record to the new IP, then watch three things for the first hour: response time, error logs, and whether any request still hits the old server. Keep the old hosting active for at least a week so rollback is a DNS change rather than a rebuild. Restore the original TTL value once you are confident, and only then cancel the old plan.
| Phase | Time | Rollback cost if rushed |
|---|---|---|
| Size and inventory | 30 min | Wrong plan, immediate re-migration |
| Lower TTL and copy | 30 min + 24h wait | Slow propagation, stale cache |
| Provision and harden | 45 min | Exposed server, compromise risk |
| Transfer and test | 45 min | Broken checkout on go-live day |
| Cut over and verify | 30 min | Downtime with no fallback |
The discipline that makes this work is sequencing. Test on the new server before DNS moves, and keep the old host alive as insurance. Done in that order, the migration costs you an evening of preparation rather than a weekend of recovery.
Before you start, compare hosting plans side by side so the plan you provision matches the headroom you calculated in phase one, and check that the provider allows the PHP and database versions your site already runs.
Related Articles：
Buying Cheap VPS Hosting Safely: 5 Data-Driven Checks Before You Pay
Cloud VPS vs Regular VPS: Five Differences That Actually Change Your Bill
Cheap VPS Hosting in the US: Real-World Performance Benchmarks at $3–$20/Month (2026 Data)
VPS vs Shared Hosting for Budget-Conscious Site Owners: When to Upgrade and What You Gain
