How to move a website from shared hosting to a VPS

The move itself takes a couple of hours; the mistakes usually happen around it: a forgotten cron job, .htaccess rules that nginx does not read, an AAAA record with the old address, or mail that disappeared along with the IP change. Below is the order of steps with commands and checks for a PHP and MySQL site.

Updated 31.10.2026 · Find a VPS for your needs →

This article is about how to move. Whether to move at all and which server to get is covered in When to move from shared hosting to a VPS. Here we assume the VPS is already bought and the site runs on WordPress, Bitrix, Laravel or another PHP engine with a MySQL database. For other stacks the order is the same, only the commands change.

Timeline: a move in four stages

  1. Two days before: write down everything that runs on the hosting and lower the TTL of the DNS records.
  2. A day before: prepare the server, copy the files and the database, test the site at the new address.
  3. Moving day: close the site to writes, transfer the fresh data, change DNS.
  4. One to two weeks after: keep the hosting running as a fallback.

What to write down on the hosting

Almost all problems after a move are things that worked on the hosting by themselves and were forgotten. Go through the hosting control panel and write down:

  • The PHP version and extensions. You can see them in the panel or over SSH with php -v and php -m. Install the same version on the VPS, and upgrade PHP separately, later.
  • The database version and size, and the table encoding.
  • Cron jobs: what runs and how often. File paths on the VPS will be different.
  • Rules in .htaccess: redirects, friendly URLs, folder access restrictions.
  • Mail: mailboxes, forwards, where the MX records point.
  • Subdomains and all DNS records, including TXT records for service verification.
  • External services that know the site's IP. Payment systems, 1C data exchange, partner APIs and mail services often accept requests only from allowed addresses. The new IP has to be added there in advance.

A day or two before the move, lower the TTL of the domain's A and AAAA records to 300 seconds. Then on switch-over day the new address will propagate in minutes rather than a day.

Prepare the server

Start with basic protection: updates, key login, a firewall. All of this is collected in First 10 steps after buying a VPS: security. Then there are two paths.

With a control panel. ISPmanager, FASTPANEL or aaPanel install the web server, the right PHP version and the database in a few clicks and give you an interface familiar from shared hosting. Plans with them: VPS with ISPmanager, VPS with FASTPANEL, VPS with aaPanel.

Without a panel. On Ubuntu and Debian the minimal set is installed with one command; packages without a version number pull in the PHP that ships with the system:

apt install nginx mariadb-server php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-zip php-intl

If the hosting had an older or newer PHP version than the system's, install it from third-party repositories with PHP packages for Ubuntu and Debian.

Keep in mind the main difference from shared hosting: nginx does not read .htaccess. Redirects and friendly URLs have to be moved into the site configuration. For WordPress the main rule looks like this: try_files $uri $uri/ /index.php?$args;. If there are many rules, it is easier to put Apache behind nginx: that is how most panels work, and .htaccess keeps working.

Move the files

If the hosting has SSH access, the fastest way is to pull the files directly from the VPS with rsync:

rsync -avz user@old-host.example:~/public_html/ /var/www/example.com/

Running the same command again transfers only what has changed, which will come in handy on moving day. If there is no SSH, there are two options: build an archive in the panel's file manager and download it to the server with wget, or fetch the files over FTP with the lftp utility:

lftp -u user old-host.example -e "mirror --parallel=4 public_html /var/www/example.com; quit"

Plain FTP sends the password in clear text, so if the hosting supports SFTP or FTPS, use them. After copying, give the files to the web server user and set the usual permissions:

chown -R www-data:www-data /var/www/example.com
find /var/www/example.com -type d -exec chmod 755 {} +
find /var/www/example.com -type f -exec chmod 644 {} +

Move the database

Make a dump on the hosting. Over SSH:

mysqldump --single-transaction --default-character-set=utf8mb4 -u user -p dbname | gzip > db.sql.gz

Without SSH the dump is exported through phpMyAdmin, but it may not cope with large databases because of the hosting's time limits; in that case ask support for a dump or make it in parts. On the VPS, create the database and the user and load the dump:

mysql -e "CREATE DATABASE site CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'site'@'localhost' IDENTIFIED BY 'strong_password';
GRANT ALL PRIVILEGES ON site.* TO 'site'@'localhost';"
zcat db.sql.gz | mysql site

A common error during import is Unknown collation: 'utf8mb4_0900_ai_ci'. It means the dump was made in MySQL 8, while the VPS runs MariaDB, which does not know this collation. Either install the same DBMS on the VPS as on the hosting, or replace the collation in the dump with utf8mb4_unicode_ci.

Then put the new database credentials into the site settings: for WordPress that is wp-config.php, for Bitrix /bitrix/.settings.php and /bitrix/php_interface/dbconn.php, for Laravel the .env file. The database server is now localhost.

