The audit most teams should run before doing anything else
- List every active WordPress plugin and mark which ones are business-critical.
- Map the page types, custom post types, taxonomies, and URL patterns that drive traffic or revenue.
- Separate content that can be imported from behaviors that must be rebuilt.
- Identify SEO-critical structures: redirects, metadata, canonical behavior, internal links, and archive logic.
Why plugins usually determine the real cost
For many WordPress sites, the plugin list is the hidden operating system of the business. Search behavior, redirects, forms, memberships, analytics glue, editorial workflow, and structured content often live there. That is why migration gets real at the plugin layer first.
If your current stack has a lot of accidental complexity, EmDash may be worth the rebuild. If your current plugin layer is broad but stable and not causing meaningful pain, the migration case is weaker.
Theme and SEO continuity are not secondary tasks
Most teams underestimate theme rebuild and SEO preservation. The hard part is usually not moving post bodies. The hard part is preserving the URL and presentation logic that search traffic and editorial workflows depend on. That is why Themes and Creating Themes are core migration pages, not optional reading.
Infrastructure is part of the same decision
EmDash changes the runtime model as well as the content model. That means hosting is part of migration planning, not a later deployment checkbox. If your likely production target is Cloudflare, read Hosting in parallel with this page.
A practical phased plan
- Phase 1: audit the WordPress stack and cut non-essential behavior aggressively.
- Phase 2: validate that EmDash can express the content model and theme shape you need.
- Phase 3: rebuild the business-critical plugin layer with cleaner boundaries.
- Phase 4: preserve URLs and SEO-critical structure before worrying about cosmetic parity.