WordPress Migration Checklist Generator

1. Handling PHP Serialized Database Strings

WordPress stores theme option arrays and widget settings as PHP serialized strings. As documented in WP-CLI Search-Replace Guidance, plain SQL text replaces corrupt string length counts, causing theme settings to reset.

2. DNS TTL & Zero-Downtime Propagation

Lowering DNS TTL to 300 seconds ensures worldwide ISP resolvers pick up new IP addresses within 5 minutes. Find ideal hosts in our WordPress Hosting Recommendation Quiz.

3. Post-Migration SEO & Permalink Audits

Check plugin compatibility prior to cutover using our WordPress Plugin Conflict Checker.

4. Automated Static Edge Migration via Nimbica

Nimbica's static edge integration connects to an existing WordPress install and pre-renders its content into static HTML served from global edge locations. This is a distinct scenario from the host-to-host migration this checklist covers: it doesn't require a database search-replace, a DNS TTL change, or a hosts-file preview, since the underlying WordPress install and its domain don't move — only the delivery layer in front of it changes.

5. How to Use This Checklist

1. Work through the phases in order — Pre-Migration items (backup, TTL) genuinely need to happen before Database & Files items, which need to happen before DNS & SSL.
2. Don't skip the local hosts-file testing step even under time pressure — it's the single step that catches most migration problems before they're visible to real visitors.
3. Keep the original site fully intact and untouched until the new site is verified working end-to-end — a migration you can roll back from is much less stressful than one you can't.
4. After cutover, actively monitor for 24-48 hours (error logs, Search Console coverage reports, actual page loads) rather than assuming success once DNS has propagated.

6. Common Migration Mistakes

• Using a plain SQL text replace on the database. Always use a serialization-aware tool (WP-CLI's `search-replace`, or a script specifically designed for WordPress's serialized data) — see section 1.
• Forgetting to lower DNS TTL in advance. A high TTL set the day of migration means some visitors keep hitting the old server for hours or days after cutover, seeing a stale or broken version of the site.
• Skipping the permalink flush. A fresh WordPress install on new infrastructure often needs Settings → Permalinks re-saved to regenerate correct rewrite rules — otherwise every non-homepage URL can 404.
• Not verifying 301 redirects for any URL structure change. If the migration also changes URL paths, missing redirects turn every inbound backlink and search result into a 404.

7. Who Should Use This Checklist

Developers and agencies migrating a WordPress site between hosts, site owners doing their first self-managed migration who want a structured reference rather than relying on memory, and anyone planning a migration who wants to identify likely failure points (serialized data, DNS propagation, redirects) before they become live incidents.

8. Limitations

This is a general-purpose checklist covering the migration steps that apply to most standard WordPress installs — it doesn't account for site-specific complexity (multisite networks, custom database tables outside WordPress's standard schema, third-party integrations with hardcoded URLs, or e-commerce order data with special handling requirements). Complex or high-traffic sites should treat this as a starting framework and add site-specific steps rather than a complete migration plan on its own. Checklist progress is not saved between visits.