Reference guide · migration-hosting · Published 2026-08-16 · 4 min read
Shared, VPS, and dedicated hosting tradeoffs
Compare shared, VPS, cloud and dedicated hosting for a migration: cost, isolation, root access, and when each choice stops scaling.
- ·The four tiers
- ·When each fits
- ·Pick for migration
Choosing a hosting tier is usually the first decision in a migration, and the four common options shared, VPS, dedicated, and cloud overlap enough to confuse. The real differences are isolation, root access, elasticity, and who is responsible for the operating system. Understanding the tradeoffs keeps you from overpaying for a server you do not manage, or migrating to a shared plan that cannot run what you just bought.
The four tiers
- Shared hosting. Dozens of accounts on one physical server sharing CPU, memory, disk and a PHP-FPM pool. It is cheap and has a control panel, but a noisy neighbour can slow your site, and you cannot run custom binaries or tune the stack. Good for small, low-traffic, plugin-driven sites.
- VPS hosting. One physical server divided into virtual machines, each with a guaranteed slice of resources and its own full operating system you can reboot, log into as root, and configure. More isolation and control than shared, but you manage updates, security and the web stack yourself unless you buy managed VPS.
- Dedicated hosting. A whole physical machine to your account. Maximum resources and control, no noisy neighbours at the hardware level, but fixed capacity, higher cost, and the fullest management burden. For sustained heavy, steady, or regulatory workloads.
- Cloud hosting. Virtual machines and services (compute, databases, object storage) provisioned on demand, billed per use, with snapshots and scaling. Elastic and ideal for unpredictable traffic, but the flexibility comes with a steeper learning curve and itemised cost that can be hard to forecast.
The tiers are not a strict ladder. Cloud and VPS both run on virtual machines and differ mostly in billing and tooling; a managed cloud plan can be easier to run than a self-managed VPS.
When each fits
Use the split table as a rough guide:
| Need | Fit | Tradeoff |
|---|---|---|
| Low traffic, wants a panel, budget small | Shared | Little control, shared CPU |
| Fixed workload, needs root, keeps costs flat | VPS | You run security and updates |
| Sustained high, steady traffic or compliance | Dedicated | Fixed cost, no elasticity |
| Spiky or seasonal traffic, wants snapshots | Cloud | Variable billing, more tooling |
The important signal is isolation under load. When your steady state approaches the shared plan's CPU quota or its PHP memory limit, that is the moment the shared tier stops being correct, regardless of price.
Pick for migration
When choosing for a migration, weigh the future workload, not the current one, because the migration cost repeats if you outgrow the tier within a year. That repeated cost is why the majority of "upgrade within six months" complaints start with a slightly too-small shared or VPS pick.
- Migrate to a tier you can administer. Buying a bare VPS you never log into leaves updates and hardening undone, which cultures a different risk than shared hosting's managed panels. A managed VPS or managed cloud plan usually fits a one-person operation better than an unmanaged box.
- Match CPU and memory to the demand. Use the hosting SLA article to add availability expectations, and the upgrade plan article for how to scale smoothly when a tier begins to run out.
- Keep the migration path open. The tier you pick sets the export and import tooling. A panel-equipped shared plan and a root VPS produce different backup and restore workflows, so confirm the new tier can import your existing dump and file structure before you move.
Whatever you choose, the migration operation itself is the same discipline: stage, test, cut over and keep the rollback plan ready. The tier changes the budget and the controls, not the need to verify the new destination before you point production traffic at it.