Shared Hosting to VPS: What to Check Before You Move
Check the site before you touch the server
If you are moving from shared hosting to VPS, start with the dull stuff. Most migrations do not fail because of the website files. They fail because of email, DNS, or an old plugin nobody remembered was still active.
Before you place the order, open your current hosting account and note four details: the current PHP version, the control panel in use, the size of your public_html folder, and whether email lives there too. If you manage the site yourself, put that in a text file now. If you are moving a client site, tell them DNS changes can take time to settle.
When the site is larger than a basic brochure build, choose a plan with room to grow. A small Hostperl VPS is a practical starting point for most moves because you can test, stage, and tune it before the final switch.
- Check whether the site uses WordPress, WooCommerce, or a custom app.
- Confirm if mailboxes are on the same account as the website.
- List cron jobs, backup schedules, and SSL expiry dates.
- Save the current DNS records before you change anything.
Export the essentials, not just the website files
A common mistake is copying only the website directory. That is not enough. You also need the database, mail settings, and anything the control panel stores outside the document root.
For WordPress sites, export the database from phpMyAdmin in cPanel or Plesk. For custom applications, ask the previous host whether the database runs on MySQL or MariaDB, and note the hostname. If you are unsure, check the configuration file first. On WordPress, it is usually wp-config.php. For many PHP apps, it is a similar file under the site root.
Use this quick checklist:
- Back up the full website files.
- Export the database.
- Record email accounts, aliases, and forwarders.
- Download SSL certificates if they are not reissued automatically.
- Copy the current DNS zone if your registrar does not manage records elsewhere.
For people moving between control panels, our guides on moving from cPanel to Plesk safely and the cPanel, Plesk, or DirectAdmin comparison can help you avoid surprises before the transfer begins.
Prepare the new VPS like a live production server
Once the VPS is provisioned, do not rush into the migration. Set it up as if the site were going live that day. Update the OS, set the hostname, check the timezone, and make sure the control panel is reachable through a secure login.
On Ubuntu or Debian, you will usually update packages first:
apt update && apt upgrade -yOn RHEL-family systems such as AlmaLinux or Rocky Linux, use:
dnf update -yThen confirm the basics: the panel license is active, the server’s DNS points are correct, and the firewall allows only the services you need. If you use cPanel, Plesk, or DirectAdmin, set the default PHP version now instead of after launch. That saves you from support tickets later because the site renders a blank page.
At Hostperl, many customers choose a VPS for this stage because it gives them their own environment without jumping to a full dedicated server too early. If you expect heavier traffic, multiple sites, or mail volume from day one, compare the options in VPS vs dedicated servers before you commit.
Move the site in a way you can test
The cleanest move is a staged one. Upload the files, import the database, then test the site with a temporary host entry or a hosts-file override before you change public DNS. That gives you a private way to check the theme, login page, contact forms, and checkout flow.
If you are using shared hosting to VPS for a WordPress site, create the new database first, set the database user permissions, and verify the application config points to the new credentials. Then load the site in a browser and look for the obvious failures: missing images, broken permalinks, and hard-coded old URLs.
A simple order works well:
- Copy files to the new account.
- Create and import the database.
- Adjust config files and permissions.
- Test the site privately.
- Only then update DNS.
If you need a reminder on avoiding downtime during a move, use How to Move Hosting Sites Without Downtime in 2026 as your final run sheet. It fits neatly with the practical steps in this tutorial.
Keep email separate in your planning
Email is where many migrations go wrong. Website files may move cleanly, but inboxes can stop receiving mail if MX records, SPF, DKIM, or mailbox paths are missed. If your current shared hosting plan includes email, decide early whether you will keep email on the old host for a while or move it at the same time.
For most small businesses, the safest approach is to keep mail stable during the website move, then move mailboxes after the site is confirmed healthy. If you run a local business, appointment inbox, or order notifications, that sequence matters more than saving an hour.
Review our notes on shared hosting vs VPS email deliverability and the SSL, DNS, and Email Setup Checklist for Hosting Customers before changing mail routing. You will catch most of the common mistakes there.
After the switch, send a test message to Gmail, Outlook, and one business mailbox. Check whether it lands in inbox, spam, or promotions. If messages go missing, review the SPF record and confirm the new VPS IP has not been flagged by a poor previous tenant. Our email deliverability checklist for VPS hosting is a good next step.
DNS cutover: make the switch boring
Lower your DNS TTL before the move, ideally 24 hours in advance. A TTL of 300 seconds works well for cutovers because it shortens propagation time without making the zone noisy. Change the A record, AAAA record if you use IPv6, and any service records tied to the website or mail server.
Do not edit unrelated records during launch. Leave domain verification, third-party app records, and existing MX entries alone unless you are intentionally moving them. Small DNS mistakes are the fastest way to turn a routine migration into a support ticket.
If your domain setup lives with the same provider, check that nameservers still point to the right zone after the move. If you manage DNS externally, keep the old zone exported until the new VPS has served traffic for a few days. For domain and DNS-related moves, the DNS and email setup checklist is worth keeping open beside your browser.
Verify the first 24 hours carefully
The first day after a migration tells you whether the move is complete or just copied. Check the homepage, key landing pages, login forms, uploads, and password reset emails. Then look at server logs and panel alerts for any signs of permission problems or PHP errors.
On the VPS, watch disk usage, memory use, and active processes. If the site feels slower than expected, the cause is often simple: an oversized PHP worker pool, an uncached homepage, or old image files that were never compressed.
A short verification list helps:
- Confirm the site resolves to the new IP.
- Test HTTPS and renew the SSL if needed.
- Send and receive test mail.
- Open the contact form and any checkout page.
- Check backup jobs and confirm they complete.
If the new server runs several sites, compare their resource usage before you decide whether you need to stay on VPS or move to dedicated hardware later. Our guides on shared, VPS, and dedicated hosting and shared hosting upgrade signals explain the practical signs customers usually see first.
What to do if something breaks
Most migration problems fall into a few patterns. A blank page usually means a PHP mismatch or file permission issue. A database connection error usually means the config file still points to the old host. Missing email usually means MX or mailbox settings were not carried over.
Work through problems in this order: DNS, web server, PHP, database, then email. That sequence saves time because it checks the layers from outside to inside. If the site loads on the new server through a temporary URL but not through the domain, the issue is almost always DNS or SSL rather than the application itself.
When you need more context on the transition itself, How to Move a Hosting Site to New Server Safely in 2026 is the natural companion guide. It pairs well with this checklist-style tutorial.
If you want a move that feels controlled instead of rushed, Hostperl can help you plan the cutover, check DNS, and size the new server properly. Our VPS hosting gives you room to stage the migration, and our team can also help you choose a larger platform if your traffic or email load needs it.
For customers moving multiple sites or business-critical mailboxes, that support can make the difference between a quiet launch and a long night.
Quick FAQ
Should I move email at the same time as the website?
Not always. If email is business-critical, keep it on the old host for the first phase, then move mailboxes after the website is stable.
How long should I keep the old hosting account active?
Keep it active for at least a few days after DNS changes. That gives you a fallback if you discover a missed file, record, or mailbox.
Can I migrate from shared hosting to VPS without downtime?
Yes, if you stage the site first, lower TTL before the switch, and verify the new server before changing public DNS.
Do I need a control panel on the VPS?
If you are used to cPanel, Plesk, or DirectAdmin, a panel makes the move easier. It also reduces configuration mistakes for email, backups, and SSL.
When should I consider dedicated hosting instead?
If multiple sites, heavier databases, or higher traffic start pushing your VPS limits, move to dedicated hosting before the server becomes a bottleneck.
Shared hosting to VPS is a sensible upgrade when you need more control, better isolation, and a cleaner path for growth. If you want help choosing the right size and panel for the move, Hostperl’s VPS vs dedicated guide and managed VPS hosting pages are the best place to start.
