Website Migration Checklist for Shared Hosting to VPS (2026)

A rushed move off shared hosting usually breaks in the same places: DNS cutover timing, mailboxes split across servers, missing SSL chain files, and backups that look fine until restore day. A website migration checklist keeps those avoidable tickets out of your week by forcing the boring decisions before you touch nameservers.

This guide is written from the hosting side of the desk—where migrations happen daily: agency batches, ecommerce launches, and the classic “we outgrew shared” upgrade. Use it to plan a clean move from shared hosting to a VPS without breaking email, search traffic, or customer trust.

Website migration checklist: decide what you’re actually moving

Before you copy a single file, lock down the scope. A “site migration” is often four separate moves bundled together: web, database, email, and DNS. The steps below only stay accurate if you know which services currently live on your shared plan.

• Web stack: Apache/Nginx, PHP version, caching layer, and any image optimization tooling.
• Database: MySQL/MariaDB version, size, and whether you rely on scheduled backups from your host.
• Email: mailboxes, forwarders, autoresponders, mailing lists, and outbound sending limits.
• DNS: where DNS is hosted today (registrar, shared host, Cloud DNS) and which records are “special” (SPF/DKIM/DMARC, API verification, Microsoft 365/Google Workspace, payment gateways).

If you’re moving to a VPS to fix performance or resource limits, size the VPS first. “Lift and hope” often lands you on a box that’s only marginally better. The smoothest upgrades happen when customers sanity-check CPU/RAM/SSD against real traffic and job schedules. The VPS sizing calculator for hosting is a quick starting point.

Why shared-to-VPS migrations fail (and how to prevent the common outages)

Most issues show up during cutover, not during the copy. The outside world—DNS resolvers, mail servers, browsers with cached HSTS—doesn’t switch instantly just because you did.

These are the failure patterns that cause the most real-world pain:

• DNS TTL left high: you changed A records, but customers keep hitting the old server for hours.
• Email split-brain: some senders deliver to old MX, others to new MX, and replies “disappear.”
• PHP mismatch: the VPS defaults to PHP 8.3/8.4 while the site was pinned to an older minor version; plugins break.
• SSL not recreated correctly: missing intermediate certificates, wrong SAN list, or certificate installed in the panel but not on the actual vhost.
• Backups not restorable: backup exists, but it’s incomplete (no DB) or permissions/paths differ on the new server.

If you’re still weighing whether a VPS is the right next step, compare the operational overhead and cost before you commit. Hostperl’s breakdown is here: signs you’ve outgrown shared hosting.

Pre-migration readiness: 72 hours before you touch DNS

Use the pre-migration window to remove surprises. A “boring” cutover is the goal—because boring rarely needs a rollback.

1) Lower DNS TTLs (without changing records yet)

Lower TTL for the records you expect to change—usually A/AAAA, and sometimes MX if email is moving. 300 seconds (5 minutes) is a practical value for 24–48 hours before cutover. Avoid 30-second TTLs; they rarely help and often create weird cache behaviour while increasing query load.

Also write down exactly where you’ll make DNS edits: registrar panel, your current shared hosting DNS zone, or a third-party DNS provider. If you’re moving DNS hosting as well, treat that as a separate change with its own checks.

2) Inventory email properly (mailboxes, aliases, and business risk)

Email is usually the sharp edge. Web traffic can tolerate brief inconsistency. Missed invoices, order confirmations, and support replies can’t.

• Export a list of mailboxes, their sizes, and active users.
• List forwarders, catch-all addresses, and autoresponders.
• Confirm outbound needs: newsletters, order confirmations, form mail, and any API-sent mail.

If shared mail limits already cause problems, a VPS move is a good time to fix sending behaviour (rate limiting, queue monitoring, authentication). This guide helps with the decision: shared hosting email limits: when to upgrade to VPS for mail.

3) Pick the right hosting target (panel vs managed stack)

Migrations go faster when the new environment matches how you actually operate. If your workflow depends on a control panel for accounts, mailboxes, SSL, and backups, keep that model on the VPS. Otherwise you’ll be migrating and re-platforming at the same time.

For many customers, a Hostperl VPS hits the practical middle ground: dedicated resources and predictable performance, with the flexibility to run cPanel/DirectAdmin/Plesk or a lighter stack—without jumping straight to dedicated hardware.

