How to Migrate a Website from Shared Hosting to a VPS Without Downtime Print

Moving your website from shared hosting to a Virtual Private Server (VPS) gives you greater control over server resources, performance, software configuration, and security.

In this guide, we'll explain how to migrate a website from shared hosting to a VPS with minimal downtime, including transferring website files, databases, configuring Nginx, testing the new server, enabling SSL, and updating DNS.

The examples use Ubuntu and a PHP/MySQL website such as WordPress. Other applications may require additional migration steps.

Need a VPS for your website? Explore Owned Networks KVM VPS Hosting with full root access and flexible server resources.

Before You Start

Make sure you have:

• Access to your existing shared hosting control panel, such as cPanel.
• FTP, SFTP, SSH, or File Manager access to your website files.
• A complete backup of your website files and database.
• A new Ubuntu VPS with root or sudo access.
• Access to your domain's DNS settings.
• A list of email accounts and DNS records currently associated with your hosting.

Important: Do not cancel your existing shared hosting account until the migration is complete and verified.

Step 1: Prepare Your New VPS

Connect to your new Ubuntu VPS through SSH:

ssh root@YOUR_VPS_IP

Update the operating system and install the required web server components:

sudo apt update && sudo apt upgrade -y

sudo apt install -y nginx mariadb-server \
php-fpm php-mysql php-curl php-gd \
php-mbstring php-xml php-zip php-intl \
curl rsync unzip

sudo systemctl enable --now nginx mariadb

php -v
nginx -v
mariadb --version

Ensure that the installed PHP and database versions are compatible with your website before proceeding.

If you are migrating WordPress, see our WordPress on Ubuntu VPS with Nginx and Free SSL guide for additional server configuration.

Step 2: Back Up Your Website Files

Before transferring anything, create a complete backup of your website on the original hosting account.

If your shared hosting provider uses cPanel, open File Manager, locate your website directory (commonly public_html), and download a compressed backup.

If SSH access is available, you can create an archive:

cd ~/public_html

tar -czf ~/website-backup.tar.gz .

For WordPress, make sure the backup includes wp-content, wp-config.php, hidden files, themes, plugins, and uploaded media.

Keep a separate backup outside both hosting servers.

Step 3: Export Your Website Database

For MySQL or MariaDB websites, export the database from the original hosting account.

In cPanel, open phpMyAdmin, select your database, choose Export, and download the SQL file.

If SSH and database credentials are available, you can use:

mysqldump --single-transaction \
-u DATABASE_USER -p DATABASE_NAME \
> website-database.sql

Replace DATABASE_USER and DATABASE_NAME with your actual database credentials.

The --single-transaction option provides a consistent snapshot for transactional tables such as InnoDB. It does not prevent changes made after the export from being absent on the destination.

Step 4: Transfer Website Files to Your VPS

Create a directory for your website on the new VPS:

sudo mkdir -p /var/www/example.com

Replace example.com with your domain.

If your shared hosting account supports SSH, transfer the files directly using rsync. Run this command on the VPS:

sudo rsync -avz --progress \
-e ssh \
USERNAME@OLD_SERVER_IP:/home/USERNAME/public_html/ \
/var/www/example.com/

Replace the username, old server address, and source directory with the values supplied by your hosting provider.

If SSH is unavailable, upload the website backup to the VPS using SFTP and extract it:

sudo tar -xzf /root/website-backup.tar.gz \
-C /var/www/example.com/

Adjust the archive location as necessary. Verify that the extracted files are in the correct website root, not inside an additional nested directory.

Step 5: Create and Import the Database

Generate a strong password:

openssl rand -hex 24

Open MariaDB:

sudo mariadb

Create a database and user, replacing the password placeholder:

CREATE DATABASE website CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

CREATE USER 'websiteuser'@'localhost'
IDENTIFIED BY 'REPLACE_WITH_STRONG_PASSWORD';

GRANT ALL PRIVILEGES ON website.*
TO 'websiteuser'@'localhost';

EXIT;

Copy the exported SQL file to the VPS, then import it:

mariadb -u websiteuser -p website \
< /root/website-database.sql

