How to Move WordPress to a VPS with Minimal Downtime

Moving WordPress to a VPS is both an application migration and a transfer of operational responsibility. On shared or managed hosting, the provider usually owns part of the web server, PHP, database, backups, security updates, and monitoring. On a self-managed VPS, those controls become your responsibility.

Quick answer: Build and secure the VPS before copying production data. Match the required PHP and database behavior, configure the web server, TLS, backups, cron, email, and monitoring, then make an initial file and database copy. Test the destination under the real hostname without changing public DNS. During a controlled cutover, stop writes on the old site, synchronize the final database and mutable files, switch DNS or the proxy origin, and keep the old host available until traffic and data integrity are confirmed.

Minimal downtime is not the same as zero downtime

A short maintenance window is often the safest design for a single WordPress database. “Zero downtime” requires more than a low DNS TTL: both origins must handle sessions, uploads, cache, cron, and database writes consistently. Without replication or a shared write path, allowing both copies to accept changes can split orders and accounts across two databases.

This guide targets minimal, controlled downtime. If the site has strict continuous-availability requirements, the architecture needs a separate design rather than a faster copy command.

Confirm that a VPS solves the actual problem

A VPS provides control over the operating system, web server, PHP workers, database, storage, and network policy. It also introduces patching, access control, capacity planning, backup, monitoring, and incident response. It will not fix inefficient queries, unsafe plugins, or an unbounded background queue.

Before migrating, document why the current platform is insufficient: resource throttling, missing extensions, traffic growth, deployment constraints, or the need for server-level integration. A measurable requirement is more useful than assuming a VPS is automatically faster.

Choose the target architecture before provisioning

Decide whether the VPS will run the database locally or use a managed database, whether media stays on local storage, and whether a CDN or reverse proxy sits in front. Identify the failure domain: a single VPS that hosts web, database, cache, and backups can lose every layer in one incident.

Size CPU, RAM, storage, and I/O from observed traffic and workload rather than page count. Leave headroom for deploys, backup compression, cache warm-up, traffic bursts, and database maintenance.

Build a secure server baseline

Start with a supported operating system image and apply security updates. Create a named administrative account, use key-based SSH access, restrict privileged access, configure a host or provider firewall, synchronize time, and record the recovery-console path before tightening remote access.

Do not disable the only working login method until a second session has successfully tested the replacement. The initial Linux server setup checklist and SSH hardening guide cover these controls in detail.

Install a compatible WordPress runtime

The destination needs a compatible web server, PHP runtime and extensions, and MySQL or MariaDB. The official WordPress server-configuration handbook identifies web serving, permissions, database, mail, and domain routing as separate parts of the environment.

Match production behavior first. A PHP major-version upgrade, database-engine change, and migration performed at the same time create several possible causes for every failure. Upgrade separately after the site is stable unless the old runtime cannot be safely reproduced.

Configure permissions without making everything writable

The deployment user, web-server user, and PHP process may have different responsibilities. Give the runtime write access only where WordPress actually needs it, such as controlled upload or cache paths. Do not use chmod 777 as a migration shortcut.

Confirm ownership after copying files. A site may render correctly while media uploads, plugin updates, cache purge, or log creation fail because the new process cannot write to the expected path.

Prepare database, cron, email, cache, and TLS

Create a dedicated database and least-privilege application user.
Configure real server cron if the existing site depends on it.
Choose an SMTP or relay path and verify SPF, DKIM, and provider policy where applicable.
Configure page and object cache deliberately; do not copy stale cache files.
Prepare TLS issuance and renewal for the final hostname.
Install monitoring before cutover, not after the first outage.

Take an initial copy while the old site remains live

Create a restorable backup first. Copy immutable and slowly changing files to the VPS, then export and import an initial database snapshot. For large uploads, an incremental tool such as rsync can make the final pass shorter.

rsync -aH --dry-run --itemize-changes /SOURCE/ USER@VPS:/DESTINATION/
rsync -aH /SOURCE/ USER@VPS:/DESTINATION/

The paths and account are placeholders. Verify both endpoints and review the dry-run output before copying. Archive mode preserves several attributes; whether ownership and permissions should be preserved depends on the destination design. This example intentionally omits deletion flags.

Export and import the database deliberately