4) Freeze risky changes and schedule the cutover

Put a change freeze in place for the cutover window. That doesn’t mean “stop taking orders.” It means no plugin updates, no theme changes, no mailbox clean-ups, and no experimental DNS edits.

Pick a cutover time that matches your customer base. For NZ/AU businesses, local off-peak hours reduce the blast radius if you need to roll back.

Website migration checklist: data copy and verification (before go-live)

Copying data is rarely the hard part. Verification is where you catch problems before real users do.

Web files: capture what actually serves requests

• Export site files including hidden files like .htaccess, .user.ini, and environment configs.
• Confirm file ownership and permissions match your runtime user (panel setups often expect specific ownership).
• Bring over cron jobs. On shared hosting these are often in a panel UI and easy to forget.

If you’re moving between control panels, follow a panel-aware workflow. Hostperl’s control panel migration checklist for cPanel, Plesk & DirectAdmin calls out the account-level settings people commonly miss, including PHP handlers, mail routing, and per-domain SSL.

Database: verify version compatibility and character sets

Most shared hosting runs MySQL 8.0+ or MariaDB 10.6+ equivalents in 2026, but version edges still matter—especially with older CMS installs and strict SQL modes.

• Confirm DB engine/version on old and new hosts.
• Check DB size and restore time estimates.
• Verify character set and collation (common failure: mixed utf8 vs utf8mb4).

For high-change sites (stores, booking systems), plan a final delta sync right before cutover. A single export done days earlier is rarely enough.

Staging verification: test without public DNS changes

Test the new VPS using a temporary URL or a hosts-file override. You want to see real requests hitting real data, without sending customers to the new server yet.

Minimum checks to run before go-live:

• Homepage + 3–5 key landing pages load without 500 errors.
• Login works (admin and customer accounts).
• Forms submit and mail sends to the right mailbox.
• Checkout/booking flow completes (use a sandbox payment gateway if possible).
• Media loads (no missing images due to path differences).

Email and DNS cutover: keep mail flowing while traffic moves

Email is where reputations get bruised. Most people will tolerate a short website hiccup. They won’t tolerate a missing invoice or an unanswered support thread.

Decide: move email now, later, or not at all

You have three sensible choices:

• Keep email where it is: move only the website. Low risk and fast, especially if mail is stable today.
• Move email with the website: gets you off shared hosting limits, but requires careful MX timing and testing.
• Move email to a dedicated mail solution: often the best long-term fit, but it’s a separate migration and should be planned as one.

If you’re moving email to the VPS, include authentication work in the plan. SPF/DKIM/DMARC isn’t optional in 2026 if you want reliable inbox placement. Hostperl’s guide on SPF, DKIM, and DMARC for VPS hosting covers the record changes and the mistakes that trigger delivery failures.

MX strategy: avoid split delivery during propagation

The safest pattern is to leave MX alone until the new mail server is proven and ready, then switch MX during a quiet window. If you change MX at the same time as A records, expect a period where mail lands on both servers.

In practice, plan for:

• Keep the old mailboxes active for at least 48 hours after cutover.
• Monitor both servers for inbound delivery.
• Tell staff that replies may arrive on either server temporarily, even if sent items look normal.

For a more formal continuity plan, Hostperl also publishes an email hosting downtime plan for cPanel & VPS moves designed for day-to-day business constraints, not lab conditions.

DNS record audit: the “small” records that break big services

Before you flip anything, export the current DNS zone and mark the records you must carry over exactly:

• TXT: SPF, DKIM selectors, DMARC, site verifications, password managers, and SaaS validations.
• CNAME: mail autodiscover, CDN endpoints, tracking links, and third-party tools.
• SRV: VoIP/Teams/other service discovery records (often forgotten because they’re rare).

A migration can look “successful” because the website loads, while mail authentication or a payment webhook quietly fails due to one missing TXT record.

Performance and stability after the move (the first 7 days)

A VPS move isn’t finished when DNS points at the new IP. The first week is where you confirm the server holds up under real traffic, cron workload, and mail patterns.

Watch resource headroom, not just uptime

Shared hosting can mask the shape of your workload. On a VPS, it’s all yours. That’s a good trade—if you keep enough headroom for spikes, updates, and backups.

