How to Migrate from Shared Hosting to a VPS

Before you migrate: decide if the move is actually worth it

If you plan to migrate from shared hosting to a VPS, start with the reason, not the server. Most people move for one of three reasons: the site has slowed down, email delivery is unreliable, or the account keeps hitting resource limits during busy periods.

If your current plan is still stable and the site is simple, our shared hosting upgrade signals guide can help you decide whether a VPS is the right next step. If you already know you need more control, Hostperl VPS hosting gives you room to adjust PHP, web server settings, mail handling, and backups without fighting a shared environment.

For many small businesses, the real question is not “Can I use a VPS?” It is “Will I manage it well enough to make the upgrade worthwhile?” A VPS rewards basic discipline: updates, backups, and a clear DNS plan.

Gather the pieces you need before you touch DNS

Migration problems usually start with missing inventory. Make a short list of what lives on the old account so nothing gets left behind.

• Website files for each domain and subdomain
• Databases, especially WordPress and store databases
• Email accounts, forwarders, filters, and aliases
• DNS records such as A, MX, TXT, and CNAME
• SSL certificates and renewal method
• Scheduled jobs, cron tasks, and application paths

If you manage a cPanel account, the best first step is to note the document root for every site and export database names from phpMyAdmin. For DirectAdmin and Plesk users, do the same from the panel interface. This is not busywork. It prevents the common “site works, mail is broken” problem after cutover.

For email-heavy sites, read the VPS email hosting checklist before you move. Mail reputation, SPF, DKIM, and DNS timing matter more than most people expect.

Prepare the VPS for the first login

Once your VPS is provisioned, log in and check the basics before hosting any traffic. On Ubuntu or Debian, confirm the OS release, update packages, and set the timezone. On AlmaLinux or RHEL-family systems, do the same through the package manager and make sure your control panel license is ready if you use one.

uname -a
cat /etc/os-release
sudo apt update && sudo apt upgrade -y

Then create a non-root admin user, enable SSH key access if you prefer it, and confirm the firewall is active. If you are on Ubuntu, our UFW firewall guide and SSH key authentication tutorial are both practical starting points.

If you want a broader setup path for the server itself, our Fail2Ban tutorial for Ubuntu VPS is a sensible next step. It cuts down brute-force noise before you bring live sites onto the machine.

Move files and databases in the right order

Copy the website files first, then move the database, then adjust configuration. That order avoids half-working sites during the transfer window.

For a WordPress site, you will usually move the contents of public_html or the domain document root, export the database, and update wp-config.php to point at the new database name, user, and password. For Laravel, PHP apps, or custom sites, look for environment files and cached paths as well.

mysqldump -u olduser -p old_db > old_db.sql
mysql -u newuser -p new_db < old_db.sql

After import, check table counts and load the site from a temporary hosts-file entry or a staging URL. If pages load but images do not, you probably missed a path, permission, or base URL setting.

For sites using MariaDB or PostgreSQL, Hostperl VPS plans are usually the better fit because you can tune database memory and caching to match the workload. That matters once the site stops being a small brochure site and starts handling real traffic.

Recreate email carefully, or leave it on the old provider for a while

Email is where many migrations go wrong. If you move DNS too early, new mail can arrive before the mailbox exists. If you move mailboxes too late, users get split between two servers.

The safest pattern is to lower the DNS TTL, create the same mailboxes on the new server, then migrate mail with IMAP sync or a panel tool. After that, point MX records to the new mail host and test sending and receiving from outside your network.

Check SPF, DKIM, and DMARC after the switch. If you use cPanel, Plesk, or DirectAdmin, each panel has a mail configuration area, but the DNS records still need to match what the server publishes. Our email deliverability checklist covers the verification steps customers most often miss.

Switch DNS without creating a support ticket for yourself

When the site is verified on the VPS, update DNS at the domain registrar or DNS host. In most migrations, you only need to change the A record for the website and the MX records for mail. Leave everything else alone unless you know why it is changing.

A simple pre-cutover checklist looks like this:

1. Lower TTL to 300 seconds at least a few hours in advance
2. Confirm the new server responds on the temporary hostname
3. Back up the final state on the old host
4. Update A, AAAA, and MX records as needed
5. Test website, forms, SSL, and mail from a clean browser session

If your domain setup is messy or you want a clean start for DNS hosting, Hostperl domain and DNS services can simplify the handoff. It is especially helpful when multiple people manage the same zone file and nobody wants surprises during launch.

Check the site after launch, not just during the copy

After DNS changes, do not assume the migration is finished. Open the site from mobile data, test a contact form, send and receive mail, and confirm the SSL padlock appears without warnings. Then check the error logs on the VPS for missing paths, permission issues, or PHP notices.

A useful quick test list is:

• Homepage loads over HTTPS
• Admin login works
• Forms submit successfully
• Email sends to Gmail, Outlook, and a business mailbox
• Images, CSS, and JavaScript load from the new host

If you see a mixed-content warning or an old redirect loop, it usually means one URL is still pointing to the previous server. Fix that before you announce the move to customers.

Choose the right VPS setup for the workload

Not every migration needs the same VPS size. A small brochure site may run well on a modest plan, while a store with heavy media and active email needs more CPU headroom and memory. If you expect growth, it is better to start with a little space above current demand than to upgrade twice in the same quarter.

Hostperl’s managed VPS hosting is a sensible fit for customers who want room to grow without moving to dedicated hardware too early. If your traffic, databases, or mail volume are already beyond a standard VPS, compare that with our VPS vs dedicated servers guide before you commit.

That decision matters for agencies too. If you host several client sites, a VPS gives you more flexibility than shared hosting and far less overhead than a dedicated server. It is usually the middle ground people actually keep.

FAQ

How long does it take to migrate from shared hosting to a VPS?

A simple site may move in under an hour once files and databases are ready. A site with mail, multiple domains, or DNS changes usually takes longer because you need testing time.

Should I move email with the website?

Not always. If mail is critical, keep the old mailbox active briefly and migrate it carefully so messages do not get lost during DNS propagation.

Do I need a control panel on the VPS?

If you are used to cPanel, Plesk, or DirectAdmin, a panel can save time and reduce mistakes. If you only host one simple site, a leaner setup may be enough.

What is the most common migration mistake?

Changing DNS before the new site and mail are fully tested. That creates short outages and split email delivery.

Can Hostperl help with the move?

Yes. If you are moving from shared hosting to a VPS, Hostperl can help you choose the right plan and prepare the server for launch.