Shared Hosting to VPS: Sizing and Migration Planning

Moving a live website from shared hosting to a VPS looks scary the first time, but it does not have to mean outages, broken emails, or SEO drops. Resource planning, traffic analysis and a structured migration plan can reduce disruption. Common reasons to move include CPU throttling, memory errors, slow admin panels, or limits on background jobs and custom services. This guide covers sizing, server preparation and migration sequencing to minimise downtime. Keeping purchases and logins available throughout also requires a plan for changing data and sessions; DNS changes alone do not ensure uninterrupted service. If you are currently on shared hosting and wondering whether you can upgrade your infrastructure without breaking your site, this article is for you.

Why Move from Shared Hosting to a VPS?

Before planning the migration, it is worth being clear about why you are moving and what you expect from the VPS.

Shared hosting means dozens or even hundreds of customers share the same server resources. It is affordable and convenient, but it also comes with strict limits and less control. A VPS (Virtual Private Server) provides a virtual server with allocated CPU, RAM, disk and networking resources. Root access, resource guarantees and configuration freedom depend on the plan and management model.

Typical reasons for moving from shared hosting to a VPS include:

• Performance bottlenecks: Slow TTFB, admin panels timing out, or “resource limit reached” errors during traffic spikes.
• Need for custom software: Background workers, queues, search engines, Node.js processes or custom daemons that your shared hosting plan may not permit.
• Security and isolation: Stronger separation from other customers, OS-level firewalls, custom security hardening and the freedom to choose your own stack.
• Predictable scaling: Options to upgrade vCPU, RAM or disk as your business grows; confirm the plan’s upgrade limits and any required downtime.

If you want a friendly comparison of hosting types, including where shared hosting ends and VPS really starts to shine, you can also read our article “The Friendly, Real-World Comparison of Web Hosting Types”.

Step 1: Analyse Your Current Usage on Shared Hosting

A low-disruption migration starts with knowing what you are running today. Guessing VPS specs risks either overpaying or hitting new limits after the move.

Measure real CPU, RAM and I/O usage

Look in your hosting panel for “Resource Usage” or “CPU and Concurrent Connections” charts. Availability depends on the host’s configuration; if these are absent, ask the host for usage and limit data. Over a 7–30 day window, look for:

• CPU: How often do you hit 100% of your allowed CPU? Are there clear peaks around campaigns, newsletters or specific hours of the day?
• Memory (RAM): Check for memory faults or “limit reached” messages. This helps estimate what your PHP workers and database actually need.
• I/O (disk throughput): Spikes during backups, imports, exports or image-heavy pages are worth investigating. Faster storage may help if disk performance is the bottleneck, but a spike alone does not establish that.

If you often see “resource limit reached” or similar errors, you may find our article “How to Avoid the ‘Resource Limit Reached’ Error on Shared Hosting” helpful for interpreting what those limits practically mean.

Understand traffic volume and patterns

Next, analyse how much traffic you actually serve:

• Visits/users per day: Use tools like AWStats, Webalizer or your analytics (Matomo, Google Analytics, etc.) to see daily and hourly patterns.
• Bandwidth: Measure GB/month transferred. This helps determine whether your VPS bandwidth quota is sufficient.
• Peak concurrency: Look at the busiest hour and estimate how many concurrent users and requests you handle.

For a deeper, formula-based approach, especially if you host multiple sites or a busy store, we have a dedicated article on how to estimate traffic and bandwidth needs on shared hosting and VPS.

Application-specific signals

Beyond raw traffic, look at how your application behaves:

• Database load: Does your host complain about slow queries or excessive CPU from MySQL/MariaDB?
• Cache usage: Are you using full-page cache, object cache (Redis/Memcached), or is everything hitting PHP and the database directly?
• Background work: Cron jobs, queue workers, scheduled imports/exports and reporting tasks all consume CPU and RAM.

Write these findings down. They will directly influence your VPS sizing.

Step 2: Plan VPS Resources Based on Real Data