Track these daily for the first week:

• CPU steal/usage: sustained CPU near 90% means you’ll feel it in page generation time.
• RAM pressure: swap activity is a warning sign for PHP-FPM and database performance.
• Disk I/O: slow queries and admin dashboards often correlate with I/O saturation.

For a day-by-day runbook, Hostperl’s VPS upgrade plan for the first week mirrors the framework our support team uses when customers upgrade under time pressure.

Cache and compression: re-check what shared hosting used to do for you

Some shared platforms quietly provide caching, image optimization, or tuned PHP defaults. On a VPS, you may need to enable equivalents yourself (object caching, page caching, Brotli/Gzip, HTTP/2/3 where supported).

Skip the micro-tuning at first. Start with the big wins: correct PHP memory limits, a sensible PHP-FPM process model, and server-side caching that matches your CMS and traffic.

Operational checklist: the “last 10%” that makes support quieter

This part isn’t glamorous, but it’s what keeps your inbox quiet after the move.

• Backups: confirm you have automated backups, retention, and a restore test. Keep at least one off-server copy.
• SSL renewals: verify auto-renew and renewal notifications. If you use Let’s Encrypt, confirm the validation method will still work.
• Monitoring: set up basic external checks (HTTP + HTTPS) and an alerting email that someone reads.
• Log access: know where your web and mail logs live in your chosen panel/stack so troubleshooting doesn’t start from scratch.
• Access control: review who has SSH/panel access; remove old contractors; store credentials in a shared vault if you’re an agency.

If your move includes a new control panel, treat it like a workflow change and document it up front. For example, if your team relies on per-site PHP switching in cPanel, confirm how that will work on the new VPS before migrating. (If you’re staying with cPanel, keep this reference handy: set up cPanel PHP Version Manager for multi-site configuration.)

What to ask your hosting provider before you migrate

A migration works best when roles are clear. You know your application and business risk. Your provider knows the platform, network, and the failure modes they see every week.

These questions change outcomes:

• What’s included in migration help? file copy, database copy, mailbox transfer, DNS guidance, SSL install, and testing support.
• What’s the rollback plan? how fast can you point back, and what data will be lost if you do?
• What are the support hours? for NZ/APAC businesses, local response timing matters during cutover.
• Do you block outbound SMTP by default? many providers do this to reduce abuse; plan for it so form mail doesn’t silently fail.

For a clear picture of what a professional move should look like in 2026, Hostperl’s hosting migration service: what to expect (and request) is a solid baseline for setting internal expectations.

Summary: a calm cutover beats a clever cutover

A solid website migration checklist doesn’t slow you down. It makes the work predictable. Lower TTLs early, test on staging, keep old mail live during propagation, and prove backups with a restore test—not a ticked box.

If you’re planning a shared-to-VPS move and want a platform that supports day-to-day hosting operations (accounts, email, SSL, backups, and room to grow), start with a Hostperl VPS hosting plan and talk to us about your cutover window and risk points. You’ll get a path that avoids surprises for customers and staff.

FAQ

How long does a shared hosting to VPS migration take?

For a typical small-business site, you can often complete the copy and staging tests in a day. The timeline usually hinges on DNS TTL and email risk; plan 48–72 hours for a controlled cutover and verification.

Should I change nameservers or only update A records?

If your DNS zone is tidy and you trust where it’s hosted, updating A/AAAA (and possibly MX) is often simpler. Changing nameservers can work too, but it raises the odds of missing records during the move.

Will my email go down during the migration?

It doesn’t have to, but email can be inconsistent during DNS propagation if you change MX. Keeping the old mail server active for at least 48 hours and monitoring both servers reduces the chance of missed messages.

Do I need a control panel on a VPS?

Not always. If you manage multiple domains, mailboxes, SSL renewals, and backups through a UI today, a panel keeps your workflow consistent. If you’re comfortable managing everything manually and the setup is simple, a lighter stack can work well.

What should I keep on the old shared hosting account after cutover?

Keep it active for a short overlap: at minimum, email (if you moved MX), the old website (for rollback), and DNS zone export records. Once you confirm traffic, mail delivery, and backups on the VPS, you can safely cancel.