WordPress Migration Checklist

1. Before you touch anything – The pre-migration audit

Most WordPress migrations go wrong before the migration even starts. The problem is almost always the same: people jump into the process without knowing exactly what they are moving.

Spend 30 minutes here and you will save hours later.

Inventory your site first:

On a migration last year involving a client’s 6GB WooCommerce store, we nearly lost three years of order history because nobody checked that the database export was excluding the wp_wc_order_stats table. Always verify what your export actually contains before you touch the live site.

The other thing most tutorials skip: check your DNS TTL before anything else. Log into your domain registrar and drop your TTL to 300 seconds (5 minutes) at least 24 hours before migration day. Default TTLs are often 86400 seconds — 24 hours. If you forget this step, your DNS cutover will take a full day to propagate globally instead of minutes.

Also read: WordPress Tips and Guides

2. Backup everything — twice

Non-negotiable. Before any migration you need two independent backups in two different locations. One backup is not a backup, it is a single point of failure.

Backup method 1 — your current host’s backup tool: Every decent host has one. Download the full backup file to your local machine. Do not leave it only on the host’s servers — if something goes catastrophically wrong with the host, that backup goes with it.

Backup method 2 — a plugin backup:

The two most reliable free options are UpdraftPlus and All-in-One WP Migration. Use one of these to create a second independent backup and send it to a cloud destination — Google Drive, Dropbox, or S3. This takes 10 minutes to set up and has saved migrations more than once.

What your backup must include:

• Full database (all tables, not just wp_ prefixed ones if you have custom tables)
• All files under /wp-content/ including uploads, themes, and plugins
• wp-config.php
• .htaccess
• Any custom files outside the standard WordPress directory structure

What you do not need to back up:

• WordPress core files — these get reinstalled fresh at the destination
• Cache files — delete these before backing up, they add size for no reason

Before proceeding, verify your backup actually works. Open the zip file. Confirm the database .sql file is there. Confirm the wp-content folder is there. A corrupt backup discovered mid-migration is a bad situation.

3. Set up the new host before touching DNS

This is the step that separates clean migrations from messy ones. Your new hosting environment should be fully configured and your site should be running on it before you change a single DNS record.

New host setup checklist:

• Create hosting account and set up a new WordPress install
• Match PHP version to your current host (check via phpinfo())
• Set up a temporary URL or use the host’s staging subdomain to access the new site
• Configure SSL on the new host before going live
• Install the same WordPress version as your current site
• Create the destination database and note the credentials

Most managed hosts — Cloudways, Kinsta, WP Engine — give you a temporary URL (something like yoursite.cloudwaysapps.com) to work with before DNS cutover. Use it. Test everything on this URL before touching your domain.

Also read: WordPress Tips and Guides

4. The actual migration — three methods ranked

Method 1: Host-provided free migration (fastest, recommended)

In 2026, most quality hosts migrate your site for free. Cloudways, Kinsta, WP Engine, and Hostinger all offer free migration as standard. You submit a request, give them your current host credentials or a backup file, and they handle the move. Typical turnaround is 2–12 hours.

This is the right call for 80% of migrations. It costs nothing, requires minimal technical knowledge, and the host takes responsibility if something breaks.

Method 2: All-in-One WP Migration plugin (easiest DIY)

Export your entire site as a single .wpress file. Install WordPress on the new host. Install All-in-One WP Migration. Import the file. Done. Works reliably for sites under 512MB. Above that, the free version hits upload limits — you need the $69 premium version or to increase upload_max_filesize in php.ini.

Method 3: Manual migration (most control)

Export your database via phpMyAdmin. Transfer files via FTP or SFTP. Import the database on the new host. Update wp-config.php with new database credentials. Run a search-replace on the database to update URLs if your temporary staging domain differs from your live domain. Use WP-CLI for the search-replace:

wp search-replace 'https://oldsite.com' 'https://newsite.com' --all-tables

Manual migration takes longer but gives you complete control and works for any site size. It is the only reliable method for very large sites (10GB+) or sites with complex multisite setups.

