The WordPress Migration Checklist We Actually Use

A WordPress migration is more than copying a wp-content folder somewhere new. The site's own address is baked into its database, plugins reference file paths, and forms, redirects and cron jobs all quietly assume they are still on the original server. This checklist is built around the specific things that break when one of those assumptions gets missed.

Before you touch anything: take inventory

Start by writing down what the site actually depends on, not just what's in the file manager. This step feels slow but saves far more time than it costs, because it turns migration from guesswork into a list you can check off.

• WordPress core files, themes and plugins in wp-content
• The full MySQL/MariaDB database
• Uploaded media in wp-content/uploads
• Any custom code outside the standard plugin/theme structure
• Cron jobs, both WordPress scheduled events and server-level cron
• SSL certificate details, if not simply reissuing on the new host
• Email accounts tied to the domain, if hosted alongside the site
• Third-party integrations: payment gateways, shipping APIs, marketing tools

Files: what to copy and what to leave behind

Copy the entire wp-content directory, including plugins, themes, uploads and any mu-plugins. It's tempting to skip reinstalling plugins from scratch and just copy the folder directly, and that generally works, but always grab a fresh copy of wp-config.php separately since it needs new database credentials on the destination server rather than a straight copy.

Leave behind cache plugin output, since cached files are specific to the old server's paths and will just get regenerated. Also skip copying .htaccess blindly if the new server uses a different web server technology underneath; check with your new host whether that file needs adjusting.

Database: the step people rush

Export the full database, not a partial one, using a tool like phpMyAdmin or WP-CLI. Once imported on the new server, WordPress's site URL and home URL fields, along with any absolute URLs saved inside post content, widgets or serialized plugin settings, still point at the old domain. This needs a proper search-and-replace tool built for WordPress databases, because a plain text find-and-replace can corrupt serialized data (the kind of stored data where a string's length is recorded as part of the format) and silently break settings.

The details that get missed most often

These are not exotic edge cases. They are the specific items that come up again and again during WordPress migrations, usually discovered by a visitor rather than the site owner.

• Contact form plugin settings that reference an absolute file path for uploads
• SMTP or transactional email plugin settings tied to the old server's credentials
• Scheduled WordPress cron events for things like automatic backups or newsletter sends
• Hardcoded image or file URLs typed directly into post content years ago
• Login security plugins that whitelist the old server's IP address
• Caching or CDN plugin configuration pointing at the old domain

Plugins and themes: reinstall the risky ones

Most plugins move fine as a straight file copy. A few categories are worth reinstalling fresh instead: security plugins, since they sometimes store server-specific firewall rules; caching plugins, since old cached output can conflict with the new environment; and anything that generated license keys tied to a specific domain, since some premium plugins and themes require reactivation after a domain or server change.

Testing before cutover

Get the new site running on a temporary URL or through a local hosts file edit before pointing the real domain at it. Then go through the site as if you were a first-time visitor and, separately, as if you were a returning customer.

• Load the homepage, a blog post, and a page with a form
• Submit the contact form and confirm the notification email arrives
• Log in to wp-admin and check that the dashboard loads without PHP errors
• If it's a store, place a test order through to confirmation
• Check that images and media load correctly, not as broken links
• Review the site on mobile, since some caching issues only show up there

Cutover and the first 48 hours

Lower the domain's DNS time-to-live a day or two ahead so the switch propagates quickly, then update the A record or nameservers once testing is complete. Keep the old hosting account active and untouched for at least several days afterward as a fallback. During the first two days on the new server, check error logs, watch that scheduled backups actually run, and confirm outgoing email is being delivered rather than landing in spam, since a new server has no email sending history yet.

When to have someone else run this list

This checklist is manageable for a straightforward brochure or blog site. It gets considerably longer in practice for a WooCommerce store with dozens of plugins, custom code, or high order volume, where a missed setting has a real cost. That's the situation free migration service on a WordPress optimized hosting plan is meant for: the same checklist, run by someone who does it daily, before the domain ever moves.

Whether it's handled for you or done in-house, the checklist itself doesn't change. Inventory what the site depends on, move files and database together, watch for the specific things that reference the old server by name, and test before the domain switch rather than after.