Managed infrastructure for SMBs

Moving from Shared Hosting to a VPS: A Small-Business Migration Checklist

Guides · GlassHosting

VPSMigrationLinuxSMB

The short answer

Moving from shared hosting to a VPS gives a small business its own server resources, full control over software versions, and room to grow. The move itself is where things go wrong: a missed email setting, a forgotten cron job, or a DNS change made too late can turn a quiet weekend task into a stressful outage.

This checklist walks small-business owners and IT leads through a calm, reversible migration: take inventory, prepare DNS early, back everything up, build and test a staging copy, plan for email, cut over, keep a rollback ready, and check everything after the move.

Before you start: is a VPS the right next step?

A VPS is a good fit when your site or apps have outgrown shared limits, you need software or settings your shared host will not allow, or you want to run more than one app on infrastructure you control. It also means someone has to look after the server: updates, security, backups and monitoring.

If nobody on your team wants that job, read managed vs unmanaged VPS before you choose. A managed VPS gives you the same server with a team that handles the upkeep.

Step 1: Take an inventory of what you have today

You cannot move what you have not written down. Log in to your shared hosting control panel and list:

  • Websites and domains, including subdomains, parked domains and redirects.
  • Applications and versions: WordPress, WooCommerce, other CMSs, custom code, and the language versions they run on (PHP, Python, Node.js).
  • Databases: names, users and which app uses each one.
  • Scheduled tasks (cron jobs) and what each one does.
  • Email: mailboxes, forwarders, aliases, autoresponders and mailing lists.
  • DNS records: export the full zone, including MX, SPF, DKIM, DMARC and any verification records for third-party services.
  • SSL certificates and how they renew today.
  • Integrations: payment gateways, SMTP relays, API keys, webhooks and IP allowlists at partners that may need your new server address.
  • Who has access: control panel, FTP or SFTP accounts, and admin users.

Keep this list in a shared document. It becomes your checklist for the move and your documentation afterwards.

Step 2: Choose and size the VPS

Size the new server for what you run today plus room for growth, not for the limits of your old plan. Our VPS sizing guide shows how to estimate CPU, memory and storage for each workload. If you are unsure whether a full virtual machine or a container-based VPS fits, our KVM vs LXC guide explains the difference.

Step 3: Lower your DNS TTL early

DNS records carry a TTL (time to live) that tells resolvers how long to cache them. If your TTL is long, some visitors will keep reaching the old server for hours after you switch.

  • Find the current TTL on the records you will change (usually the A, AAAA and www records).
  • Lower it to a few minutes at least one full old-TTL period before cutover, so caches pick up the short value in time.
  • Leave MX records alone for now unless email is moving at the same time.
  • Raise the TTL again once the move is stable.

Step 4: Back up everything before you touch anything

Take a complete backup from the shared host and store it somewhere other than the old or new server:

  • All website files, including uploads and hidden configuration files.
  • A full export of every database.
  • Your DNS zone export and email settings from Step 1.
  • Mailbox contents, if email is moving.

Then confirm the backup is usable: open the archive, check the database dump is complete, and note where it lives. Our Linux VPS backups and snapshots guide covers how to set up ongoing backups on the new server, and the same habits apply to this one-time migration backup.

Step 5: Prepare and secure the new server

Set up the VPS before any data lands on it:

  • Update the system and enable automatic security updates.
  • Harden SSH with keys, no password logins and no direct root login. Our SSH security guide walks through it.
  • Turn on a firewall that allows only the services you need, usually SSH, HTTP and HTTPS.
  • Install the stack your apps need, matching the language and database versions from your inventory where possible.
  • Create named accounts for each person who manages the server.

If you plan to run several apps side by side, our Docker on a Linux VPS guide shows how containers can keep them separate.

Step 6: Build and test a staging copy

