Website Migration Checklist: Moving From Shared Hosting to VPS Without Downtime

Overview

A good website migration checklist does two jobs at once: it reduces surprises, and it gives you a repeatable process you can trust next time. The biggest mistake in a move from shared hosting to VPS is treating it as a simple file copy. In practice, a migration touches DNS, databases, email routing, SSL, cron jobs, application caches, file permissions, backups, and monitoring. If any one of those pieces is skipped, the site may appear to work while quietly breaking forms, uploads, scheduled tasks, or outbound mail.

The safest way to move from shared hosting to VPS without downtime is to think in phases:

• Prepare: inventory the current site, lower DNS TTL where possible, provision the VPS, and document dependencies.
• Replicate: build the new environment, restore files and databases, and confirm the application works before public traffic arrives.
• Sync: capture the latest content changes, especially for dynamic sites with comments, orders, or form submissions.
• Cut over: update DNS or switch your reverse proxy route, then observe logs and behavior closely.
• Stabilize: leave the old host online briefly, verify background jobs and email, and confirm backups and monitoring are working on the VPS.

If you are still selecting your new server, start by sizing it conservatively but realistically. A migration often fails because the new VPS is underpowered or missing storage headroom. Our Ubuntu Server Sizing Guide for Web Apps: How Much RAM and CPU Do You Really Need? can help you estimate a reasonable baseline.

Before you begin, define the migration type. Most projects fit one of these scenarios:

• Static or mostly static website
• CMS site such as WordPress, Ghost, or a PHP application
• Custom app with database and background jobs
• Containerized deployment using Docker Compose

Your checklist should match the actual stack, not just the website label.

Checklist by scenario

This section gives you a practical server cutover checklist you can reuse. Start with the universal steps, then follow the scenario-specific list that fits your stack.

Universal pre-migration checklist

• List every domain and subdomain involved, including www, root domain, staging, API, and assets.
• Export or record current DNS records: A, AAAA, CNAME, MX, TXT, DKIM, SPF, DMARC, and any verification records.
• Lower DNS TTL ahead of the cutover if your DNS provider allows it. Do this well before migration day so the shorter TTL has time to propagate.
• Create a full backup of files, databases, and configuration from the shared host.
• Confirm you can restore those backups somewhere else. A backup that has never been tested is only a partial safety net.
• Inventory application requirements: PHP version, Node version, database version, extensions, image libraries, cron jobs, queues, SSL behavior, and writeable directories.
• Provision the VPS with enough CPU, memory, disk, and swap for normal load plus migration overhead.
• Apply base server setup: SSH keys, firewall rules, package updates, non-root user, time zone, fail2ban if appropriate, and automatic security updates where suitable.
• Install the runtime stack: Nginx or Apache, PHP-FPM, Node.js, database server, Redis, Docker, or whatever the app needs.
• Set up backups on the VPS before cutover, not after.
• Set up monitoring and alerting so you can see issues immediately after launch. The VPS Monitoring Checklist: What to Track for Uptime, CPU, Memory, Disk, and SSL is a useful follow-up here.
• Prepare a rollback plan: what change will be reversed, who will do it, and how long the old host will remain available.

Scenario 1: Static site or simple brochure site

• Copy site files to the new server.
• Set up the web server root, compression, caching headers, and redirects.
• Verify asset paths, image loading, robots.txt, and sitemap availability.
• Test the new site using a temporary domain, hosts file override, or local DNS mapping.
• Check HTTPS, mixed content warnings, canonical tags, and redirect behavior from HTTP to HTTPS.
• Confirm forms or third-party embeds still work. Static sites often fail here because form endpoints or API keys were overlooked.
• Cut over DNS and monitor access logs for 404 errors or repeated redirect loops.

Scenario 2: WordPress, Ghost, or another CMS

• Put the application into maintenance mode only if needed for the final sync. Many low-traffic sites can avoid visible downtime by minimizing the freeze window.
• Copy application files, themes, plugins, uploads, and configuration files.
• Export and import the database.
• Update configuration values for database host, credentials, absolute paths, and environment variables.
• Check file ownership and permissions so uploads, caching, and updates work correctly.
• Rebuild caches and restart services.
• Verify login, media library, comments, contact forms, search, scheduled posts, and any e-commerce flow.
• Confirm cron behavior. A CMS moved from shared hosting may lose scheduled tasks if old host cron jobs were not recreated.
• Reissue or install SSL certificates and test HTTPS on the new server before pointing DNS.
• If you run Ghost, compare your setup against a VPS-specific workflow like How to Host a Ghost CMS Site on a VPS: Complete Setup and Maintenance Guide.

Scenario 3: Custom app with database, worker, or queue

• Document every service the app needs: web process, app process, worker, queue broker, cache, search service, object storage, and outbound email provider.
• Create a production environment file on the VPS with all required variables.
• Install and enable process management such as systemd or PM2 for Node.js apps.
• If the app is Node-based, validate the deployment flow against How to Deploy a Node.js App on Ubuntu VPS With Nginx, PM2, and SSL.
• Run database migrations carefully. Know whether they are backward-compatible in case traffic hits both old and new environments during propagation.
• Test uploads, transactional email, login sessions, webhooks, and API callbacks.
• Verify any scheduled jobs or workers are running and not duplicated across both servers after cutover.
• Check external integrations that may rely on server IP allowlists.

Scenario 4: Docker-based deployment