WP-CLI can perform database operations using the credentials in wp-config.php. Its official database command reference includes export, import, check, and size operations. Run commands from the correct WordPress root and keep exports outside public web paths.

Do not place database passwords directly in shared command history. After import, compare table counts, inspect errors, and test WordPress reads and writes. If the public domain remains unchanged, changing servers does not require a database-wide URL replacement.

Test the VPS before public DNS changes

Map the real hostname to the VPS IP on an authorized test workstation or use a controlled preview method. The real hostname is important for virtual-host selection, cookies, redirects, CORS, and TLS. A raw-IP test cannot validate all of those behaviors.

Test pages, login, media, search, REST API, loopback requests, cron, email, cache, and the main business journey. For WooCommerce, use sandbox payment and prevent the preview copy from sending live webhooks or customer messages.

Measure the VPS under representative load

A successful single request does not prove capacity. Observe PHP-FPM queueing, database latency, CPU, memory pressure, disk I/O, and error rates while exercising representative cached and dynamic routes. Use controlled load that cannot create real orders or overwhelm the source platform.

Set worker and connection limits from measured memory and concurrency. Raising every limit can move the failure from a queue to OOM termination.

Prepare DNS and the cutover runbook

Lower relevant TTLs at least one previous-TTL period before the migration. Record the current A, AAAA, CDN origin, and rollback values. Define who can start the maintenance window, who changes traffic, what tests must pass, and which failure triggers rollback.

The broader WordPress hosting migration checklist explains why the old origin must remain available while cached DNS answers expire.

Run the final synchronization

Enable a controlled maintenance or read-only state on the old site.
Stop or isolate cron, workers, email, and webhooks that could run twice.
Export the final database and import it into the VPS.
Synchronize new uploads and other mutable files.
Recheck configuration, ownership, cache, and application health.
Enable production processing only on the selected origin.

Record the time of the final successful write on the old system. This establishes the data boundary for verification and rollback.

Switch traffic and monitor both origins

Change the DNS records or CDN origin, including IPv6 where applicable. Confirm the public certificate, HTTP status, canonical URL, and response from multiple networks or resolvers. Watch access logs on both systems to understand where real users are landing.

Monitor user-visible availability alongside CPU, RAM, disk, PHP-FPM, database, and queue signals. The server monitoring guide provides a practical signal checklist.

Define rollback around data, not only DNS

Pointing traffic back is simple only before the VPS accepts new writes. Once it has received orders, uploads, or account changes, the old database is stale. The rollback plan must explain how those records will be reconciled and who decides whether rollback is still safer than fixing forward.

Keep the old host intact and prevent writes until the observation period ends. Do not delete it merely because the new homepage responds.

Post-migration operations

Confirm automated backups and perform a separate restore test.
Verify operating-system, PHP, database, and WordPress update ownership.
Test TLS renewal, disk alerts, external uptime checks, and log rotation.
Review firewall rules, listening ports, and administrative accounts.
Raise DNS TTL after the migration is stable.
Decommission the old host only after retention and rollback requirements are met.

Common VPS migration mistakes

Treating the VPS as a faster shared-hosting account
Changing PHP, database, and web server during the same cutover
Copying stale cache and session files
Running cron, email, or payment callbacks on both origins
Using broad permissions to hide ownership problems
Switching DNS before testing with the final hostname
Keeping backups only on the VPS they protect
Planning DNS rollback but not data reconciliation

When should you use a managed migration?

If the site processes live orders, has a large media library, uses custom workers, or lacks a tested server baseline, the highest risk is coordination rather than file transfer. The WordPress migration service covers destination preparation, staged synchronization, cutover, and post-migration verification for these cases.

Frequently asked questions

Can WordPress run on a small VPS?

It can, but the right size depends on dynamic traffic, PHP concurrency, database workload, cache behavior, and operational headroom. Measure the workload instead of choosing by page count.

Do I need to change WordPress URLs?

No, not when the public domain, scheme, and path remain the same. Moving to a new IP or server does not by itself require search-and-replace.

Can I keep both servers active during DNS propagation?

Both can serve read traffic, but allowing independent writes is unsafe without a shared or replicated data design. A controlled write boundary is essential.

Should the database run on the same VPS?

That can be reasonable for a modest workload, but it combines resource contention and failure domains. Base the decision on capacity, recovery requirements, and operational capability.