How to Migrate a WordPress Site to a Dedicated Server Without Downtime

Moving WordPress from shared hosting or a VPS to a dedicated server gives you more resources, steadier performance, and full control over your environment. The move itself is where things go wrong: a missed database change, an untested configuration, or a poorly timed DNS switch can mean broken pages or lost orders.

A guaranteed zero-downtime move isn't realistic for every site. Blogs and brochure sites are easy, because little changes between your first copy and the cutover. WooCommerce stores, membership sites, and forums keep receiving orders, registrations, and comments, so they need a short write freeze during the final sync. This guide covers both cases.

What You'll Need

• Root or sudo access to the new dedicated server

• SSH access to the old server, or a complete backup you can restore

• Access to your domain's DNS settings

• A recent backup stored somewhere independent of both servers

• Enough free disk space on the new server for files, the database, and temporary migration files

• A plan for SSL (covered in Step 9)

This guide assumes a Linux server, MySQL or MariaDB, and Nginx or Apache. Paths and commands may differ on other stacks.

Step 1: Audit the Existing Site

Document the current environment so you can reproduce it:

• WordPress version, active theme, and installed plugins

• PHP version and required extensions

• MySQL/MariaDB version

• Web server type and virtual host configuration

• Database size and total WordPress directory size

• Cron jobs, including system cron replacing WP-Cron

• Email setup (SMTP, SPF, DKIM), CDN, firewall rules, and caching

If you have SSH access, these commands give you a baseline:

php -v
mysql --version
du -sh /path/to/wordpress

If WP-CLI is installed, run these from the WordPress directory:

wp core version
wp plugin list
wp theme list
wp db size

Some hosts restrict command-line access, in which case use the hosting control panel instead.

Step 2: Lower Your DNS TTL

TTL (Time to Live) controls how long resolvers cache your DNS answers. A long TTL means some visitors keep reaching the old server after you switch.

At least 24-48 hours before migration:

• Open your DNS provider and find the A record for your root domain and relevant subdomains, plus the AAAA record if you use IPv6.

• Reduce the TTL to around 300 seconds if your provider allows it.

• Wait for the previous, longer TTL to expire before relying on the new value.

A short TTL speeds up the switch but does not make it instant, and some resolvers cache longer than they should. If your DNS runs through a proxy or CDN, your public records may point at the proxy rather than your server, so adjust your cutover plan accordingly.

Step 3: Prepare the New Dedicated Server

Build an environment that closely matches the old one, so WordPress behaves the same way.

• Install the stack: Nginx or Apache, PHP (with PHP-FPM where applicable), MySQL or MariaDB, a firewall, and secure SSH access. Common WordPress extensions include mysqli, curl, gd, mbstring, xml, zip, and intl. Your theme and plugins may require others.

• Create the database: Make a dedicated database and a separate user with only the privileges WordPress needs, protected by a strong, unique password.

• Configure the web server: Create a virtual host (Apache) or server block (Nginx) with the correct document root, PHP handling, and rewrite rules. A typical document root is /var/www/yourdomain.com. Use restrictive ownership and permissions rather than making everything writable.

• Change one thing at a time: Don't upgrade PHP, WordPress, and plugins during the move. Migrate on a compatible environment first, confirm it works, then upgrade separately so any problem is easy to trace.

Step 4: Back Up Files and Database

A complete backup includes WordPress core files, themes, plugins, uploads, custom configuration, and the database. Copying the directory alone isn't enough, because posts, users, settings, and orders live in the database.

Export the database:

mysqldump -u dbuser -p --single-transaction dbname > wordpress-backup.sql

The --single-transaction option gives a consistent snapshot of transactional tables such as InnoDB without locking the site for the whole export. It does not cover non-transactional tables, and it doesn't capture writes that happen after the snapshot. If your database mixes storage engines, use a backup method that guarantees consistency.

Compress it to speed up transfer:

gzip wordpress-backup.sql

Store the backup securely, since it may contain personal data, and confirm it can actually be restored.

Step 5: Transfer the Files

rsync over SSH is the best tool here because it's resumable and later runs transfer only what changed. Run this from the new server:

rsync -avz --progress user@OLD_SERVER_IP:/path/to/wordpress/ /var/www/yourdomain.com/

The trailing slash on the source copies the directory's contents into the destination. After the transfer, confirm that uploads, custom directories, and hidden files such as .htaccess came across, and check ownership and permissions.

Avoid adding --delete unless you fully understand it, because it removes destination files that aren't present in the source. If SSH access to the old server isn't available, use SFTP or your host's backup and restore feature instead.

Step 6: Import the Database

Decompress the backup if needed, then import it into the new database:

gunzip wordpress-backup.sql.gz
mysql -u newdbuser -p newdbname < wordpress-backup.sql

Make sure the target database is empty and meant for this migration, since importing into a database with live data can cause conflicts or duplicates. If the import fails, the usual causes are insufficient privileges, version incompatibility, a missing database, or packet and resource limits. The error message and database logs will point to which.

Afterward, verify the tables exist. With WP-CLI configured, you can also run:

wp db check

Step 7: Update wp-config.php

Point WordPress at the new database:

