A better path to easier WordPress migration: guided wizard + complete-site import

[swissky]

The idea

Migrating from WordPress to EmDash should take minutes, not an afternoon of docs and post-migration surprises. Today the plugin import path silently drops a lot of a real site: taxonomy assignments (especially on CPTs), ACF/custom fields, SEO metadata, menus, comments, site identity, and everything past the first 500 media files. Users discover the gaps only after switching.

We (this:matters) migrated two live sites — a small business site (CPTs + ACF + Yoast) and a ~1.8k-post tech blog (3.5k media files, 300+ comments, Rank Math, custom taxonomies) — and built out both halves of the migration path along the way:

Plugin side (emdash-cms/wp-emdash#8): a guided wizard under Tools → EmDash Migration with preflight checks (permalinks, REST loopback, Authorization header, App Passwords, reachability), a one-paste migration key, a "what will be migrated" overview, a Deploy-to-Cloudflare shortcut, and new/extended endpoints (/comments, /menus, site identity in /options, post_types per taxonomy) plus capability hardening.

Core side (#1830): the import actually brings everything over — taxonomies incl. auto-created CPT taxonomy definitions, ACF/custom fields (with plugin-bookkeeping meta filtered out and stringly-typed values coerced), Yoast/Rank Math SEO fields, menus, comments, site identity, full media library, and internal links rewritten to root-relative URLs so posts stop linking back to the old domain.

Both PRs are open and tested end-to-end (the blog stress test imported 1768 items, 309 comments, 1689 taxonomy assignments with 0 errors). Touches emdash-cms/wp-emdash#1, #2, #3, #5, #7 and relates to #1691.

Open questions we'd like maintainer input on

1. Permalink → redirect map: the plugin already exports per-post permalink; should core generate a redirect map (old WP paths → new EmDash routes) as a follow-up?
2. CPT routes/templates (Imported CPTs need routes created as well wp-emdash#2): taxonomies now migrate, but route/template creation for imported CPTs is an open design question.
3. Anything you'd like split out of feat(import): complete WordPress migrations via the exporter plugin (taxonomies, ACF, SEO, menus, comments, site identity, link rewriting) #1830 into separate PRs for easier review?

[swissky]

Next piece: chunked, resumable import execution — fixes #475.

The current /execute endpoint does everything in a single Worker invocation: taxonomy setup, every content page, menus, all comments, site settings. On a site with 500+ posts that's hundreds of subrequests and D1 queries in one request, which is exactly the "Worker exceeded resource limits" failure in #475 (and it's why an interrupted import can't resume).

Planned approach — client-driven chunking, stateless server:

• /execute gains optional phase + cursor params. The admin wizard drives the import in a loop: one WP content page (~50 posts) per request, then paginated comments, then a small finalize phase (menus + site identity). Each invocation stays far below CPU and subrequest limits on both free and paid plans.
• Cross-chunk state (WP-post-ID → EmDash-ID map for menus/comments, translation groups, comment threading roots) is accumulated by the client and passed back in — no server-side session state, no cleanup, no new tables.
• Resume for free: skipExisting already rebuilds the ID map from existing content on a re-run, so an aborted import just runs again and fast-forwards.
• Media: the admin already drives that step; it will send bounded batches instead of one giant request, with the existing content-hash dedupe making re-runs safe.
• Fully backward-compatible: a request without phase behaves exactly as today.

The admin gets real progress ("312 / 507 posts") instead of an indefinite spinner, and large imports stop dying at the edge. PR to follow, building on #1830's import pipeline.