How to Migrate Your WordPress Site to a New Host Without Any Downtime

Pre-Migration Checklist: What to Verify Before You Touch Anything

Migrations that go wrong almost always fail because of something that was wrong before the migration started. Taking 30 minutes to audit the current state of the site prevents a class of problems that are difficult to diagnose mid-cutover when you are under time pressure.

Start by documenting the current WordPress version, PHP version, and the versions of the five most critical plugins. Note any custom php.ini settings or .htaccess rules that are specific to the current host. Confirm that you have working admin credentials for the WordPress dashboard and direct database access via phpMyAdmin or the command line.

Verify that your domain's current DNS TTL is visible and note its value. If it is set to 86400 (24 hours), you need to lower it now (before anything else) because changes to TTL take one full TTL cycle to propagate. Drop it to 300 (five minutes) immediately and give it 24 hours to take effect before you proceed with the migration.

Take a full manual backup at this stage: a complete database export and a compressed archive of the wp-content directory. Even if your current host provides automated backups, having a copy you personally made and verified is insurance against the automated backup being incomplete or pointing to files you cannot easily retrieve.

Exporting Your Database and Files Correctly

The WordPress database holds your content, settings, users, and plugin configuration. Export it via phpMyAdmin using the Quick export method with SQL format, or via the command line if you have SSH access. A command-line export via mysqldump is faster and less prone to timeout on large databases.

Check the resulting SQL file is not zero bytes and contains CREATE TABLE statements near the top. A common failure mode is that the export completes but the download is truncated, leaving you with an apparently valid file that fails on import.

For files, the minimum set required is the wp-content directory — themes, plugins, and uploaded media. If you are moving the entire WordPress installation rather than just the site content, include wp-config.php, wp-includes, and the root-level .php files. Compress the archive before transfer; a 500 MB uncompressed directory transfers more reliably as a 200 MB gzip than as thousands of small files over an FTP connection.

Setting Up the New Environment and Importing Data

On the new host, create a fresh database and a database user with full privileges on that database. Record the hostname, database name, username, and password carefully — you will need them for wp-config.php.

Import the SQL dump into the new database. In phpMyAdmin, use the Import tab and select the file. For databases over 50 MB, the upload limit may be lower than the file size; check the max_allowed_packet and upload_max_filesize settings in the panel, or import via the command line where size limits do not apply.

Upload the wp-content directory to the new host's public root. Then place wp-config.php in the root, updating the database credentials to point to the new database. Do not change the WordPress home or site URL values in wp-config.php at this stage — those will point to the live domain and will be updated automatically when DNS changes.

If the new server's PHP version differs from the old one, test that all active plugins load without fatal errors by accessing the site via its temporary preview URL before making any DNS changes.

Lowering DNS TTL Ahead of Cutover

If you have not already done this, lower your DNS TTL now and wait for it to propagate. The goal is to minimise the window during which different users around the world see different A records after you change the DNS. A 300-second TTL means most resolvers will pick up the change within five minutes of your DNS update.

During the 24 hours between lowering the TTL and making the final change, your site continues serving from the original host with no interruption. This window is also a useful time to complete your file transfer and database import at a relaxed pace.

Testing on the New Host Before Going Live

Most hosts provide a temporary preview URL or allow you to test via a modified local hosts file. Use one of these methods to browse the site on the new server and confirm that pages render correctly, images load, forms submit, and plugin functionality works as expected.

Check the WordPress admin panel at the preview URL. Verify that the database connection is live by looking at a post count, a user list, or a settings page that reads from the database. Run any caching plugin's cache-clear function to eliminate stale cache entries that might mask database connectivity issues.

The configuring WordPress on shared infrastructure documentation covers PHP version selection, .htaccess optimisation, and the LiteSpeed cache configuration that is available on NVMe shared plans — worth reviewing before the cutover so you can enable the right caching layer on day one.

The DNS Flip: Timing It Right and Confirming Propagation

Choose your cutover window deliberately. A Tuesday at 2am in your primary user timezone is not glamorous, but it is a window where traffic is at a natural low, which means fewer in-progress sessions are interrupted and you have time to react to problems before peak hours.

Update the A record at your DNS provider to point to the new host's IP address. If you have AAAA records, update those too. If you are using a CDN, update the origin IP in the CDN configuration rather than just changing the domain's A record.

Use an online propagation checker to monitor the change spreading across major DNS resolvers globally. Within five minutes of the change, the majority of users should be hitting the new server. Within 30 minutes, propagation is typically complete outside of edge cases in high-TTL ISP caches.

Post-Migration Checks and What to Do If Something Breaks

Once DNS has propagated, run through a post-migration verification checklist. Confirm SSL certificate is valid on the new host. Test a contact form submission from end to end. Check that images in posts are loading correctly from the new server. Submit a test e-commerce order if applicable. Verify that the WordPress admin dashboard loads and that no plugin is reporting a configuration error.

If you discover that media files are missing, re-upload the wp-content/uploads directory from your backup. If plugin errors appear, the most common cause is a PHP version mismatch — check the version in the new host panel and adjust it to match the original if possible, or contact the plugin developer with the specific error message.

Keep the old hosting account active for at least 72 hours after a successful cutover. This ensures you have access to the original database and files if a problem surfaces after propagation is complete. Only cancel the old account once you are confident the migration was clean and you have a verified backup on the new host.