define( 'DB_NAME', 'newdbname' );
define( 'DB_USER', 'newdbuser' );
define( 'DB_PASSWORD', 'your-strong-password' );
define( 'DB_HOST', 'localhost' );

DB_HOST may differ if your database runs on a separate machine. Keep your existing authentication salts and table prefix, and don't expose credentials in repositories, screenshots, or logs.

Does the site URL need to change? If your domain, protocol, and install path stay the same, no database search-and-replace is needed. If any of those change, use WP-CLI, which handles serialized data correctly. Take a backup first and preview with a dry run:

wp search-replace 'https://old-domain.example' 'https://new-domain.example' --dry-run

See the WP-CLI search-replace documentation for details.

Step 8: Test Before Changing DNS

A hosts file override lets only your own computer reach the new server using the real domain name, while everyone else still sees the old site.

Edit /etc/hosts on Linux or macOS, or C:\Windows\System32\drivers\etc\hosts on Windows, and add a line using your new server's IP (the one below is an example):

203.0.113.10 yourdomain.com www.yourdomain.com

Then browse the site and check:

• Homepage, inner pages, and custom post types

• Permalinks (if inner pages return 404, check your rewrite rules, then try wp rewrite flush)

• Admin login and dashboard

• Images, uploads, and downloads

• Forms and transactional email

• WooCommerce cart, checkout, and payments in test mode, if applicable

• Plugin behavior, scheduled tasks, and caching

• Browser console errors and server logs

Remove the hosts entry when you're done.

Step 9: Set Up SSL Before Cutover

The new server must serve valid HTTPS before visitors arrive. There are two common approaches:

• DNS-01 validation: Issue a Let's Encrypt certificate by proving domain control through a DNS TXT record, which works before your A record points at the new server. Renewal is easiest when your DNS provider supports API-based record updates. See the Let's Encrypt challenge types documentation.

• Transfer an existing certificate: Securely copy the certificate and private key to the new server, restrict access to the key, and configure the web server to use them.

Whichever you choose, confirm the certificate covers every hostname visitors use and that the full chain is valid.

Step 10: Final Sync and DNS Cutover

How you do this depends on how much your site changes.

• Blogs and mostly static sites: Run a final rsync to catch new uploads, export and import the latest database, then update DNS. Account for any posts, comments, or admin changes made since your first copy.

• WooCommerce, membership sites, and other dynamic sites: Don't just re-export the database while both servers keep accepting writes, because the two databases will diverge. Use a controlled write freeze:

  • Announce a maintenance window if needed.

  • Pause anything that writes to the old database, including scheduled tasks, background jobs, and third-party integrations. Maintenance mode alone may not stop all of them.

  • Run the final rsync.

  • Export the final database and import it on the new server.

  • Verify the destination database and essential functions.

  • Update DNS.

  • Keep writes disabled on the old application for as long as requests might still reach it.

Updating DNS: Change the A record (and AAAA if applicable) for the root domain, www, and any other affected subdomains, then confirm with a DNS lookup tool that the new answers are returned. Make sure the new server is properly configured for IPv6 if you keep AAAA records.

Never let both servers independently accept orders or other critical writes unless you've designed and tested a data synchronization strategy for it. For transaction-heavy stores, a reverse proxy that sends all requests to a single authoritative application during the transition is a safer option.

Step 11: Verify and Monitor

Check the response first:

curl -I https://yourdomain.com

A successful response doesn't prove everything works, so also test real workflows. Confirm that:

• The domain resolves to the intended destination

• HTTPS works without warnings

• Admin access and database connections are stable

• Forms, checkout, and payment integrations work

• New orders and registrations land in the new database

• Cron jobs and email delivery run as expected

• Logs show no persistent PHP errors, database failures, or unexpected 404s

• Automated off-server backups are running

Keep the old server available for at least 48-72 hours as a fallback, longer if your traffic or DNS behavior warrants it. Once things are stable, raise the TTL back to a normal value and shut down the old server only after confirming nothing still depends on it.

Troubleshooting Common Problems

Mistakes That Cause Most Migration Problems

• Skipping the hosts file test and discovering problems on live traffic

• Copying files without the database

• Mismatched PHP versions or missing extensions

• Forgetting cron jobs, email records, CDN settings, or SSL

• Upgrading several components during the move

• Treating a loading homepage as proof the whole site works

• Canceling the old server before the new one is verified

Post-Migration Checklist

• Domain and subdomains resolve correctly, with valid HTTPS

• Permalinks, admin login, uploads, and forms work

• WooCommerce checkout and order creation tested, if applicable

• Scheduled tasks and email delivery confirmed

• Server logs reviewed for errors

• Off-server backups configured and restore-tested

• Firewall and security rules updated for the new server's IP

• Google Search Console monitored for crawl errors

• Page speed compared against your pre-migration baseline

Final Thoughts

A smooth migration comes down to preparation and control over the handoff. Audit the old site, back it up, build a compatible server, test it through a hosts file override, set up SSL in advance, and coordinate the final sync carefully, especially for sites that accept new data constantly. A clear rollback plan and a few days of monitoring turn a risky move into a routine one.

If your site needs dedicated resources and full control over its environment, explore GTZHost's dedicated server plans to find a configuration that fits your workload.