• Bring the stack up on the VPS with the same compose file structure used in staging or development, but with production secrets and persistent volumes.
• Confirm volume mounts for uploads, databases, and application storage are durable and backed up.
• Set restart policies, health checks, and log retention.
• Test service-to-service networking inside the stack.
• Review reverse proxy configuration for HTTPS, timeouts, and websocket support if needed.
• Use a production-oriented checklist such as How to Deploy Docker Compose on a VPS: Production Checklist for Small Projects before the final switch.

Final cutover checklist

• Take one more fresh backup from the current host.
• Run a final database sync if the site is dynamic.
• Pause write-heavy actions if necessary for a few minutes, such as checkout, publishing, or user-generated content.
• Update DNS records to the VPS IP address, or switch traffic at the proxy layer if that is your setup.
• Purge caches only after the new origin is serving correct responses.
• Watch logs, uptime checks, and error notifications in real time.
• Test the live site from a mobile network and another ISP if possible to catch local cache bias.
• Keep the old hosting account active until you are certain traffic and background jobs have fully moved.

What to double-check

This is the section many people wish they had reviewed before migration day. A site can load fine and still have hidden problems. These are the items most worth rechecking after the VPS is live.

DNS and domain behavior

• Root domain and www both resolve correctly.
• Redirects are intentional and do not create loops.
• MX, SPF, DKIM, and DMARC records were preserved if email is handled outside the website host.
• Nameserver changes were not made accidentally when only an A record update was needed.
• You have a way to perform a DNS propagation check from more than one region.

Application integrity

• Admin login works.
• File uploads succeed and appear in the correct location.
• Search, forms, comments, or checkout complete successfully.
• Background jobs, queue workers, and cron tasks are running exactly once.
• Caches are warm but not serving stale references to the old host.
• Environment variables match production needs.

Security and SSL

• SSL certificates are valid and renewing automatically if that is your plan.
• Firewall rules allow only the expected ports.
• Password-based SSH login is disabled if you intend to use keys only.
• Default database users or sample apps were removed.
• Backups are stored off-server or at least on separate storage.

Performance and server health

• CPU, memory, and disk usage remain stable under normal traffic.
• PHP-FPM, Nginx, database, or app worker logs do not show repeating errors.
• Swap use is not constantly growing, which can signal insufficient RAM.
• Disk has enough free space for logs, backups, and uploads.
• Monitoring covers uptime, SSL expiry, resource usage, and disk thresholds.

If the application is storage-heavy, such as Nextcloud or self-hosted analytics, revisit app-specific hosting guidance rather than assuming a general web stack is enough. For example, storage and backup design matter more for platforms like Nextcloud, while write patterns and maintenance tasks look different for tools like Plausible Analytics or n8n.

Common mistakes

The most expensive migration problems are usually simple oversights. Here are the ones that come up often when people move from shared hosting to VPS for the first time.

• Changing too many things at once. A hosting move is not the best time to redesign the site, switch DNS providers, change mail providers, and upgrade the application stack all in one day.
• Forgetting email records. Website DNS and mail DNS often live together. Recreating only the web records can silently break email delivery.
• Testing only the homepage. Real issues tend to appear in forms, login areas, uploads, checkout, scheduled tasks, and webhooks.
• Assuming shared-host defaults exist on the VPS. Shared hosting often hides operational work by preconfiguring cron, mail routing, backups, PHP modules, and file ownership rules.
• Skipping rollback planning. If the site goes live with a database mismatch or broken uploads, you need a documented reversal path, not an improvised one.
• Turning off the old host too early. Keep it online until you are certain DNS propagation has finished and no important tasks depend on the old environment.
• Ignoring monitoring. A migration is not done when DNS changes. It is done when the new server has remained healthy for a full operating cycle, including cron windows, cache expiry, and backup jobs.
• Underestimating application-specific needs. A Laravel app, WordPress site, and Dockerized Node service all behave differently on the same VPS. If your project is framework-specific, compare your plan against focused guidance such as Best Hosting for Laravel Applications: Shared, VPS, Cloud, and Managed Options.

One more practical rule: if your current shared host is stable enough to keep running for a few extra days, use that time. Rushed cutovers create avoidable downtime. Controlled overlap usually costs less than emergency recovery.

When to revisit

This checklist should be treated as a living document, not a one-time project note. Revisit it whenever the underlying assumptions change.

• Before seasonal traffic periods: If your site has known busy periods, review server sizing, caching, backups, and rollback steps ahead of time.
• When your application stack changes: New PHP versions, Node runtimes, Docker workflows, or database upgrades can alter your migration steps.
• When you add services: CDN, object storage, transactional email, Redis, search, or queue workers all expand the checklist.
• When your DNS provider or registrar changes: Record formats, TTL handling, and nameserver workflows vary enough to justify a fresh review.
• After any migration incident: Update the checklist while the lessons are still fresh. Add the exact failure, the detection method, and the prevention step.

For the next migration, keep a simple action sheet with three columns: task, owner, and verification. That makes this article more than a guide; it becomes an operating procedure. A calm migration is rarely about one clever command. It is usually the result of disciplined preparation, small tests, and careful observation after cutover.

If you are planning the move now, the practical next steps are straightforward: size the VPS, build the environment, restore a test copy, lower DNS TTL, and schedule a cutover window with enough time to verify forms, email, SSL, cron, and logs. Then keep the old host alive until the new one has proven itself under real traffic.