Update your website's database configuration with the new credentials.

For WordPress, edit wp-config.php and update DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST.

Step 6: Configure Nginx on the VPS

Detect your installed PHP-FPM socket:

ls /run/php/*-fpm.sock

Create an Nginx virtual host. Replace the domain and PHP socket with your actual values:

sudo nano /etc/nginx/sites-available/example.com

Add:

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/PHP_VERSION-fpm.sock;
    }

    location ~ /\. {
        deny all;
    }

    location ~* /(?:uploads|files)/.*\.php$ {
        deny all;
    }
}

Replace PHP_VERSION with the installed PHP-FPM version. This example uses WordPress-compatible routing; other PHP frameworks may require different Nginx rules.

Enable the website and verify the configuration:

sudo ln -s /etc/nginx/sites-available/example.com \
/etc/nginx/sites-enabled/example.com

sudo chown -R www-data:www-data /var/www/example.com

sudo nginx -t && sudo systemctl reload nginx

Review application-specific file permissions before applying ownership changes to an existing multi-user environment.

Step 7: Test Your Website Before Changing DNS

One of the most important migration steps is testing the new VPS while your domain still points to the original hosting provider.

You can test HTTP routing directly using curl:

curl -I --resolve example.com:80:NEW_VPS_IP \
http://example.com

Replace NEW_VPS_IP with your VPS public IPv4 address.

For full browser testing, temporarily map your domain to the new VPS IP in your computer's hosts file. This allows you to inspect the migrated website without changing public DNS.

Check:

• Homepage and internal pages.
• Images, CSS, and JavaScript files.
• Database connectivity.
• WordPress administrator login, if applicable.
• Contact forms and outgoing email.
• Application logs and PHP errors.

For HTTPS testing before DNS cutover, install a valid certificate using a supported DNS challenge or another certificate validation method. Do not bypass certificate verification when evaluating production readiness.

Step 8: Configure Free SSL on the New VPS

Install Certbot:

sudo apt install -y snapd
sudo snap install --classic certbot

Once the domain resolves to the new VPS and ports 80/443 are reachable, request a free Let's Encrypt certificate:

sudo /snap/bin/certbot --nginx \
-d example.com -d www.example.com

sudo /snap/bin/certbot renew --dry-run

Only include domain names that resolve correctly to the VPS.

Important: HTTP-01 certificate validation may fail before DNS is updated. For a certificate before cutover, consider DNS-01 validation, which requires control over the domain's DNS records.

Step 9: Reduce DNS TTL Before Migration

To minimize the transition period, reduce the DNS TTL for the records you intend to change.

For example, change the TTL from 3600 seconds to 300 seconds, preferably at least one previous TTL period before the migration.

This helps recursive DNS resolvers refresh records more quickly, although some clients and resolvers may retain cached information longer.

If your DNS is managed through Cloudflare or another DNS provider, make the changes in that provider's DNS management interface.

Step 10: Perform the Final Synchronization

For websites that accept orders, comments, registrations, or other database writes, a final synchronization is essential.

Before switching DNS:

1. Enable maintenance mode or temporarily stop writes on the original website.
2. Take a final database export.
3. Synchronize files uploaded or modified since the initial transfer.
4. Import the final database into the new VPS.
5. Verify that the destination website works correctly.
6. Keep the original website from accepting new writes during the transition.

If SSH access is available, repeat the rsync transfer:

sudo rsync -avz \
-e ssh \
USERNAME@OLD_SERVER_IP:/home/USERNAME/public_html/ \
/var/www/example.com/

For databases, take a fresh export after writes have stopped, then restore it to the destination using the same database import procedure.

Do not independently accept writes on both servers. Without database replication or another coordinated migration mechanism, this can create inconsistent data.

Step 11: Update DNS to Your New VPS

Once the new website has been tested, update the domain's DNS records:

If your domain uses an AAAA record, update or remove it as appropriate. An outdated IPv6 record can direct some visitors to the old server.

Check DNS resolution:

dig +short example.com A
dig +short example.com AAAA
dig +short www.example.com

DNS propagation time depends on caching, TTL values, and resolver behavior.

Step 12: Verify the Migration

After DNS changes, verify the public website and monitor the new VPS:

curl -I https://example.com

sudo nginx -t
sudo systemctl status nginx mariadb --no-pager

sudo tail -n 50 /var/log/nginx/error.log

free -h
df -h

Test the website from multiple networks and confirm that database-backed functionality works.

Keep your old hosting account active until DNS has settled and you have confirmed that the migrated website operates correctly.

Important: Don't Forget Email Hosting

Moving your website does not automatically migrate your email accounts.

Before changing DNS, review your existing:

• MX records.
• SPF, DKIM, and DMARC records.
• Email accounts and mailboxes.
• SMTP settings used by your website.

If email will remain with your existing provider, preserve the relevant DNS records and confirm that the old hosting account can continue providing email service.

If email is also being migrated, plan that as a separate process to avoid losing messages.

How to Roll Back a Failed VPS Migration

If the new website experiences serious problems, you may need to return traffic to the original server.

1. Stop new writes on the destination.
2. Determine whether any new orders, registrations, or other changes need to be reconciled.
3. Restore the original DNS records.
4. Verify the original website and database.
5. Investigate the destination server before attempting another migration.

Warning: Changing DNS back does not automatically synchronize databases. Any changes accepted on the new server must be handled before rollback to avoid data loss.

Common Website Migration Problems

Website Shows 502 Bad Gateway

Check PHP-FPM status and verify that the Nginx configuration references the correct PHP socket.

Error Establishing a Database Connection

Verify the database credentials, database host, imported data, and MariaDB service status.

Website Still Loads from the Old Server

Check DNS caching, A and AAAA records, CDN configuration, and local hosts-file overrides.

WordPress Images or Links Point to the Old Domain

Review the WordPress site URL settings and database content. If changing domains, use a WordPress-aware search-and-replace tool rather than blindly replacing text inside SQL files.

SSL Certificate Is Invalid

Confirm that the correct domain resolves to the VPS and that the web server presents a certificate covering that hostname.

Contact Forms Stop Sending Email

Review SMTP settings, mail-provider authentication, SPF/DKIM records, and outbound email restrictions on the new VPS.

Related Solution: Upgrade to an Owned Networks KVM VPS

Frequently Asked Questions

Can I migrate from shared hosting to a VPS without downtime?

In many cases, downtime can be minimized by preparing and testing the VPS before changing DNS. However, dynamic websites may require a maintenance window or coordinated database migration to prevent data loss.

How long does a website migration take?

A small website may take less than an hour to transfer, while larger websites or databases can require several hours. DNS caching, testing, and application complexity affect the overall timeline.

Can I migrate WordPress from cPanel to an Ubuntu VPS?

Yes. Export your WordPress files and database, configure the new web server, import the database, update WordPress configuration, and test before changing DNS.

Will my website become faster after moving to a VPS?

A VPS provides dedicated resource allocations and greater configuration control, but performance depends on CPU, RAM, storage, caching, application optimization, and server configuration.

Do I need to transfer my domain name?

No. You can keep your domain registered with its current registrar and simply update its DNS records to point to the new VPS.

Will my email accounts migrate automatically?

No. Email migration is separate from website migration. Preserve or update MX and email authentication records as required.

What VPS resources do I need?

For a small PHP or WordPress website, 2 GB RAM may be sufficient, while 4 GB or more provides additional capacity for databases, caching, and plugins. Actual requirements depend on traffic and workload.

Should I cancel shared hosting immediately after migration?

No. Keep the original account active until DNS changes have settled, the website has been verified, and any email or data dependencies have been resolved.

Conclusion

Migrating from shared hosting to a VPS involves preparing the destination server, transferring website files and databases, configuring the web server, testing the application, and carefully updating DNS.

By preparing the VPS before cutover and coordinating the final synchronization, you can minimize downtime and reduce the risk of data loss.

Ready to upgrade? Explore Owned Networks KVM VPS Hosting and choose a server configuration that matches your website's requirements.

Last reviewed: November 2026.