Migrate Shared Hosting to VPS India 2026
Step-by-step guide to migrate shared hosting to VPS India with real Linux commands and Inservers VPS as the recommended destination in 2026.
Migrating from shared hosting to VPS India is simpler than most site owners expect. The process has nine steps: back up files and database on your old host, provision a VPS, install the LEMP stack, transfer files via rsync, import the database, configure Nginx, enable SSL, update wp-config.php, and cut over DNS. Total elapsed time for a 5GB WordPress site: under two hours.
5 Signs You Have Already Outgrown Shared Hosting
If you are reading this guide, you have probably already felt at least one of these. Here is the full checklist so you can stop second-guessing the decision.
CPU throttling during business hours. cPanel shared environments enforce per-account CPU limits — typically in the range of 25 to 100 "Entry Processes" and CPU usage capped around 25% of a single core. When you hit that ceiling, cPanel throws a 503 or shows a "Resource Limit Reached" error page. If this happens between 10am and 8pm IST — peak Indian internet hours — you are losing real customers.
Persistently high I/O wait killing load times. On shared hosting, twenty other accounts fight over the same spinning disk. MySQL queries that should complete in 3ms take 300ms because your neighbour is running a WooCommerce sale. You cannot fix this with a caching plugin when the disk itself is the bottleneck.
RAM limits preventing caching plugins from working. Redis and Memcached need to run as persistent system services. Shared hosts do not allow that. WP-Rocket and W3 Total Cache fall back to file-based caching, which is better than nothing but far slower than in-memory object caching. If your product catalogue has 5,000+ SKUs, the database will get hammered on every page load regardless of how you configure your plugin.
No SSH access. This is the biggest invisible constraint. Without SSH you cannot run WP-CLI, you cannot set up Composer, you cannot debug with tail -f error.log, and you cannot do anything that requires real system access. Every serious optimisation task hits this wall eventually.
Cannot install custom software. Shared hosting runs a fixed PHP version (often outdated), a fixed MySQL version, and no ability to install system-level packages. PHP 8.2 with OPcache tuned for your specific workload is not available. PHP 8.0 shared by 200 accounts is what you get.
Why Inservers VPS Is the Right Destination for Indian Websites
When you migrate shared hosting to VPS India, the provider you land on matters as much as the migration itself. Here is why Inservers Host Private Limited is the recommended destination for this guide.
India data centre, same country as your users. Inservers runs infrastructure through Advika Datacenter in Noida, which holds ISO 27001 certification and is MeitY-empanelled. A server physically located in Noida delivers sub-5ms latency to users across North India and under 20ms to most of peninsular India. Compare that to a Singapore VPS, which adds 60–100ms of baseline latency before your first byte is sent.
15-minute provisioning minimises your migration window. You can order at 1:45am IST, have root SSH access by 2:00am, and complete your migration and DNS cut-over before 4:00am — all before Jio users start their morning browsing. Most VPS providers take 30–60 minutes for provisioning; some managed providers take hours. Inservers consistently provisions in under 15 minutes, which is the difference between a clean maintenance window and an extended outage.
1Gbps unmetered bandwidth means rsync finishes fast. Transferring a 10GB WordPress install over a 100Mbps link takes about 13 minutes. Over a 1Gbps link it takes under 90 seconds. Inservers provides 1Gbps unmetered bandwidth on every plan, which directly compresses the window during which your site is in a split-brain state between old and new servers.
NVMe SSD storage makes your post-migration site measurably faster. Database queries that took 180ms on shared hosting SATA can complete in 8–12ms on NVMe. That is not a marketing claim; it is a function of random-read IOPS (NVMe delivers 500K+ IOPS versus 200–400 IOPS for spinning disk). For WooCommerce sites running complex product queries, this is the single biggest performance gain from the migration.
Hardware you can trust. Inservers runs AMD Ryzen 7 5700G and EPYC 7C13 processors — modern silicon with consistent single-thread performance that PHP workloads depend on.
INR billing, UPI payment, and GST invoice. No international transaction fee, no currency conversion, and a proper GST invoice for your business expense claim. Plans start at ₹399/month with full root access.
Enterprise-grade DDoS protection at no extra cost. Inservers routes all traffic through Cloudflare Magic Transit with 500 Tbps DDoS mitigation capacity on every plan, including the entry tier. On shared hosting you share whatever DDoS protection your host has configured. On Inservers VPS you get the same network-level protection that Cloudflare sells to enterprises.
Before You Migrate: The Pre-Flight Checklist
Running this checklist before you touch anything prevents 90% of post-migration problems.
Back up everything. Files and database, both. Do not start a migration without a complete backup sitting on your local machine. Your shared host's backup is not a substitute for a backup you personally created and verified.
Note your current PHP version. Log into cPanel, go to MultiPHP Manager, and write down the PHP version your site is running. You will need to install exactly this version (or higher) on the VPS. PHP 7.4 and 8.1 behave differently; migrating and upgrading PHP simultaneously is a recipe for unexpected errors. Get the site working on the new server with the old PHP version first, then upgrade.
List every cron job. In cPanel, go to Cron Jobs and copy every entry: the schedule and the command. WordPress WooCommerce sites often have custom cron jobs for inventory sync or email queues. These will not exist on the new server unless you recreate them.
Check your email setup. If email hosting lives on the same shared account (MX records pointing to the same server), you need a separate plan for email after migration. Many sites can switch to Google Workspace or Zoho Mail; decide this before migration day, not after.
Record your current DNS TTL. Log into your domain registrar or DNS provider and find your A record TTL. If it is 86400 (24 hours), lower it to 300 (5 minutes) at least 48 hours before your planned migration. This makes the final DNS cut-over propagate in minutes instead of a day.
Plan a maintenance window. 2:00am IST is the right time. Indian web traffic typically drops to its lowest point between 1:30am and 4:00am IST. Even Jio's night-time browsing crowd is thinner in this window. Put up a maintenance page on your old server before you start, so users who land during the window see a clean message rather than a broken site.
Step 1: Order Your Inservers VPS
Visit inservers.com and select the plan that matches your site size.
1GB RAM (entry plan): Suitable for a straightforward WordPress blog or small informational site with under 10,000 monthly visitors.
2GB RAM: The right choice for most WooCommerce stores, membership sites, or WordPress installs with multiple active plugins. This is the most common migration target.
4GB RAM: Multi-site WordPress networks, high-traffic blogs (50,000+ monthly visitors), or sites running Elasticsearch or Redis alongside the web stack.
When configuring your order: - Choose Ubuntu 22.04 LTS as your operating system. It has the longest support window (until 2032), the widest package availability, and the most community documentation. - Select the Noida data centre for the lowest latency to Indian users. - Add your SSH public key during checkout if the panel allows it, or you will set up key authentication in the next step.
Pay via UPI, Net Banking, or card. You will receive a GST invoice at the email address you register. Root credentials and the server IP arrive within 15 minutes.
Step 2: Initial VPS Setup
SSH into your new server as root and run the following sequence in order.
ssh root@YOUR_VPS_IP
Update all system packages first. Do not skip this; fresh VPS images are often a few weeks behind.
apt update && apt upgrade -y
Create a non-root deployment user. Running everything as root is dangerous — a single mistyped command can destroy the server.
adduser deploy
usermod -aG sudo deploy
Set a strong password when prompted. Then copy your SSH public key to the new user so you can log in without a password:
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy
Configure UFW firewall. Allow SSH and web traffic, then enable the firewall:
ufw allow OpenSSH
ufw allow 'Nginx Full'
ufw enable
UFW will ask for confirmation before enabling. Type y and press Enter. From this point forward, only ports 22, 80, and 443 are reachable from the internet.
Log out and log back in as the deploy user to verify sudo access works:
exit
ssh deploy@YOUR_VPS_IP
sudo whoami
The output should be root. If it is, your base server is correctly configured.
Step 3: Install the LEMP Stack
LEMP is Nginx + MySQL + PHP. This is the recommended stack for WordPress and WooCommerce on a VPS because Nginx handles concurrent connections far more efficiently than Apache under Indian traffic patterns (where shared mobile connections create high concurrency with low throughput per connection).
Install Nginx:
sudo apt install nginx -y
sudo systemctl enable nginx
sudo systemctl start nginx
Visit http://YOUR_VPS_IP in a browser. You should see the Nginx welcome page.
Install MySQL 8.0:
Ubuntu 22.04 ships MySQL 8.0 in its default repositories.
sudo apt install mysql-server -y
sudo mysql_secure_installation
The mysql_secure_installation wizard will ask you to set a root password, remove anonymous users, disable remote root login, and remove the test database. Answer yes to all of these.
Install PHP 8.2 and php-fpm:
Ubuntu 22.04's default repositories include PHP 8.1. To get PHP 8.2, add Ondřej Surý's PPA, which is the standard source for up-to-date PHP packages on Ubuntu:
sudo apt install -y lsb-release ca-certificates apt-transport-https software-properties-common
sudo add-apt-repository ppa:ondrej/php -y
sudo apt update
sudo apt install php8.2 php8.2-fpm php8.2-mysql php8.2-xml php8.2-curl php8.2-mbstring php8.2-zip php8.2-gd php8.2-intl php8.2-bcmath php8.2-imagick -y
After installation, tune the key PHP settings. Open the php-fpm configuration:
sudo nano /etc/php/8.2/fpm/php.ini
Find and update these values:
memory_limit = 512M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_vars = 5000
Save, then restart php-fpm:
sudo systemctl restart php8.2-fpm
sudo systemctl enable php8.2-fpm
Step 4: Transfer Your Files
There are two paths here depending on whether your old shared host provides SSH access.
If your old host provides SSH (most hosts do, even on shared):
Use rsync directly between the two servers. This is the fastest method and uses Inservers' 1Gbps uplink to pull data rapidly from the old host. Run this from your VPS:
sudo mkdir -p /var/www/yoursite
rsync -avz --progress [email protected]:/home/user/public_html/ /var/www/yoursite/
Replace user with your cPanel username, oldhost.com with your old server's hostname or IP, and yoursite with your domain name (without dots, for the directory name). The -avz flags preserve file attributes, are verbose, and compress the transfer stream. The --progress flag shows transfer speed in real time.
If your old host does not provide SSH:
Download your site files via FTP/SFTP to your local machine first, then upload them to the VPS:
scp -r /path/to/local/site/files deploy@YOUR_VPS_IP:/var/www/yoursite/
After the transfer, set correct ownership so Nginx and php-fpm can read the files:
sudo chown -R www-data:www-data /var/www/yoursite
sudo find /var/www/yoursite -type d -exec chmod 755 {} \;
sudo find /var/www/yoursite -type f -exec chmod 644 {} \;
These permissions (755 for directories, 644 for files) are the correct baseline for WordPress. The chown to www-data is essential — without it, php-fpm will throw 403 errors.
Step 5: Transfer the Database
On your old host (via SSH or cPanel Terminal):
mysqldump -u YOUR_DB_USER -p YOUR_DB_NAME > site_backup.sql
Enter the database password when prompted. If your old host does not provide SSH, export the database from phpMyAdmin: select your database, click Export, choose SQL format, and download the file.
Transfer the SQL file to your VPS:
scp site_backup.sql deploy@YOUR_VPS_IP:/tmp/
On your VPS, create the new database and user:
sudo mysql -u root -p
Inside the MySQL prompt:
CREATE DATABASE yoursite_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'yoursite_user'@'localhost' IDENTIFIED BY 'use_a_strong_password_here';
GRANT ALL PRIVILEGES ON yoursite_db.* TO 'yoursite_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;
Use CHARACTER SET utf8mb4 explicitly. Many shared hosting environments create databases with the older utf8 character set, which cannot store certain Unicode characters (including emoji). Importing into utf8mb4 is always safe and avoids charset mismatch issues.
Import the database:
mysql -u yoursite_user -p yoursite_db < /tmp/site_backup.sql
Step 6: Configure the Nginx Virtual Host
Create a server block configuration file for your domain:
sudo nano /etc/nginx/sites-available/yoursite.com
Paste the following working WordPress configuration:
server {
listen 80;
server_name yoursite.com www.yoursite.com;
root /var/www/yoursite;
index index.php index.html;
access_log /var/log/nginx/yoursite.access.log;
error_log /var/log/nginx/yoursite.error.log;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ {
expires 1y;
add_header Cache-Control "public, immutable";
access_log off;
}
location ~ /\.ht {
deny all;
}
location = /favicon.ico { log_not_found off; access_log off; }
location = /robots.txt { log_not_found off; access_log off; }
}
Enable the site and test the configuration:
sudo ln -s /etc/nginx/sites-available/yoursite.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
If nginx -t returns syntax is ok and test is successful, you are good. If there are errors, the output will tell you exactly which line is wrong.
Step 7: SSL with Certbot (Let's Encrypt)
Install Certbot and its Nginx plugin:
sudo apt install certbot python3-certbot-nginx -y
Obtain and install the certificate. Certbot will automatically modify your Nginx config to redirect HTTP to HTTPS and set up the SSL parameters:
sudo certbot --nginx -d yoursite.com -d www.yoursite.com
Enter an email address when prompted (for expiry notifications), agree to the terms, and choose whether to share your email with EFF. Certbot will handle the rest.
Verify that auto-renewal is configured:
sudo systemctl status certbot.timer
The timer should show active (waiting). Let's Encrypt certificates expire every 90 days; the timer renews them automatically before expiry. You can test the renewal process without actually renewing:
sudo certbot renew --dry-run
Step 8: Update wp-config.php
Open the WordPress configuration file on your VPS:
sudo nano /var/www/yoursite/wp-config.php
Update the database connection constants to match what you created in Step 5:
define('DB_NAME', 'yoursite_db');
define('DB_USER', 'yoursite_user');
define('DB_PASSWORD', 'use_a_strong_password_here');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', 'utf8mb4_unicode_ci');
Also update the WP_HOME and WP_SITEURL constants if your old host had them hard-coded:
define('WP_HOME', 'https://yoursite.com');
define('WP_SITEURL', 'https://yoursite.com');
Save the file. The site is now configured to connect to the local MySQL database on the VPS.
Step 9: Lower DNS TTL, Test, Then Cut Over
Test the site before changing DNS. Edit the /etc/hosts file on your local machine (not the server) to point your domain at the new VPS IP:
On macOS/Linux:
sudo nano /etc/hosts
On Windows, edit C:\Windows\System32\drivers\etc\hosts as Administrator.
Add this line:
YOUR_VPS_IP yoursite.com www.yoursite.com
Now open https://yoursite.com in your browser. Because your local machine resolves the domain to the new VPS IP, you are testing the new server without affecting live visitors. Check:
- The homepage loads correctly over HTTPS
- You can log in to the WordPress admin dashboard
- Product pages and checkout work (for WooCommerce)
- Images load correctly
- Contact forms submit
- Any custom post types or taxonomies are visible
When you are satisfied the site works, remove the /etc/hosts line and proceed to DNS cut-over.
DNS cut-over. Log into your domain registrar or DNS provider. Change the A record for yoursite.com and www.yoursite.com from the old hosting IP to YOUR_VPS_IP. Because you lowered the TTL to 300 seconds 48 hours ago, this change propagates globally within 5 minutes.
Monitor both servers for the next 30 minutes. Keep the old shared hosting account active (do not cancel it immediately) so that any visitor whose DNS has not yet propagated still gets a working site. Cancel the old account only after 24–48 hours.
Post-Migration Optimisation
The migration is done. These optimisations are what separate a VPS that merely runs your site from a VPS that makes your site noticeably faster for Indian users.
Enable OPcache. OPcache stores compiled PHP bytecode in memory, eliminating the need to recompile PHP files on every request. It is installed with PHP 8.2 but needs to be activated:
sudo nano /etc/php/8.2/fpm/php.ini
Find and set these values:
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.jit=1255
opcache.jit_buffer_size=128M
The JIT compiler (available in PHP 8.x) provides additional speed gains for computation-heavy workloads like WooCommerce price calculations.
Install Redis for object caching. Redis keeps database query results in RAM so repeated identical queries do not hit MySQL at all. On WooCommerce sites, this alone can cut average page generation time by 40–60%.
sudo apt install redis-server php8.2-redis -y
sudo systemctl enable redis-server
sudo systemctl start redis-server
Then install the Redis Object Cache plugin in WordPress and enable it. The plugin will detect Redis automatically.
Tune PHP-FPM pool settings. The default PHP-FPM configuration is conservative. For a 2GB RAM VPS handling Indian traffic patterns (high concurrency bursts during cricket matches and sale events), these settings work well:
sudo nano /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 8
pm.max_requests = 500
The pm.max_requests = 500 setting recycles workers after 500 requests, which prevents memory leaks in long-running PHP processes from gradually consuming all available RAM.
Enable Nginx microcaching. Microcaching serves cached pages to anonymous visitors for 30–60 seconds, which eliminates the PHP and database overhead for the vast majority of page views. Add this to your Nginx config:
fastcgi_cache_path /tmp/nginx_cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
fastcgi_cache_use_stale error timeout invalid_header http_500;
Then inside your server block's location ~ \.php$ section, add:
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 30s;
fastcgi_cache_bypass $cookie_woocommerce_cart $cookie_wordpress_logged_in;
fastcgi_no_cache $cookie_woocommerce_cart $cookie_wordpress_logged_in;
The fastcgi_cache_bypass and fastcgi_no_cache directives ensure logged-in users and users with items in their WooCommerce cart always get uncached responses. This is critical — you do not want a customer to see another customer's cart.
Restart everything after any configuration change:
sudo systemctl restart php8.2-fpm
sudo systemctl reload nginx
Common Migration Mistakes (and How to Avoid Them)
Forgetting to recreate cron jobs. WordPress relies on WP-Cron for scheduled posts, email queues, and plugin tasks. If you use server-side cron (the correct approach for high-traffic sites), you must add it to the new server's crontab manually. Run crontab -e as the www-data user or check /etc/cron.d/ for any site-specific cron files.
Wrong file permissions. Files uploaded via WordPress (images, PDFs) go into wp-content/uploads/. After migration, this directory and all its subdirectories must be writable by www-data. The correct permissions are 755 for directories and 644 for files. If the uploads directory ends up with 777 permissions, it is a security vulnerability. If it ends up with 644 for subdirectories, WordPress cannot create year/month upload folders.
Not testing email delivery. If your site sends transactional email (order confirmations, password resets), test it immediately after migration. Shared hosts often configure PHP's mail() function to use the local MTA. On a fresh VPS, there is no MTA configured. Install and configure Postfix, or switch to an SMTP service like SendGrid or Amazon SES via a plugin. WooCommerce order emails silently failing after migration is one of the most reported post-migration issues.
MySQL charset mismatch causing import errors. If your old database used utf8 and you created the new database with utf8mb4 (as recommended), you may encounter warnings during import about truncated data. This is almost always benign — the data imports correctly. However, if the old database had a utf8 collation set at the table level, you may need to run a conversion after import:
ALTER TABLE wp_posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
Run this for any table that had collation errors during import.
Starting the migration without lowering DNS TTL. If your DNS TTL is 86400 and you forget to lower it before migration day, you will face a 24-hour propagation window during which your old host needs to stay live. Always lower TTL 48 hours in advance.
Frequently Asked Questions
How long does it take to migrate from shared hosting to VPS India? A typical 5GB WordPress site takes 90–120 minutes end-to-end: 15 minutes for Inservers VPS provisioning, 20–30 minutes for LEMP stack installation, 10–20 minutes for file and database transfer over the 1Gbps link, and 15–20 minutes for configuration and testing. Budget 2 hours for your maintenance window.
Which Inservers plan should I choose for WooCommerce migration? The 2GB RAM plan handles most WooCommerce stores comfortably when combined with Redis object caching and OPcache. Stores with more than 5,000 products or running complex filter plugins should start at 4GB RAM to give MySQL enough memory for its buffer pool.
Do I need root SSH access to migrate from shared hosting to VPS? Root access on the VPS is required to install packages, configure the web server, and set file permissions. Root access on the old shared host is not required — you only need your cPanel username, FTP credentials, and database credentials. The rsync command connects using your regular SSH or SFTP user on the old host.
Can I migrate a non-WordPress site using this guide? The file transfer and database steps (Steps 4 and 5) work for any PHP application: Laravel, Joomla, Magento, or a custom PHP app. Steps 6 and 8 are WordPress-specific. For Laravel, replace the Nginx server block with the correct one for Laravel's public/ directory and update .env instead of wp-config.php.
What happens to email after I migrate to VPS? Email hosted on the shared account will stop working once you point DNS to the VPS, unless you configure an MTA on the VPS or move email to a dedicated provider. The cleanest solution is to move email to Google Workspace or Zoho Mail before migration and update your MX records separately. Do not mix web hosting migration with email migration on the same day.
How do I handle the migration for a site that cannot go offline at all? Run both servers in parallel. Set up the VPS fully, then copy files and database. Enable database replication or use a plugin like WP Migrate to keep the VPS database in sync. When ready, flip DNS and let propagation happen naturally. Keep both servers running for 48 hours. Zero-downtime migration adds complexity but is achievable with this approach.
Is Inservers VPS managed or unmanaged? Inservers provides unmanaged VPS with full root access. This guide covers the complete server setup. Inservers provides hardware, network, and hypervisor support. Operating system configuration, software installation, and security patching are the account holder's responsibility. If you need managed VPS support, contact [email protected] or call +91-9335017701 to discuss managed options.
Does Inservers VPS include DDoS protection? Every Inservers VPS plan includes 500 Tbps DDoS mitigation through Cloudflare Magic Transit. This is network-level protection active on all plans at no additional cost — the same infrastructure Cloudflare deploys for enterprise customers. This is a significant advantage over shared hosting environments where DDoS protection is typically shared and limited.
Verdict
Migrating from shared hosting to VPS India in 2026 is a nine-step process that any technically capable site owner can complete in a two-hour maintenance window. The command sequence in this guide works. The permissions are correct. The Nginx configuration handles WordPress properly, including WooCommerce.
The reason to do this migration now rather than later is straightforward: every day your site runs on shared hosting with CPU throttling, limited RAM, and shared I/O, you are paying for a constraint rather than infrastructure. Inservers VPS at ₹399/month removes all three constraints simultaneously, adds 500 Tbps DDoS protection, delivers sub-20ms latency to Indian users through the Noida data centre, and provisions in 15 minutes so your maintenance window stays tight.
Follow the steps in order. Back up before you start. Test with /etc/hosts before cutting DNS. And schedule your window for 2:00am IST — that is when your users are asleep and your VPS has the whole night to prove itself.
Visit inservers.com to check current plan pricing, or contact the team at [email protected] or +91-9335017701 with questions about which plan fits your workload.