# Migrating from shared hosting to a VPS Source: https://vpsdime.com/knowledgebase/getting-started/migrating-to-a-vps Last reviewed: 2026-07-02 Summary: The complete move from cPanel-style shared hosting to your own VPS, what changes (you own the server now), the email decision to make before touching DNS, inventory, building the destination first, the hosts-file trick to test before cutover, lowering TTL, and the overlap week before cancelling the old plan. ## 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](https://vpsdime.com/knowledgebase/getting-started/migrating-a-vps).) 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](https://vpsdime.com/knowledgebase/getting-started/securing-your-vps), and [backups](https://vpsdime.com/knowledgebase/getting-started/backing-up-your-vps) 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](https://vpsdime.com/knowledgebase/technical-questions/mailcow-on-linux-vps) is the good tooling, but deliverability and upkeep are a real ongoing job, and [our email policy](https://vpsdime.com/knowledgebase/acceptable-use/email-policy) applies. Choose this deliberately, not by default, the full decision guide is [Should I host my own email?](https://vpsdime.com/knowledgebase/getting-started/self-hosting-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](https://vpsdime.com/knowledgebase/getting-started/hosting-a-website) 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](https://vpsdime.com/knowledgebase/getting-started/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](https://vpsdime.com/knowledgebase/getting-started/uploading-files-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](https://vpsdime.com/knowledgebase/getting-started/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](https://vpsdime.com/knowledgebase/getting-started/hosting-a-website)). 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](https://vpsdime.com/knowledgebase/getting-started/securing-your-vps), a [real backup routine](https://vpsdime.com/knowledgebase/getting-started/backing-up-your-vps) (the old panel's nightly backups are gone with it), and re-creating the **cron jobs** from your inventory ([timers are the better home](https://vpsdime.com/knowledgebase/technical-questions/systemd-timers)). Then, and only then, cancel the old plan. The work itself is yours (the service is [self-managed](https://vpsdime.com/knowledgebase/support-coverage/software-and-server-management)), 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](https://vpsdime.com/open-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?"