5. Search-replace and URL updates

This is where most DIY migrations produce broken sites. When you move from one domain or staging URL to another, WordPress has hardcoded URLs throughout the database — in posts, meta fields, widget settings, and serialized option values. A simple find-and-replace in phpMyAdmin will break serialized data. You need a tool that handles serialization correctly.

Recommended tools:

• WP-CLI search-replace — fastest and most reliable if you have SSH access
• Better Search Replace plugin — free, handles serialized data, no SSH needed
• Interconnect/it Search Replace DB script — good for large databases

Run the search-replace after importing the database but before going live. Always do a dry run first:

wp search-replace 'https://staging.cloudwaysapps.com' 'https://yoursite.com' --all-tables --dry-run

Review the dry run output, then run it without --dry-run.

Common URLs to search-replace:

• Old domain → new domain
• HTTP → HTTPS if you are adding SSL
• Staging subdomain → live domain
• Old host’s CDN URLs if applicable

6. Pre-launch testing checklist

Do not cut over DNS until every item on this list is checked on the staging/temporary URL.

Functionality:

• Homepage loads correctly
• Internal links work
• Images load (check a post with multiple images)
• Contact forms submit and deliver email
• WooCommerce checkout completes a test order (use a $0.01 product)
• Search works
• User login and registration works
• Comments load and post

Technical:

• SSL certificate active and no mixed content warnings
• No broken links (run Broken Link Checker plugin)
• No PHP errors in debug log (define('WP_DEBUG', true) temporarily)
• Page speed baseline matches or beats old host (run WebPageTest)
• Caching plugin configured and working
• Cron jobs recreated if applicable
• 301 redirects recreated if you had any

Email:

• WordPress transactional email sending correctly (test with a form submission)
• If using SMTP plugin, update credentials for new host environment

Performance data referenced from WebPageTest.

7. DNS cutover and going live

Your site is tested, everything works on the staging URL, and you are ready to go live. Here is the exact sequence.

Cutover sequence:

1. Confirm DNS TTL is already at 300 seconds (you did this in step 1)
2. Log into your domain registrar
3. Update nameservers or A record to point to the new host’s IP
4. Wait 5–15 minutes for propagation (fast because of the low TTL)
5. Visit your site — confirm it is loading from the new host
6. Check SSL is active on the live domain
7. Run the search-replace one final time if your staging URL differed from the live URL
8. Flush all caches (hosting cache, plugin cache, Cloudflare if applicable)
9. Submit updated sitemap in Google Search Console
10. Monitor error logs for the first 24 hours

Keep the old host active for 48–72 hours after cutover. Do not cancel immediately. DNS propagation is mostly complete in minutes with a low TTL, but some ISPs cache longer. Having the old host live means those users still reach your site during propagation.

After 72 hours:

• Cancel old hosting if no longer needed
• Remove migration plugins from the new install
• Set DNS TTL back to 3600 or higher
• Confirm Google Search Console is indexing the new URLs correctly

8. Post-migration — the checks people skip

Most migration guides end at DNS cutover. These are the things that break quietly after migration and only get noticed weeks later.

Analytics and tracking: Google Analytics, Facebook Pixel, and other tracking scripts often need the domain updated in their respective dashboards. Check that your analytics are recording sessions correctly within 24 hours of going live.

Affiliate and ad code: If you have affiliate links or ad network code referencing the old domain, update them. Some affiliate programs tie payouts to a specific domain.

Google Search Console: Add the new host’s site as a property if you changed domains. If you stayed on the same domain, verify coverage has not dropped. Submit your sitemap.

Uptime monitoring: Set up a free uptime monitor (UptimeRobot is free for 50 monitors at 5-minute intervals) on the new host. You want to know immediately if the new host has reliability issues.

Backups on the new host: Confirm automated backups are configured and running on the new host. Do not assume they are on by default — check.

Performance baseline: Run a WebPageTest or GTmetrix test and save the results. This gives you a before/after comparison and a baseline to diagnose any future performance issues.

Also read: WordPress Tips and Guides