Migrating from shared hosting to a VPS

What this is#

Moving your sites off shared hosting (cPanel, Plesk, and friends) onto your own VPS. Done in the right order, the visitors never notice; this page is that order. (Moving from another VPS instead? That's its own guide.)

First, the honest framing of what changes. Shared hosting sold you a managed environment: PHP preconfigured, a control panel, mailboxes bundled in, backups quietly handled. A VPS gives you the whole server: root access, your choice of everything, real performance, no neighbor caps, and in exchange, setup, updates, security, and backups become yours. The migration is also the moment you take over those jobs, plan for that, not just for the file copy.

Step 0: decide about email first#

The single most common migration casualty is mail, because shared hosting bundled your mailboxes and the VPS doesn't. Decide before touching DNS:

• Keep mail at a mail provider (the sane default): a hosted mail service (or your registrar's mail offering) hosts the mailboxes; your domain's MX records point there, and the VPS only serves the website. Nothing about the site move touches your mail.
• Self-host mail on the VPS (hard mode): possible, Mailcow is the good tooling, but deliverability and upkeep are a real ongoing job, and our email policy applies. Choose this deliberately, not by default, the full decision guide is Should I host my own email?

Either way, list every mailbox and forwarder that exists on the shared plan now, they vanish when that plan closes.

Step 1: inventory#

From the old panel, write down: the sites and their PHP versions, every database, cron jobs (easy to forget, invisible until something stops happening), the full DNS zone (export or screenshot it, especially MX and TXT/SPF records), and which domains have SSL.

Step 2: build the destination first#

Deploy the VPS and set up the stack before anything moves: web server + PHP (matching the version the site ran on) + database, or a one-click application if it fits. Get a placeholder page serving on the VPS's IP so you know the plumbing works. The old site stays live and untouched throughout.

Missing cPanel already? You don't have to go without a panel, and you don't have to pay for one either. The modern open-source generation is genuinely good: HestiaCP gives you the full shared-hosting mental model (sites, PHP versions, DNS, even mailboxes), CloudPanel does fast PHP hosting without the mail baggage, and Coolify turns the VPS into your own deploy platform. The full rundown with honest caveats: Modern open-source control panels.

Step 3: move files and databases#

• Files: download a full backup from the old panel (cPanel: Backup → Download a Full Website Backup) or pull the document root over SFTP, then place it under your web root on the VPS.
• Databases: export from the old side (phpMyAdmin → Export, or the panel's backup), import on the VPS (mysql newdb < dump.sql).
• Reconnect: update the app's config for the new DB name/user/password and any changed paths (wp-config.php for WordPress). Watch for hardcoded old-server paths like /home/cpaneluser/....

Step 4: test before DNS moves, the hosts-file trick#

You can browse the site on the new server while the whole world still sees the old one: add a line to your own computer's hosts file (/etc/hosts, or C:\Windows\System32\drivers\etc\hosts on Windows):

YOUR.VPS.IP yourdomain.com www.yourdomain.com

Your machine now resolves the domain to the VPS. Click through everything, pages, logins, forms, uploads, and fix what's broken with zero pressure, because nothing is live yet. Remove the line when done testing.

Step 5: cutover#

1. A day ahead, lower the TTL on the domain's A records (to 300s) so the switch propagates fast.
2. Switch the A records to the VPS IP (pointing your domain), leaving MX and mail-related records exactly as your Step-0 decision requires.
3. Issue SSL on the VPS as soon as DNS resolves there (certbot).
4. Keep the old hosting alive for a week. Cached DNS sends stragglers to the old server for a while, and the overlap is your safety net if something surfaces late.

Step 6: take over the landlord's jobs#

Shared hosting did these silently; now they're yours, and day one is the right day: the security checklist, a real backup routine (the old panel's nightly backups are gone with it), and re-creating the cron jobs from your inventory (timers are the better home). Then, and only then, cancel the old plan.

The work itself is yours (the service is self-managed), but none of it is exotic, and an AI chatbot walks any single step in this page with you patiently.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP and the site being moved,
• which step you're on (inventory, copy, hosts-file test, cutover), and where it got stuck.

Related questions#

• "How do I move my website from shared hosting to a VPS?"
• "What happens to my email when I leave shared hosting?"
• "How do I test my site on the new server before changing DNS?"
• "How do I migrate a WordPress site to a VPS?"
• "When can I safely cancel my old hosting?"