Armed with traffic and resource data, you can now size a VPS that is powerful enough without wasting budget. Leave workload-appropriate headroom instead of planning to run at 90–100% utilisation all day.

vCPU (virtual CPU)

Use shared hosting CPU usage to inform VPS sizing, not as a direct conversion to vCPUs. First establish what the host’s CPU percentage measures. The ranges below are rough starting points to validate under representative peak load, not visit-count capacity guarantees:

• Light sites: Small corporate site or blog (for example, ~50k visits/month): consider 1–2 vCPUs as an initial test configuration, assuming good caching and optimized code.
• Busy WordPress/WooCommerce or medium apps: For online stores, learning platforms or membership sites, evaluate 2–4 vCPUs as an initial test configuration, including representative order, login and dynamic-content workloads.
• Heavier workloads or multiple sites: If you run several active sites, an API and background workers, evaluate 4+ vCPUs and measure whether that leaves room for growth.

If you use PHP‑based apps, our article on how much CPU, RAM and bandwidth a website needs gives practical sizing examples.

RAM (memory)

RAM is where under-sizing hurts quickly: PHP processes, databases and caches all live here.

• 1–2 GB RAM: May suit a single small site with light database usage, carefully tuned PHP limits and minimal background tasks.
• 4 GB RAM: A starting point to evaluate for WordPress + WooCommerce or a small SaaS app; available room for object cache and PHP workers depends on the workload.
• 8+ GB RAM: Recommended if you host multiple busy sites, intensive reporting, or you rely on in-memory caches (Redis) and search engines (Elasticsearch/OpenSearch, Meilisearch, etc.).

Compare these rough guidelines with your current usage charts, then validate total memory use under representative peak load. Include the OS, control panel, database and caches in the VPS budget; shared-account charts may not include all of them. If you frequently hit memory limits, allow additional headroom.

Disk type, size and IOPS

Compare both storage capacity and disk type when choosing a VPS plan.

• Type: Prefer SSD storage, including NVMe options. NVMe can offer higher IOPS (input/output operations per second) than SATA SSDs, but the VPS’s actual storage limits and workload determine the benefit.
• Size: Add up your existing usage (files + databases + emails), then budget explicitly for logs, retained backups, staging copies and growth. An extra 50–100% is a starting allowance, not a substitute for calculating those copies.
• Performance: If you expect frequent imports, backups or many small database writes, compare the plans’ IOPS and throughput limits as well as their disk types.

We covered this topic in depth in our NVMe VPS hosting guide, including what IOPS and IOwait numbers really mean in practice.

Bandwidth

Take your monthly bandwidth figure from shared hosting and add a safety margin:

• If you use 200 GB/month today, plan for at least 300–400 GB/month.
• If you are close to 1 TB/month, choose a plan with a clear buffer above that, especially if you expect campaigns or international traffic growth.

If you serve heavy images or downloads, consider combining your VPS with a CDN later to offload static assets.

IPv4, IPv6 and IP reputation

Confirm whether the chosen plan includes a dedicated public IPv4 address, IPv6, and control over reverse DNS (PTR). If you send transactional email (order confirmations, password resets) directly from the VPS, you must plan email DNS (SPF, DKIM, PTR) and warm up the IP reputation carefully. We will touch on email in the migration steps.

Step 3: Prepare the New VPS Properly

Once you have selected a suitable VPS plan at dchost.com, the next goal is to turn that blank instance into a ready, secure and tested environment before directing production traffic to it.

Choose OS and control panel

For most web workloads we recommend a stable Linux distribution such as AlmaLinux, Rocky Linux, Debian or Ubuntu. Your choice may be influenced by:

• Compatibility with your control panel (cPanel, DirectAdmin, Plesk, etc.).
• Your existing knowledge or your team’s experience.
• Long-term support (LTS) requirements.

If you prefer managing everything over SSH, our guide on running a VPS without a control panel over SSH only walks through a complete stack setup.

Apply basic security hardening

Security must be in place before you copy production data:

• Create a non-root user with sudo privileges.
• Configure SSH keys and verify a new SSH session and sudo access before disabling password logins. If changing the SSH port, allow the new port through the firewall first and keep the existing session open until access is confirmed.
• Enable a firewall (UFW, firewalld or nftables) allowing only necessary ports (SSH, HTTP/HTTPS, panel ports).
• Update the OS and packages; remove unused services.

We maintain a step-by-step hardening checklist in our article “The Calm, No‑Drama Guide: How to Secure a VPS Server (For Real People)”. It is a good companion while preparing the new machine.

Install and tune the web stack

Match the stack of your shared hosting as closely as possible to reduce surprises:

• Web server: Apache, Nginx or LiteSpeed/OpenLiteSpeed, depending on your preference and application requirements.
• PHP: Match the existing major and minor release where it is still supported, using current security patches and the required extensions. If the existing release is unsupported, test a supported replacement before cutover rather than carrying it into production.
• Database: MySQL, MariaDB or PostgreSQL, again matching versions as closely as possible.
• Caching: Configure OPcache, and if your application supports it, Redis or Memcached for object caching.

Also replicate key PHP settings such as memory_limit, max_execution_time and upload_max_filesize. We explain how to tune these safely in our article on choosing the right PHP memory_limit, max_execution_time and upload_max_filesize.

Benchmark before migration

With the stack ready, perform quick benchmarks to verify that the VPS delivers expected performance for CPU, disk and network. This helps spot performance constraints or misconfigurations (e.g. throttled CPU, slow storage tier) before they affect production. Our new VPS checklist for benchmarking CPU, disk and network walks through practical tools and what numbers to look for.

Step 4: Design a Low‑Downtime Migration Strategy

Now that the new VPS is ready, the focus shifts to how to move your site. The following sequence aims to minimise disruption. For a write-heavy application, plan a brief write freeze for the final sync unless you have a tested way to keep both servers using one authoritative data set during cutover:

1. Reduce DNS TTLs in advance.
2. Take a full backup on shared hosting.
3. Copy files and databases to the VPS.
4. Test everything via a temporary host mapping or preview domain.
5. Pause application writes and background jobs before the final file and database sync; keep the preview copy from running production jobs.
6. Switch DNS and monitor. While traffic can reach either server, keep writes disabled on the old copy and resume them only on the authoritative application. If old-server requests cannot be forwarded there safely, show maintenance mode on the old copy.

We have a separate checklist-style article on moving from shared hosting to a VPS with zero downtime. This guide combines resource sizing with a maintenance-and-sync migration procedure; the following sections explain DNS timing, traffic-window selection and the cutover sequence.

Lower DNS TTLs early

TTL (Time To Live) is how long resolvers cache your DNS records. When you change the A record of your domain to point to the VPS, you want that change to propagate fast.

• At least 24–48 hours before migration, lower the TTL on your main A/AAAA records (and possibly MX if email is affected) from values like 3600–86400 seconds to 300 seconds or even 120 seconds.
• Wait for the old TTL to expire so that the shorter TTL is actually used by resolvers.

Our article “The TTL Playbook for Zero‑Downtime Migrations” explains how to plan these TTL changes to reduce DNS cache delays during cutover.

Plan around your traffic patterns

Look at your analytics to find the naturally quietest period for your site:

• For B2B apps, compare traffic across customer timezones and working hours rather than assuming that local nighttime is quiet.
• For B2C/e‑commerce, check hourly visits and order activity, including campaigns and scheduled promotions, before choosing a window.

Schedule the final sync and DNS cutover inside this window so that fewer active sessions are affected and cache warm‑up hits are manageable.

Decide what moves together

For many projects, the safest path is to move only the web application and database first, keeping some services (e.g. email) where they are for a while. That reduces the blast radius if something unexpected happens.

• Scenario A – Web + DB only: Move the website and database to VPS and keep email at the current provider. Update the web A/AAAA records, but first check whether MX targets, mail-client hostnames or SPF depend on those addresses; preserve or adjust those dependencies so mail stays on the existing service.
• Scenario B – Full move: Web, database and email all move to the VPS or to a new mail platform simultaneously; DNS changes include MX, SPF and others.