Restore your files and databases to the new server and test it before any real visitor sees it:

  • Point a temporary hostname at the new server, or use your local hosts file to preview the site at its real domain.
  • Update app configuration with the new database details and file paths.
  • Issue an SSL certificate for the staging hostname, or plan to issue the real one at cutover.
  • Test the things that make you money: forms, logins, checkout, payment callbacks, search and contact pages.
  • Recreate your cron jobs and confirm they run.
  • Check outbound email from the app (order confirmations, password resets) actually arrives.

Fix problems here, on staging, where they cost nothing.

Step 7: Plan email separately

Email is the part of a shared hosting move that most often breaks. Decide early where email will live:

  • Keep email where it is. If your mailboxes are with a dedicated email provider, leave the MX records untouched and only move the website.
  • Move email to a dedicated provider. Many small businesses use the move as a chance to separate email from web hosting. Plan mailbox migration on its own schedule.
  • Run mail on the VPS. Possible, but it adds deliverability, spam filtering and security work. Most small businesses are better served by a dedicated provider.

Whatever you choose, make sure SPF, DKIM and DMARC records include whatever will send mail for your domain after the move, including the VPS itself if your website sends transactional email.

Step 8: Cut over

Pick a quiet time and follow a written runbook:

  1. Announce a short change freeze: no new content, orders on hold if needed.
  2. Take a final backup and a final database export from the shared host.
  3. Sync any files and data that changed since staging.
  4. Issue or confirm SSL certificates for the real domain on the new server.
  5. Update the A, AAAA and www records to the new server.
  6. Watch traffic arrive on the new server and test the key user journeys again.
  7. Update IP allowlists at payment gateways, SMTP relays and partners.

Step 9: Keep a rollback ready

A good migration can be undone. Until the new server has run cleanly for a while:

  • Keep the shared hosting account active and untouched.
  • Keep the old DNS values written down so you can point records back quickly.
  • Decide your rollback trigger in advance, for example checkout failures or errors you cannot fix quickly.
  • Know what happens to new data if you roll back, such as orders or form entries taken on the new server, and how you would carry them back.

Because you lowered the TTL in Step 3, a rollback reaches visitors quickly too.

Step 10: Post-move checks

After cutover, check the new server and the business together:

  • Every domain and subdomain loads over HTTPS with a valid certificate.
  • Redirects, including http to https and non-www to www, behave as before.
  • Forms, checkout, logins and email notifications work end to end.
  • Cron jobs run on schedule.
  • Search engines can reach the site: robots.txt and sitemap are in place and pages return the right status codes.
  • Backups are running on the new server and a test restore works.
  • Monitoring and alerts are set up. Our VPS monitoring and alerts guide explains what to watch.

When everything has run cleanly for a while, raise the DNS TTL back up, take a final archive of the shared account, and cancel it.

A shared-hosting-to-VPS migration checklist

  1. Inventory of sites, apps, databases, cron jobs, email, DNS, certificates, integrations and access.
  2. VPS chosen and sized for today plus growth.
  3. DNS TTL lowered well before cutover.
  4. Full backup stored off both servers and checked.
  5. New server updated, SSH hardened, firewall on.
  6. Staging copy built and tested, including payments and app email.
  7. Email plan decided, with SPF, DKIM and DMARC updated.
  8. Written cutover runbook followed in a quiet window.
  9. Rollback plan ready and the old account kept active.
  10. Post-move checks done, backups and monitoring running, TTL raised again.

Part of our Linux VPS series

This checklist pulls together the rest of our Linux VPS series: choose the right VPS size, secure SSH on a Linux VPS, set up Linux VPS backups and snapshots, add VPS monitoring and alerts, and run apps with Docker on a Linux VPS.

Next steps

A VPS gives you room to grow and full control of your stack. If you would rather have a team plan the move, migrate your sites, and look after the server afterwards, our managed services can take that on for you. Read managed vs unmanaged VPS to compare, browse the plans, then tell us what you run or email sales@glasshosting.com. We will help you plan a migration that fits your business.

Host with GlassHosting

Order a plan or browse the knowledgebase for deeper how-tos.

Order / billing Knowledgebase All guides