Move the cron jobs

Run jobs as the site user, not as root: crontab -u www-data -e. Check the paths: on the hosting the site lived in something like /home/user/public_html, on the VPS in /var/www/example.com, and the path to PHP may differ too (which php). Separately check the tasks the host ran for you: Bitrix agents on cron, 1C data exchange, sending emails from the queue.

Test the site before changing DNS

Visitors are still going to the hosting, while you can open the new server on your own machine. Map the domain to the server's IP in your computer's hosts file (/etc/hosts on Linux and macOS, C:\Windows\System32\drivers\etc\hosts on Windows):

203.0.113.10  example.com www.example.com

Go through the home page, catalog, product page, search, forms, cart and admin login, and upload an image. Watch the error log at the same time: tail -f /var/log/nginx/error.log. To quickly check the server's response without a browser: curl -I --resolve example.com:80:203.0.113.10 http://example.com/.

Typical problems at this step:

  • 502 Bad Gateway: nginx cannot reach PHP-FPM, because the socket path in the site configuration does not match the one in the PHP pool settings.
  • A blank page or error 500: a PHP extension is missing. Its exact name will be in the error log.
  • Large files do not upload: by default nginx limits the request body to 1 MB (client_max_body_size), and PHP limits it with upload_max_filesize and post_max_size.
  • Links lead to 404: the .htaccess rules were not moved.

TLS certificate

The usual domain validation for a free certificate goes over HTTP to the address DNS currently points to, that is, to the hosting. So before the switch there are three options:

  • Get a certificate via DNS validation: certbot certonly --manual --preferred-challenges dns -d example.com -d www.example.com. certbot will ask you to add a TXT record. Such a certificate does not renew itself, so after the move issue a regular one.
  • Temporarily move the current certificate and key from the hosting, if the panel lets you export them.
  • Change DNS and immediately issue a certificate with certbot --nginx -d example.com -d www.example.com. For a few minutes the site will show an error over HTTPS; for a small site this is acceptable.

After issuing, check automatic renewal: certbot renew --dry-run.

Moving day

  1. Close the site to writes: turn on maintenance mode or at least stop taking orders and comments. For a shop this is a few minutes.
  2. Run the same rsync command once more: it will transfer only the changes.
  3. Make a fresh database dump and load it on the VPS over the old one.
  4. Change the A record of the domain and www to the server's IP. If the domain has an AAAA record with the hosting's IPv6 address, replace it with the server's IPv6 or delete it, otherwise some visitors will keep landing on the old server.
  5. Check that the new records are visible: dig +short example.com A @8.8.8.8 and dig +short example.com AAAA @8.8.8.8.
  6. Open the site for writes, now on the VPS.

Do not lose your mail

This is the most common trouble with a move. Check where MX points: dig +short example.com MX. If it is example.com or mail.example.com that resolves to the same IP as the site, changing the A record will send mail to the VPS, where there is no mail server. Before the switch, create a separate record for mail with the hosting's old IP and put it in MX, or better, move the domain's mail to a separate mail service in advance.

If the site sends emails (orders, password resets), check them after the move. Emails from a new IP without an SPF record will land in spam: either add the server's IP to SPF, or send emails through a mail service's SMTP. Your own mail server on a VPS is a separate task; plans for it are in VPS for a mail server.

After the move, and rollback

Do not shut down the hosting for one or two weeks. In the first hours, check the old database: if someone placed an order on the old server between the final dump and the DNS change, move it over by hand. After a couple of days, look at the hosting's access log: if people are still coming there, the old address is left somewhere, most often in the AAAA or www record.

Rollback is simple while the hosting is running: put the old IP back in DNS, and thanks to the short TTL visitors will return to the hosting within minutes. When everything is stable, set the TTL back to normal values, set up backups following VPS backups: strategies and tools, and add external monitoring. Plans for websites: VPS for a website, VPS for WordPress, VPS for an online store, VPS for Bitrix. For a first trial build, hourly billing is convenient.

FAQ

How long does it take to move a website to a VPS?

For an ordinary CMS site, preparing the server, copying and testing take from a couple of hours to a day. Moving day itself, with the final sync and DNS change, takes about an hour, and the site is closed to writes for a few minutes.

Can I move a website without downtime?

Yes, if you lower the TTL of the DNS records in advance, build and test the site on the VPS via the hosts file, and on moving day close it to writes only for the duration of the final sync. Visitors can read the site the whole time.

How do I move a website if the hosting has no SSH?

Files as an archive from the panel's file manager or over FTP with lftp, the database as an export through phpMyAdmin. If the database is large and the export breaks off, ask the hosting support for a dump.

What happens to the domain's mail after the IP change?