Scenario A is simpler and has fewer dependencies. Scenario B needs more detailed testing of email deliverability, PTR records and spam filters.

Step 5: Perform the Migration Step‑by‑Step

With planning complete, it is time to move real data. The exact tooling and transfer method depend on your control panel, application and database. Adapt the sequence below to those requirements and validate it before cutover.

1. Full backup on shared hosting

Before touching anything, take a complete backup on your shared hosting account:

• All website files (public_html or relevant document roots), plus required application files and configuration outside those roots and a record of scheduled jobs.
• All databases (via phpMyAdmin export, panel backup tools or command line).
• Email accounts and mailboxes (if you plan to move email now).

Store this backup off‑server (not only on the same shared host), restrict access to it and keep archives out of public document roots. Verify that it can be restored before relying on it. Restoring this snapshot will not recover writes made after it was taken.

2. Initial file transfer to VPS

Next, copy files from shared hosting to the VPS:

• For control panel to control panel moves (e.g. cPanel to cPanel), use built‑in transfer tools or full account backups.
• For manual moves, use SFTP, rsync over SSH, or archive (tar/zip) + download/upload.

Place the files in the correct document root on your VPS (often /home/username/public_html for panel setups or a custom directory under /var/www for manual stacks).

3. Database migration

Export a consistent database snapshot from shared hosting and import it into the VPS database server. Use a database-appropriate consistent backup method or pause writes during export. Treat this as the initial copy; changes made on the live site afterward must be included in the final database sync:

• Use mysqldump for MySQL/MariaDB or panel tools like phpMyAdmin export.
• Create the target database and application user, grant that user the required database privileges, and use the same names or adjust your application configuration later.
• Import via command line or management panel.

After import, run a quick check:

• Connect with a DB client (phpMyAdmin, Adminer or CLI) and compare tables and row counts against the exported snapshot or a source held unchanged during comparison. Matching counts are a basic check, not proof that all data is identical.
• Check character set and collation to avoid encoding issues.

4. Update application configuration

Point your application to the new database and ensure URLs and paths are correct:

• Update wp-config.php (for WordPress), .env (for Laravel) or respective config files with new DB host, name, user and password.
• Ensure configured file paths are correct and required log, cache and upload directories exist and are writable by the application user; do not make the entire application tree writable.
• Configure email sending (SMTP settings) if you are changing how you send mail.

5. Configure SSL/TLS on the VPS

To avoid browser warnings during testing, set up SSL on the VPS:

• If your domain already has a certificate, arrange a valid certificate for that domain on the VPS and complete the CA’s validation requirements before cutover. A separate hostname (like vps.yourdomain.com) with its own certificate can be used for preliminary testing, but that certificate does not cover the final domain unless it explicitly includes it.
• Consider using Let’s Encrypt or another CA with automated renewal (ACME clients).

Before cutover, test HTTPS on the VPS using the final hostname, check redirects for loops and fix any page resources still loaded over HTTP. Recheck after cutover. Preserve existing HSTS requirements; enable or broaden HSTS only after HTTPS works for every hostname it will cover.

6. Preview the site on the VPS without changing DNS

Before changing public DNS for the production domain, preview the site on the VPS. A temporary hostname or local hosts-file override does not restrict public access; use access controls if the preview must be private.

• Use a temporary hostname (vps.yourdomain.com) pointing to the VPS IP and configure the virtual host to respond to both this and the final domain.
• Alternatively, edit your local hosts file on your computer so that yourdomain.com resolves to the VPS IP while everyone else still sees the old host.

Confirm that requests reach the VPS, including after redirects, then test thoroughly:

• Homepage, product pages, blog posts, search and filters.
• Login, registration, checkout and forms. Use sandbox payment credentials and controlled email recipients to avoid real charges or customer notifications during preview testing.
• Admin panel performance.
• File uploads, downloads and image galleries.

7. Final database and file sync

Between your initial copy and the final cutover, new data appears on the old server: new orders, comments, uploads, etc. To avoid losing them:

• During low traffic, put the old application into maintenance mode and pause all other writers, including scheduled jobs, queue workers and inbound integrations. Keep the VPS application and its background writers paused during the final sync. Allow enough time for the measured transfer and validation work rather than assuming a few minutes.
• Take a fresh database dump and import it on the VPS, replacing the earlier copy.
• Sync changed files (e.g. wp-content/uploads) again with rsync or SFTP.

Once this final sync is complete and validated, restore production settings used for testing. Before reopening the application, verify its session handling: if existing logins or carts must survive, preserve the required session data and signing or encryption secrets through an application-supported method and test that behaviour. If sessions cannot be preserved, plan and communicate the resulting sign-ins or cart resets rather than promising continuity.

Enable the application and its writers only on the VPS. Keep the old site in maintenance mode with its other writers paused so no new data is written there. Visitors still reaching the old host will see maintenance rather than the live site.

8. DNS cutover to the VPS

Now you point your domain to the new VPS:

• Update web A records to the VPS IPv4 address and web AAAA records to its tested IPv6 address. If the VPS will not serve IPv6, remove obsolete web AAAA records rather than leaving them pointed at the old host.
• If you moved email, update MX, SPF (TXT), DKIM (TXT/record) and PTR (Reverse DNS via your VPS provider) as needed.

Lowering TTLs far enough in advance can shorten the overlap, but it does not guarantee a switch within a few minutes. Previously cached records may retain their earlier TTL, and some clients may continue using the old address. Monitor traffic on both hosts and keep the old endpoint available without accepting writes during the transition.

9. Monitor closely after the switch

For the first few hours after DNS cutover, watch:

• Server CPU, RAM, disk I/O and network traffic to confirm your sizing assumptions.
• Application logs and error logs for PHP, Nginx/Apache and the database.
• Key user flows (logins, checkouts, API endpoints).

If you set up monitoring and uptime checks (e.g. with Prometheus, Grafana, Uptime Kuma), this is where they pay off. Our article on VPS monitoring and alerts can help you put basics in place.

Step 6: Handling Email, DNS and Rollback Options

Email and DNS details often cause the small issues people remember from migrations. A bit of extra planning here avoids most surprises.

Option A: Keep email where it is (simpler)

If your current email setup works well, consider keeping it in place for now. Keep the required mail hosting subscription and DNS service active, even if the website moves:

• Change only the website’s A/AAAA records, such as yourdomain.com and www, to the VPS, after checking that mail delivery and mail clients do not depend on those same names.
• Retain the existing MX targets and their address records if they still route to the mail provider. If an MX target is the main domain, separate mail routing from the website before changing that domain’s address. Review SPF rather than assuming it is unchanged: mechanisms that depend on changed addresses may alter sender authorisation. Retain DKIM and DMARC settings that remain valid for the existing provider.
• Configure your web app on the VPS to send mail using SMTP via the existing email provider.

This reduces the number of moving parts during the main migration. You can always move email later with a dedicated plan.

Option B: Move email to the VPS (more complex)

Before committing to self-hosted email, confirm the chosen provider and plan permit the required SMTP traffic, including inbound TCP port 25 for receiving mail from other servers and outbound TCP port 25 for direct delivery to them. Ask about restrictions and any approval process; do not assume that installing mail software or changing DNS establishes connectivity. If direct outbound delivery is unavailable, evaluate an authenticated SMTP relay and confirm that its submission endpoint is reachable. A relay for outgoing mail does not replace inbound connectivity needed to receive mail on the VPS.

Extend the Step 3 firewall rules at both the VPS and any provider firewall to allow only the mail services you configure. These may include inbound TCP 25 for server-to-server mail, TCP 465 for submission with implicit TLS or TCP 587 with required STARTTLS, and TCP 993 for IMAP with implicit TLS. Require authentication for client submission and prevent unauthorised relaying. Allow the corresponding outbound delivery or relay traffic, configure valid certificates for client-facing mail hostnames, and test connectivity, TLS and sending/receiving from outside the VPS before changing MX records. Then complete the mail setup:

• Set up mail services (Postfix/Exim + Dovecot or panel-managed equivalents).
• Configure SPF, DKIM and DMARC records for your domain.
• Request or configure a proper PTR (Reverse DNS) record for the VPS IP; our guide on PTR (Reverse DNS) records explains why this matters for email delivery.
• Migrate existing mailboxes via IMAP sync tools or email migration features in your control panel. Recreate accounts, aliases and forwarding rules as needed; copying messages alone does not migrate these settings. Test sending and receiving before changing MX records, then keep the old mail service available and repeat mailbox syncs to capture messages delivered there during the DNS transition.

Monitor bounces and spam folder placement carefully after the switch and warm up gradually if you send large volumes of email.

Rollback plan

Even with careful planning, you should have a way back:

• Keep the old hosting account active and retain a documented rollback procedure. If a critical issue appears, freeze writes on both hosts and preserve backups before deciding which copy of the data will be authoritative.
• With old-host writes frozen at cutover, subsequent production changes should exist only on the VPS. Reconcile those changes, including uploads and database records, into the chosen rollback copy and validate it before reopening writes. Then point DNS back if needed, keeping the VPS from accepting writes during the overlap. If reconciliation is not possible, explicitly assess and approve the potential data loss before proceeding.

Testing the VPS and validating the final sync reduce migration risk but do not eliminate the need for rollback planning. A documented path clarifies how to restore service without creating conflicting data.

After Migration: Optimisation and Next Steps

Once your site runs stably on the VPS, you can start using the flexibility that made you move in the first place.

Optimise performance

• Enable and tune caching: Full-page caching (Nginx FastCGI cache, LiteSpeed Cache, Varnish) plus object caching (Redis) can drastically reduce CPU load. Exclude personalised pages, carts, checkout, account pages and other session-sensitive routes from shared full-page caching.
• Tune PHP-FPM and OPcache: Adjust process counts, pm.max_children, and OPcache configuration for your concurrency level and available RAM, leaving capacity for the database and other services.
• Database tuning: Use settings appropriate to your database engine and version. For an InnoDB workload, size the buffer pool within the database’s RAM budget. Evaluate query caching only where supported and used, and examine slow query logs.

Strengthen security and backups

• Regular updates: Keep OS and packages patched, especially web server, PHP and database.
• Automated backups: Set an offsite backup schedule and retention policy based on how much data you can afford to lose; daily backups may not be frequent enough for a busy store. Use the 3‑2‑1 strategy (3 copies, 2 media, 1 offsite) as a planning framework and regularly verify restores.
• Monitoring and alerts: Monitor resource usage trends to know when it is time to scale the VPS up again.

Plan for future scaling

As your traffic grows further, a single VPS may evolve into:

• A larger VPS with more vCPU/RAM.
• Separate VPSs for web and database tiers.
• Load-balanced clusters with multiple web nodes behind a reverse proxy.

The resource and traffic analysis habits you built for this migration will be invaluable for those next steps.

Conclusion: Calm, Predictable Migration from Shared Hosting to VPS

Moving from shared hosting to a VPS can be a controlled, low-downtime project rather than a last-minute emergency. The maintenance-and-sync procedure above includes a service interruption; uninterrupted availability requires a different design for handling traffic, writes and sessions during the transition. Start by understanding your current resource usage and traffic patterns to select and validate a VPS configuration with some breathing room. Prepare the server carefully: choose a stable OS, configure the web stack, harden security and benchmark performance before directing production traffic to it. Then execute a disciplined migration: lower TTLs in advance, take full backups, copy files and databases, test via hosts file or preview domains, pause writers for the final database and file sync, validate the result, and only then enable the VPS application and switch DNS while monitoring closely.

A VPS can provide more control and flexibility, but performance and reliability depend on resource sizing, configuration and ongoing operation. When selecting a plan, establish who is responsible for configuration, maintenance and migration support. For a more advanced architecture—high availability, separate database servers or future colocation—confirm the required infrastructure and support scope before committing.