“`html

VPS MIGRATION GUIDE 2026

Website Migration to a New VPS: Complete Zero-Downtime Transfer Guide

Learn how to move website files, databases, domains, email settings, SSL certificates, applications, and server configurations to a new VPS while reducing downtime and protecting your data.

Written by Hamza

Why Migrate a Website to a New VPS?

Moving a website to a new virtual private server may be necessary when the existing server no longer provides enough performance, storage, memory, network quality, security, or administrative control.

A migration may also be part of changing hosting providers, upgrading from shared hosting, moving to a different data-center location, replacing an outdated operating system, or separating an important website from other projects.

A successful migration involves more than copying website files. The database, users, permissions, web server, PHP version, runtime dependencies, scheduled tasks, DNS records, email configuration, SSL certificate, firewall rules, and application environment may all need to be recreated.

This guide explains a structured migration process designed to minimize service interruption and make rollback possible if the new VPS does not work as expected.

Quick Migration Summary

Audit the old server: Identify files, databases, applications, DNS records, email services, and dependencies.
Back up everything: Create independent copies before changing the original server.
Prepare the new VPS: Install the operating system, web server, database, PHP, firewall, and required packages.
Transfer website data: Copy files with Rsync, SCP, SFTP, or a hosting migration tool.
Move the database: Export it from the old server and import it into the new environment.
Test before DNS changes: Use a local hosts-file entry or temporary subdomain.
Lower DNS TTL: Reduce the time that old DNS responses remain cached.
Perform a final synchronization: Copy recent changes immediately before the DNS switch.
Update DNS: Point the domain to the new VPS IP address.
Monitor and retain the old VPS: Do not cancel the original server immediately.

How the Migration Process Works

The safest migration process prepares the new server before changing public DNS. This allows you to test the website privately while visitors continue using the original VPS.

Audit the old VPS

↓

Create complete backups

↓

Prepare and secure the new VPS

↓

Copy website files and databases

↓

Configure the web server and application

↓

Test through a hosts-file entry

↓

Perform the final synchronization

↓

Point DNS to the new VPS

↓

Monitor traffic, errors, email, and SSL

↓

Retain the old server for rollback

Common Reasons for Moving to a New VPS

More Performance

The existing server may not provide enough CPU, RAM, storage speed, or network capacity.

Better Location

A server closer to the target audience can reduce latency and improve loading performance.

Improved Reliability

Frequent downtime, unstable storage, or poor network routing may justify changing infrastructure.

More Control

A new VPS can provide administrative access, custom software, and greater configuration flexibility.

Security Upgrade

Migration can replace an unsupported operating system or a server with uncertain security history.

Provider Change

Pricing, support, policies, locations, or infrastructure requirements may lead to a new provider.

Main Types of Website Migration

Migration Type	What Is Moved?	Complexity
Static website	HTML, CSS, JavaScript, images, downloads, and web server configuration.	Low
WordPress website	WordPress files, uploads, themes, plugins, database, and configuration.	Moderate
Dynamic application	Application code, database, dependencies, environment variables, workers, queues, and scheduled tasks.	Moderate to high
Complete server migration	Multiple websites, databases, accounts, mailboxes, DNS settings, services, and server configurations.	High
Control-panel migration	Accounts and services moved with tools provided by compatible hosting panels.	Depends on panel compatibility

STEP 1

Audit the Existing Website and VPS

Before ordering or configuring the new VPS, document the current environment. The replacement server should support the website’s software, traffic, storage, and operational requirements.

Operating system and version
Web server and version
PHP, Python, Node.js, Java, Ruby, or other runtime versions
Database engine and version
Website document-root directories
Database names and database users
Environment variables and configuration files
SSL certificates and renewal method
Cron jobs and scheduled tasks
Background workers, queues, and process managers
Firewall rules and exposed ports
Email accounts and mail-routing records
DNS records and nameservers
Disk usage, database size, and expected traffic

Important:
Do not assume that copying the public website directory is enough. Important configuration files, hidden files, database credentials, uploads, scheduled tasks, and application secrets may be stored elsewhere.

STEP 2

Create Complete Backups

Create independent backups before changing either server. Store at least one copy outside the old VPS so that a server failure does not destroy both the live website and its backup.

Website Files

Back up public files, uploads, themes, plugins, application code, and hidden configuration files.

Databases

Export every database using a database-native backup tool.

Configuration

Save web server, PHP, firewall, application, DNS, cron, and service configurations.

Mail Data

Back up mailboxes, aliases, forwarding rules, filters, and mail authentication records when email is hosted locally.

Example Website Archive

sudo tar -czf website-files-backup.tar.gz /var/www/example.com

Example MySQL or MariaDB Export

mysqldump -u database_user -p database_name > database-backup.sql

Example PostgreSQL Export

pg_dump -U database_user -F c database_name > database-backup.dump

Verify the backups:
Confirm that the files are not empty, check their sizes, inspect archive contents, and test database restoration when possible.

STEP 3

Choose and Prepare the New VPS

The new server should provide enough resources for the current website and expected growth. Avoid choosing a configuration based only on the lowest advertised price.

Resource	Why It Matters
CPU	Handles application code, PHP requests, database operations, compression, and background jobs.
RAM	Supports the operating system, database, web server, caching, and concurrent visitors.
NVMe storage	Improves file access, database performance, cache operations, and backup speed.
Network location	Affects latency and loading performance for the target audience.
Bandwidth and port speed	Affect content delivery, traffic capacity, backups, and migration speed.
Backup options	Provide recovery options after mistakes, compromise, or infrastructure failure.

Update the operating system before installing the required services:

sudo apt update

sudo apt upgrade -y

Secure the New VPS Before Migration

A newly created VPS may receive automated login attempts and internet scans shortly after activation. Apply basic security controls before uploading sensitive website data.

Create a non-root administrative account.
Use SSH keys for authentication.
Disable direct root login when appropriate.
Install operating-system security updates.
Allow only required firewall ports.
Install login protection or rate-limiting tools.
Restrict database services from public access.
Configure time synchronization.
Enable system and application logging.
Set up external backups before launching the website.

Example UFW Configuration

sudo ufw allow OpenSSH

sudo ufw allow 80/tcp

sudo ufw allow 443/tcp

sudo ufw enable

sudo ufw status

Avoid losing access:
Confirm that SSH access is allowed before enabling a firewall or changing the SSH configuration.

STEP 4

Install the Required Server Software

Install the web server, database engine, runtime, extensions, and supporting tools required by the website.

Example Nginx Installation

sudo apt install nginx -y

sudo systemctl enable nginx

sudo systemctl start nginx

Example MariaDB Installation

sudo apt install mariadb-server -y

sudo systemctl enable mariadb

sudo systemctl start mariadb

Example PHP Installation

sudo apt install php-fpm php-mysql php-cli php-curl php-xml php-mbstring php-zip php-gd -y

Compatibility check:
Confirm the required runtime versions before installation. A website developed for one PHP, database, Node.js, or framework version may fail on a significantly different version.

STEP 5

Transfer Website Files to the New VPS

Several tools can transfer website files. Rsync is especially useful because it can preserve permissions and efficiently copy only changed files during the final synchronization.

Method	Best Use	Consideration
Rsync	Linux-to-Linux migration and repeated synchronization.	Requires SSH access between servers.
SCP	Simple copying of files or archives.	Less efficient for repeated synchronization.
SFTP	Manual transfer with a graphical client.	Large migrations can take longer and permissions may need review.
Control-panel tool	Moving accounts between compatible hosting panels.	Review what the automated tool includes and excludes.

Example Rsync Transfer

rsync -avz –progress /var/www/example.com/ \

new_admin@NEW_VPS_IP:/var/www/example.com/

Example SCP Transfer

scp website-files-backup.tar.gz new_admin@NEW_VPS_IP:/home/new_admin/

Check ownership:
After transferring files, confirm that the web server user can read the website files and write only to directories that require uploads or cache data.

STEP 6

Create and Import the Database

Create the destination database and database user on the new VPS. Use strong credentials and grant only the permissions required by the application.

Example MySQL or MariaDB Setup

CREATE DATABASE website_database CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER ‘website_user’@’localhost’

IDENTIFIED BY ‘USE_A_STRONG_PASSWORD’;
GRANT ALL PRIVILEGES ON website_database.*

TO ‘website_user’@’localhost’;
FLUSH PRIVILEGES;

Import the Database

mysql -u website_user -p website_database < database-backup.sql

PostgreSQL Import Example

pg_restore -U website_user -d website_database database-backup.dump

Update the website configuration with the new database name, username, password, host, and port when these details differ from the old server.

STEP 7

Configure the Web Server

Configure Nginx, Apache, Caddy, or another server to recognize the website’s domain and serve the correct document root.

Example Nginx Server Block

server {

listen 80;

listen [::]:80;server_name example.com www.example.com;
root /var/www/example.com/public;

index index.php index.html index.htm;
location / {

try_files $uri $uri/ /index.php?$query_string;

}
location ~ \.php$ {

include snippets/fastcgi-php.conf;

fastcgi_pass unix:/run/php/php-fpm.sock;

}
location ~ /\.ht {

deny all;

}

}

Test the configuration before reloading Nginx:

sudo nginx -t

sudo systemctl reload nginx

Adjust the example:
The correct document root, index files, PHP socket, rewrite rules, and security configuration depend on your operating system and application.

Recreate Application Services and Settings

Dynamic applications may rely on services that are not stored inside the main website directory.

Component	Migration Requirement
Environment variables	Transfer secrets, database credentials, API keys, application URLs, and runtime settings securely.
Cron jobs	Recreate scheduled backups, reports, maintenance, publishing, and cleanup tasks.
Queue workers	Configure process managers and background job services.
Cache services	Install and configure Redis, Memcached, or application-specific caching.
File permissions	Set correct ownership for uploads, cache, logs, sessions, and generated files.
External integrations	Update IP allowlists, webhooks, payment callbacks, storage endpoints, and API restrictions.

STEP 8

Test the Website Before Updating DNS

Do not point public traffic to the new VPS until the website has been tested. You can temporarily map the domain to the new server on your own computer by editing the local hosts file.

Example Hosts-File Entry

NEW_VPS_IP example.com

NEW_VPS_IP www.example.com

After saving the entry, your computer will load the domain from the new VPS while normal visitors continue using the old server.

Pre-Migration Testing Checklist

Homepage and important landing pages
Images, stylesheets, scripts, fonts, and downloads
Contact forms and email notifications
User registration and login
Administrative dashboard
Search and filtering functions
Checkout and payment flow
Database creation and update operations
File uploads and generated content
Scheduled tasks and background workers
API endpoints and webhooks
Redirects and custom error pages
Mobile and desktop layouts
Server and application logs

Lower the DNS TTL Before the Migration

Time to Live controls how long DNS resolvers may cache a record. Lowering the TTL before migration can help visitors receive the new VPS address more quickly after the DNS update.

Migration Stage	Suggested Action
Before migration	Lower the A and AAAA record TTL to a value such as 300 seconds when the DNS provider permits it.
During migration	Update the domain records to the new VPS IP address.
After stabilization	Increase the TTL after the new server has been confirmed stable.

Plan ahead:
Lowering the TTL immediately before the DNS switch may not affect DNS responses that were already cached with the previous higher TTL.

STEP 9

Perform the Final Data Synchronization

Content may change while you are preparing the new server. New orders, comments, form submissions, customer accounts, uploads, and database updates can occur after the first backup.

Immediately before changing DNS, perform a final file and database synchronization. For highly dynamic websites, temporarily enable maintenance or read-only mode to prevent writes during the final database export.

Example Final Rsync

rsync -avz –delete /var/www/example.com/ \

new_admin@NEW_VPS_IP:/var/www/example.com/

Use –delete carefully:
This option removes destination files that are not present at the source. Test the command without destructive options and verify both paths before using it.

STEP 10

Point the Domain to the New VPS

Open the domain’s DNS management panel and replace the old VPS address with the new server’s public IP address.

Record	Host	New Value
A	@	New VPS IPv4 address
CNAME	www	example.com
AAAA	@	New VPS IPv6 address, when correctly configured

Verify the DNS response with:

dig example.com A

dig example.com AAAA

dig www.example.com

nslookup example.com

STEP 11

Install or Reissue the SSL Certificate

After the domain resolves to the new VPS and ports 80 and 443 are accessible, install a valid SSL certificate.

Install Certbot for Nginx

sudo apt install certbot python3-certbot-nginx -y

Request the Certificate

sudo certbot –nginx -d example.com -d www.example.com

Test Renewal

sudo certbot renew –dry-run

Check every hostname:
Make sure the certificate includes the root domain, www version, and any subdomains served from the new VPS.

Migrating Email Services

Website migration and email migration are separate tasks. If email is hosted by a third-party provider, keep the existing MX and authentication records unchanged.

When email is hosted on the old VPS, you may need to move mailboxes, aliases, forwarding rules, filters, spam settings, DKIM keys, and mail server configurations.

Preserve MX records until the replacement mail server is ready.
Recreate all mailbox accounts and aliases.
Transfer existing mailbox data.
Configure correct reverse DNS with the VPS provider.
Recreate SPF, DKIM, and DMARC records.
Confirm that outbound port restrictions do not block mail delivery.
Test incoming and outgoing messages before changing MX records.
Review spam reputation and delivery logs.

Safer option:
When business email already works through an external service, changing only the website’s A record should not affect mail delivery as long as MX and TXT records remain unchanged.

Special Considerations for WordPress Migration

A WordPress migration normally includes the WordPress core files, themes, plugins, uploads, configuration file, and database.

Copy the complete WordPress directory, including hidden files.
Export and import the WordPress database.
Update database credentials in wp-config.php.
Confirm that the PHP version and extensions are compatible.
Recreate rewrite rules and permalink configuration.
Verify upload-directory permissions.
Clear plugin, page, object, and CDN caches.
Test contact forms, SMTP, logins, media, and scheduled tasks.
Review serialized database values before replacing URLs.

WordPress Search and Replace

When the domain remains the same, a database URL replacement may not be necessary. When the domain changes, use a WordPress-aware tool that safely handles serialized data.

wp search-replace ‘https://old-example.com’ \

‘https://new-example.com’ \

–all-tables \

–dry-run

Run a dry test first:
Review the proposed changes before performing a permanent replacement and keep a recent database backup.

How to Minimize Website Downtime

Prepare First

Configure and test the new VPS before changing public DNS.

Lower TTL

Reduce DNS caching in advance of the migration.

Final Sync

Copy the latest files and database changes immediately before switching DNS.

Maintenance Mode

Temporarily stop new writes during the final database export when required.

Keep Both Servers

Leave the original VPS online while DNS caches refresh.

Monitor Continuously

Watch errors, database activity, traffic, SSL, email, and system resources.

STEP 12

Monitor the New VPS After Migration

Continue monitoring after DNS begins sending visitors to the new server. Some problems appear only under real traffic.

Area	What to Check
Availability	Website uptime, HTTP response codes, SSL validity, and external monitoring.
Performance	CPU, memory, disk usage, storage latency, database load, and response time.
Application	Login, checkout, forms, uploads, API requests, scheduled jobs, and background workers.
Logs	Web server errors, application exceptions, authentication failures, and database warnings.
DNS	Correct A, AAAA, CNAME, MX, SPF, DKIM, DMARC, and verification records.
Backups	Automatic backup completion, retention, off-server storage, and restoration testing.

Common Migration Problems and Solutions

Problem	Possible Cause	Recommended Check
Blank page or server error	Missing PHP extension, runtime error, or incompatible software version	Review application, PHP, and web server logs.
Database connection error	Incorrect database credentials, permissions, hostname, or database service status	Test the database login directly and verify application configuration.
Images or CSS are missing	Incomplete file transfer, incorrect paths, permissions, or mixed-content URLs	Inspect browser errors, paths, file ownership, and HTTPS URLs.
Uploads fail	Incorrect directory permissions or PHP upload limits	Check writable directories, disk capacity, and runtime limits.
Domain still opens the old VPS	DNS caching or an unchanged proxy record	Check authoritative DNS and test through multiple resolvers.
HTTPS certificate fails	Domain not resolving to the new VPS or port 80 is blocked	Verify DNS, firewall rules, and web server accessibility.
Some visitors cannot connect	Broken IPv6 or an outdated AAAA record	Test IPv6 connectivity or remove the incorrect AAAA record.
Email stops working	MX, SPF, DKIM, DMARC, or mail-host records were changed	Compare the current DNS zone with the pre-migration backup.
Scheduled jobs do not run	Cron jobs or worker services were not recreated	Review cron entries, timers, process managers, and service logs.

Useful Post-Migration Commands

Test Nginx

sudo nginx -t

Check Listening Ports

sudo ss -tulpn

Check Disk Space

df -h

Check Memory

free -h

View Nginx Errors

sudo tail -f /var/log/nginx/error.log

Test HTTP Response

curl -I https://example.com

Prepare a Rollback Plan

A rollback plan defines how to restore service on the original VPS if the new environment develops a serious problem.

Keep the original VPS unchanged and online.
Record the old IP address and original DNS settings.
Keep pre-migration file and database backups.
Document the exact time of the final database export.
Monitor whether users are writing data to the new database.
Understand how recent data would be handled after reverting.
Restore the old DNS address when rollback is necessary.
Investigate the new VPS privately before attempting another switch.

Data warning:
Rolling back after customers have created new orders, accounts, uploads, or messages on the new server can cause data loss unless those changes are synchronized back to the old database.

When Should You Cancel the Old VPS?

Do not cancel the original VPS immediately after updating DNS. Retain it until the new server has been tested under normal traffic and old DNS caches have expired.

Confirm that public DNS consistently returns the new VPS address.
Verify that website traffic is reaching the new server.
Confirm that forms, orders, uploads, logins, APIs, and scheduled jobs work.
Confirm that email and third-party integrations remain functional.
Verify automatic backups on the new VPS.
Retain a final archive of the old server.
Remove sensitive data before releasing the old VPS.
Revoke old credentials, API keys, and access permissions when appropriate.

After decommissioning, update internal documentation so that administrators do not continue using the old server address or credentials.

Complete VPS Migration Checklist

Audit the current website and server environment.
Record DNS, email, application, database, and firewall settings.
Create complete off-server backups.
Verify that the backups can be opened or restored.
Choose a VPS with sufficient resources and a suitable location.
Update and secure the new operating system.
Install the web server, database, runtimes, and dependencies.
Create the website directories and database users.
Transfer website files.
Export and import the database.
Update application credentials and environment variables.
Recreate cron jobs, workers, queues, and cache services.
Configure Nginx, Apache, Caddy, or another web server.
Test the configuration before reloading services.
Test the new VPS through a local hosts-file entry.
Lower DNS TTL before the final migration.
Enable maintenance mode when data consistency requires it.
Perform the final file and database synchronization.
Point the domain to the new VPS.
Install or reissue SSL certificates.
Test website functionality from external networks.
Monitor logs, resources, DNS, SSL, email, and application activity.
Keep the old VPS available for rollback.
Confirm that new automatic backups are working.
Securely decommission the original server after stabilization.

Frequently Asked Questions

Can I migrate a website to another VPS without downtime?

Downtime can often be minimized by preparing the new VPS in advance, testing privately, lowering DNS TTL, performing a final synchronization, and keeping both servers online during the transition.

How long does a VPS migration take?

The duration depends on website size, database activity, application complexity, transfer speed, DNS caching, testing requirements, and whether email is included.

Should I change nameservers during migration?

Not necessarily. When the existing DNS provider will continue managing the domain, update only the A and AAAA records. Change nameservers only when moving the complete DNS zone to another provider.

Can I copy the SSL certificate from the old VPS?

A certificate and its private key can sometimes be transferred securely, but reissuing the certificate on the new server is often simpler. Protect private keys and never transfer them through an insecure channel.

Will moving the website affect email?

Updating the website’s A record should not affect external email hosting when MX and TXT records remain unchanged. Email hosted on the old VPS requires a separate migration.

When can I delete the old VPS?

Keep it until DNS has stabilized, the new server has operated successfully under real traffic, backups are working, and you are confident that rollback is no longer required.

Can several websites be migrated to the same VPS?

Yes. Each domain can have its own document root, web server configuration, database, SSL certificate, user permissions, and resource requirements.

What is the safest website migration method?

The safest method uses verified backups, a fully prepared destination server, private testing, a documented final synchronization, controlled DNS changes, monitoring, and a tested rollback plan.

Final Thoughts

Migrating a website to a new VPS requires careful planning, complete backups, compatible software, secure configuration, accurate data transfer, private testing, and controlled DNS changes.

The most reliable approach is to build and test the replacement environment while the original website remains online. Once the new VPS is ready, perform a final synchronization, update DNS, install SSL, and monitor the service under real traffic.

Dynamic websites require special attention because databases, orders, accounts, uploads, comments, messages, and background jobs can change during the migration. Maintenance mode or a short read-only period may be necessary to protect data consistency.

Keep the original VPS available until the new server has proven stable. A documented rollback plan and verified off-server backups provide essential protection if the migration produces unexpected errors.

Technical note:
Commands, package names, PHP sockets, directory structures, database tools, firewall settings, DNS interfaces, and certificate procedures vary between operating systems, applications, and hosting providers. Replace all example values with your actual information, verify backups, test commands in a non-critical environment, and review official documentation before modifying a production server.

Our data centers