Moving from shared hosting to a VPS changes the resources and operating responsibilities behind your website. Files, databases, DNS, TLS, email, queues and scheduled jobs all need a coordinated plan. A faster-looking server specification does not by itself fix slow queries, external API delays or application errors.
This checklist reduces interruption and data-loss risk by preparing a compatible destination, rehearsing the move and coordinating the final writes. A dynamic site may need a short write pause while reads remain available. Define what users can do during the transition rather than promising that every request and transaction will continue without interruption.
Migration Goals and When a VPS Helps
Define completion criteria before copying: acceptable service interruption, recoverable data point, key transactions and the conditions that trigger rollback. DNS caches will not all switch at once, and an open connection may keep using the old endpoint. Keeping both servers available is useful only if they do not accept divergent orders, comments or account updates.
Repeated resource-limit events and measured capacity pressure can justify a VPS, as can a need for supported runtime or service configuration control. First separate CPU, memory, I/O and application bottlenecks. Virtual machines may still share physical resources, so a VPS is not automatically faster, isolated from contention or more secure. Check allocation terms and whether updates, backups and incident response are managed or your responsibility.
Preflight: The Calm Before the Copy
Map what you actually have
Inventory code, uploads, databases and engines, runtime versions/extensions, scheduled tasks, queues, session storage and all other writers. Record registrar/DNS access, TLS, mailboxes, SMTP, CDN origin settings, payment callbacks and external IP allowlists. Check what the shared host permits: SSH, rsync, database export and panel backups are not universal. If a tool is unavailable, prepare a supported encrypted-transfer or backup/restore alternative.
Decide what changes now vs. later
Prepare a supported runtime compatible with the application and reproduce necessary configuration before changing performance settings. Do not copy an unsupported stack into production simply for parity; validate any required upgrade in advance as a separate compatibility task. Keep a protected, off-server backup of files, data and required configuration, and prove it restores into an isolated environment.
Get ahead of DNS
Lower only the DNS records that will change, early enough for their previous TTLs to expire. New TTLs do not clear existing caches; negative caching and serve-stale behavior can extend the overlap. A-record TTLs do not set parent NS or DS cache times. The DNS records guide explains those layers. Low TTL is neither an instant switch nor an instant rollback.
Lay the Foundation: Preparing Your VPS Like a Pro
Build a secure baseline
Use a supported OS, prepare the appropriate administrative user and SSH key, then test a second login and the needed privileges before restricting password or root access. Keep the current session and provider recovery console available. Apply updates and firewall rules for the actual management port and required services, covering IPv4 and IPv6. Keep database/cache services private. Add swap only from a measured memory plan; it does not replace RAM capacity.
Pick your stack and mirror what works today
Match application requirements for runtime version, extensions, SQL engine/version, character sets and collations. MySQL, MariaDB and PostgreSQL are not interchangeable restore targets. Recreate only the database privileges needed by the application, and check redirects, uploads, timezone and background process requirements. Update environment configuration explicitly so the test copy cannot accidentally connect to production data or queues.
SSL from the start
Prepare a valid certificate for the production hostname before changing traffic and verify its chain and renewal path. The official Let’s Encrypt overview explains domain validation. A local hosts-file override does not redirect the CA: use an appropriate DNS-01 workflow or coordinate HTTP-01 on the publicly reached endpoints. Monitor renewal failures and actual certificate expiry independently; Let’s Encrypt announced the end of its expiration-email service for June 4, 2025.
Performance knobs you’ll come back to
Use conservative, application-tested cache and process settings. Account for per-worker memory before increasing PHP-FPM concurrency, and reserve capacity for the OS, database and other services. Enable Redis only when the application’s cache/session integration requires it. Record baseline response time, errors, worker queues and resource use, then assess tuning changes against comparable traffic after migration.
Build a Staging Copy You Can Trust
Create a safe staging domain or use your hosts file
A staging hostname or a local hosts-file mapping can help preview the destination. Use the production hostname for final TLS, redirect, cookie and application checks. A hosts override affects only that client’s name resolution; it does not hide a publicly accessible VPS or redirect external payment callbacks. Protect the clone with authentication or network controls, and keep separate test credentials and side effects disabled.
Move files and the database for the first pass
Take the first file copy using an allowed transfer method; the rsync documentation covers incremental transfer, path semantics, dry-run and deletion options. Review source/destination and exclusions, retain actual uploads and do not copy a running database data directory as an ordinary file backup. Use a consistent database export and test the import. A server-only move with unchanged URLs does not require broad search-and-replace.
Hide staging from bots and curious eyes
Authentication or network restriction protects the staging copy. A robots rule or noindex directive is not access control, and Google does not support noindex inside robots.txt. A crawler must fetch a page to see a meta or HTTP noindex instruction. Isolate cache/session storage and suppress real customer emails, payment requests, webhooks and scheduled jobs; use sandbox destinations for tests.
Replicate redirects and edge behavior
If your old host had .htaccess or custom Nginx configs for redirects, mirror those rules now. Confirm www to non-www rules, trailing slashes, and HTTPS-only redirects. This is where subtle differences between servers can surprise you. Keep your rules simple and test the awkward URLs—category pages, legacy slugs, even 404s.
Consistent Data and a Controlled Cutover
Lower TTL and set your timing
Choose a staffed window based on a measured rehearsal, after allowing the previous DNS TTL to expire. Identify all writers, including comments, administrative updates, cron, queues and inbound webhooks. A blog can still receive writes while files are copied. Two or three synchronization passes do not guarantee a consistent final state; use a coordinated write pause or a proven replication/single-writer design.
Do a dry run of everything
Rehearse on the access-controlled destination: login, search, uploads, forms, redirects and a sandbox checkout. Route test email to controlled recipients and examine authentication/results. Measure export, import and final file synchronization time. Local hosts changes do not test external callbacks, so exercise those through a separately controlled test path without triggering real customer actions.
First rsync, then second rsync
The initial file pass reduces the final transfer volume. For cutover, coordinate all writers, take a consistent database snapshot and finish the uploads/file delta before allowing destination writes. In MySQL, single-transaction supports a consistent InnoDB snapshot; nontransactional tables and concurrent DDL need different handling. Separately dumping related tables does not preserve consistency. Check actual version/privileges plus routines, events and triggers, and validate the restore. A snapshot still omits writes made after its snapshot point.
An optional safety net with a reverse proxy
If the old shared host permits reverse-proxy configuration, a tested proxy can forward cached clients to the new application. Use the actual new origin destination to avoid a DNS loop, preserve the required Host/TLS behavior, and handle cookies, request bodies, client-address trust and long-lived connections correctly. Do not blindly retry writes. Where proxying is unavailable, plan a controlled read-only or maintenance response and accept its service limitation.
SSL and HSTS timing
Keep valid TLS throughout the move, including the old endpoint during overlap. Existing HSTS can prevent users from bypassing certificate errors; removing the header does not instantly clear cached policy. Test any HSTS change separately, and do not casually send parent-domain includeSubDomains or long max-age settings from a staging workflow. Verify certificates and redirects before changing live traffic.
The Switch: DNS Cutover, Instant Checks, and the Post-Migration Lap
Update DNS with confidence
After final synchronization and validation, update the intended A/AAAA or supported alias target. Test IPv4 and IPv6; an old AAAA can keep some clients on the previous host, and removing it also has a cache delay. If a CDN fronts the application, preserve the public CDN path and change its origin configuration instead of bypassing it. Verify DNS and full application transactions from representative networks.
Watch logs like a hawk
Watch old and new access/error logs, worker queues, data checks and mail flow through the planned overlap. The old application must not accept independent writes after the new writer starts. A quiet first hour does not prove all caches or integrations have moved. Keep recovery material and the old service until observed traffic, data and dependency checks satisfy the retirement criteria.
Restore TTL and confirm AAAA
Once you’re happy, raise the TTL to something reasonable. If you set an AAAA record, make sure the IPv6 path behaves the same as IPv4. It’s not unusual to have a firewall rule perfect for IPv4 and a little too strict for IPv6 by accident.
Post-migration essentials
Confirm only the intended cron and workers run, with pending jobs accounted for. Check uploads, sessions, mail and critical flows again. If mailboxes moved, synchronize existing and newly arrived messages separately; MX changes do not copy them. For direct VPS sending, confirm provider/port rules, PTR through the IP provider and matching forward DNS, then inspect SPF/DKIM/DMARC and controlled delivery tests. Verify CDN origin/cache behavior and take a new protected backup with an isolated restore check.
Warm only content safe to share, at a controlled request rate. Exclude carts, checkout, account pages, personal responses and inappropriate authenticated/cookie-bearing requests from shared page caches. Check cache keys and invalidation rules. A cold cache may contribute to initial latency, but warming it does not fix worker exhaustion, slow queries or a wrong origin.
Common Migration Problems and Checks
Permissions and ownership
A permissions mismatch can prevent code from loading or stop uploads, cache and sessions from being written. Check the actual error and effective service user. Grant only the necessary read/write access to the intended paths; broad permissions can hide the cause and expose application data. Recheck ownership after copying files between different hosting accounts.
Missing PHP extensions and limits
Compare the required PHP/runtime extensions and effective limits using private diagnostic access. Do not leave a public phpinfo page exposing configuration or secrets. Upload failures can arise from permissions, web-server limits, disk capacity or libraries as well as memory. Use the actual error and request path to identify which layer needs adjustment.
Absolute URLs and mixed content
If your site was forced to HTTP on the old host and you’re now serving true HTTPS, some hard-coded links can point to old HTTP resources, causing mixed content warnings. Fix these early and keep an eye on your redirects so you don’t trap users in a loop.
Serialized data in databases
Only replace URLs when the public address or an actual stored reference changes. Back up the database, scope the affected tables/columns and preview the result with a serialization-aware tool such as WP-CLI search-replace. A blind SQL text replacement can corrupt serialized values. Follow platform guidance for GUIDs and multisite scope, and verify the resulting links and settings in the clone before applying a needed migration change.
Background jobs and workers
Prepare scheduler and worker definitions without activating duplicate producers in staging. During cutover, stop or coordinate old writers, account for in-flight and queued jobs, and start only the designated new workers against the correct queue. A process manager restarting after reboot does not migrate queue contents. Test retries and idempotency so a redelivered job does not duplicate a payment, email or external update.
Emails from the server
Choose deliberately between an external SMTP provider and operating outbound mail on the VPS. Verify credentials, network/port access, TLS and provider limits; inspect SMTP responses and message authentication results. MX concerns inbound delivery, while PTR is managed by the sending-IP provider. SPF, DKIM, DMARC and reverse DNS contribute to acceptance decisions but do not guarantee delivery to every recipient.
A Realistic Rollback Plan (Just in Case)
Define rollback triggers, a responsible operator and a recoverable old environment before cutover. Before the new system accepts writes, returning is simpler. After new orders or updates arrive, coordinate writes and safely transfer the new data before directing traffic to an old database; changing DNS alone can lose or fork data. DNS reversal and cache clearing are not instant client redirection. Validate data and service behavior before ending the recovery window.
The Complete Checklist (Told Like a Friend)
Before anything
Verify account access and record service dependencies without putting secrets in ordinary notes. Capture the current configuration, DNS values, writers and required user flows. Create an off-server backup and test its restore. Lower relevant TTLs early enough for old values to expire; choose a protected preview path and define the final synchronization and rollback criteria.
On the VPS
Prepare a supported compatible stack, administrative access, valid TLS, monitoring and backups. Prove the new SSH key and recovery path before tightening access, and cover the actual ports plus IPv4/IPv6 in firewall rules. Keep database/cache access private. Rehearse any required version change before migration rather than assuming different database engines or unsupported versions are equivalent.
First migration pass
Copy files and a consistent database snapshot, correct environment paths and least-privilege permissions, and preview through the intended hostname. Keep the clone authenticated/network-restricted with production side effects disabled. Verify redirects, HTTPS, uploads and key data; use sandbox payments and controlled email tests. Measure the time needed for the final delta.
Final sync and cutover
Coordinate every writer, including background and webhook paths; finish the consistent database and uploads delta; then validate before enabling the new writer. Change the intended DNS or CDN origin target. Keep old cached clients in a tested proxy, read-only or maintenance path so they cannot create divergent writes. Check service and data outcomes immediately and retain the rollback plan.
Aftercare
Check logs, data, sessions, mail, scheduled jobs and workers on both sides. Verify live indexing/canonical settings and remove unintended staging restrictions only on the production destination. Raise TTLs after stability is established. Back up the new environment and test recovery; retire the old service only after the agreed traffic, data, DNS and mail checks pass.
Completing and Measuring the VPS Migration
A verified migration has a compatible destination, recoverable data, safe writer ownership and evidence that required services work. Reads may remain available while writes pause, but that is a service choice to communicate and measure. Preparation reduces interruption risk; it is not a universal promise of invisible cutover or unlimited new capacity.
Keep a record of the final data point, configuration changes, operator responsibilities and recovery checks. Compare performance against the old environment under a similar workload before judging the benefit. Preserve public URLs, redirects, canonical and sitemap behavior for a host-only move; if URLs actually change, plan appropriate permanent redirects separately.
Use the checklist as a starting point for your application’s actual dependencies. Revisit the plan when hosting, DNS, mail or runtime versions change, and retain the lessons from the rehearsal and observed cutover so the next migration can be assessed against real evidence.