If MX points to the domain itself or to a subdomain with the same IP as the site, mail will go to the VPS and be lost. Before the switch, point MX to a separate record with the old IP or move mail to a mail service.

Do I need to move the SSL certificate?

Not necessarily. A free certificate can be issued again: before the DNS change via a TXT record, after it via the usual HTTP validation. A paid certificate is moved together with its private key.

How do I roll back if something goes wrong on the VPS?

Put the hosting's old IP back in DNS. With a short TTL visitors will return within minutes, which is why the hosting is worth keeping on for one or two weeks after the move.

Plans on this topic

VPS for LaravelBest VPS hosting 2026

More in the guide

  • When to move from shared hosting to a VPSA VPS does not make a site faster by itself: it gives you resources and freedom, and with them the job of running a server. Here is how to tell that hosting has become too small, when the problem can be solved without moving, and how to migrate a site so visitors notice nothing.
  • VPS backups: strategies and toolsOn a VPS, backups are your job, even if the plan says "backups included". We go through what exactly to back up, why a host snapshot is not enough, how to set up restic or BorgBackup in half an hour, and how to make sure you can actually restore from a backup.
  • First 10 steps after buying a VPS: securityBots start guessing passwords on a new server within minutes of it getting a public IP. Below are ten steps that close the most common holes in about an hour: commands for Ubuntu and Debian, the differences for AlmaLinux and Rocky Linux, and the checks that keep you from locking yourself out of your own server.
  • How to choose a country for your serverPut the server where your visitors are. For an audience across Europe, Germany, the Netherlands and Finland are convenient; for North America, the US East Coast. If you serve EU users, keeping the data in the EU makes GDPR simpler. Price hardly decides it: at the same host a server in Frankfurt, Amsterdam or New York usually costs the same, and only Asia and Australia are noticeably more expensive.
  • Hourly billing: when it pays offHourly billing pays off if you need the server for less than three weeks a month: for a test, a build, a one-off heavy job. At most hosts an hour costs exactly the monthly price divided by 730 hours, so over a full month you hardly overpay. The overpayment hides elsewhere: hourly plans are dearer on average, and for a server that runs all year, monthly billing or a year paid in advance usually comes out cheaper.
  • How much RAM and how many cores a website needsMost websites are fine with 2 GB of memory and one or two cores; a shop with thousands of products needs 4 GB and two cores. Memory matters more than cores: when it runs out, the site slows down or crashes, while an extra core without memory adds almost nothing. Below I show how to work out the memory for your site and how to see what it actually uses.
  • KVM or OpenVZ: which to chooseIn 2026 KVM is almost always the right pick: it costs a dollar or two more per month than OpenVZ, but everything runs on it, from Docker to Windows. OpenVZ makes sense in one narrow case, explained below, and at the end you will find the commands to check your own server in a minute.
  • NVMe or SSD: does it matter for a websiteFor a small site the difference between NVMe and SSD is barely noticeable, because pages are served from memory rather than from disk. It shows up in shops and sites with a large database. At the same host NVMe costs only about $0.50–1 a month more, and sometimes less, so what usually decides it is not the disk type but its size and how the host has limited it.
  • What is a VPS, in plain EnglishA VPS is a slice of a powerful physical server that you rent and that behaves like a separate computer, with its own operating system, its own IP address and full control. Below is how it differs from shared hosting, who needs one, what it costs and what to check right after you buy it.
  • VPS for a Telegram bot: what the bot needs and how to pick a planA bot with a menu and a few commands runs fine on the cheapest server, while a bot with broadcasts, files and a database hits completely different limits. Here is what a bot really consumes, which Telegram limits shape the choice of server and how to avoid overpaying.
  • Windows VPS: licensing, RDP and secure sign-inA Windows server costs more than Linux not only because of memory: the price includes a licence, and how it is arranged decides whether you are compliant and how many people can connect. An exposed RDP port is also the most common way such servers get hacked. Here are both topics.
  • How to test VPS ping and speed before you payThe numbers in a plan do not tell you the latency to your users or how fast the disk really is. Most of this can be measured before you pay, the rest in the first hour after launch. Here are the tools and how to read the results.
  • Corporate network on a VPS: remote access to the officeA rented server can become the hub of a company's private network: remote employees and branch offices connect through it to the ERP, file server, CRM and Git. Here are the common layouts, protocols, server requirements and security basics.
  • How to choose a VPS: the 7 specs that matterTwo plans with the same "2 cores, 4 GB, 50 GB" can differ several times in speed and twice in price a year later. Here is what stands behind each line of a VPS plan and what to check before you pay.
  • VPS vs VDS: is there a difference and what actually mattersIn most markets VPS and VDS mean the same thing: a virtual server. The difference that really affects your work is hidden not in the name but in the virtualization type and whether resources are guaranteed.