Migrations from EmDash to WordPress for teams who picked Cloudflare‘s EmDash on launch and decided WordPress’s larger ecosystem, deeper plugin catalogue, or specific integration is the right next step.
Platform context: 19 years of WordPress at scale (Postmedia network, Sherwin-Williams brands, M.L. Campbell) · tracked EmDash since Cloudflare launched it, run the sample install on Workers · ranking-preservation as a deliverable, not a hope
Most migrations that go badly aren’t broken on launch; they’re broken in the weeks before launch when assumptions about content fidelity and URL continuity quietly fail. An EmDash-to-WordPress move in 2026 is smaller in scope than a typical CMS-to-CMS migration. EmDash sites are months old, the content models are TypeScript schemas you can introspect, and there’s no vendor lock-in to escape because EmDash is open source. The work is still URL preservation, schema continuity, content fidelity, integration reconnection, and editorial training — but each step is faster than a migration off a legacy proprietary platform.
Who this is for
- Fit. Teams who shipped on Cloudflare’s EmDash since its 2025-2026 launch and need a specific WordPress plugin, a larger ecosystem, or a hiring pool that EmDash doesn’t yet have.
- Fit. Organisations whose AI-agent or governance requirements have shifted, and the WordPress MCP-server tooling now covers the need with the maturity they want.
- Not fit. Teams that picked EmDash six months ago and want to leave because they didn’t read the early-adopter warning. That’s a different conversation about whether the move solves the problem; book a discovery call first to test the premise.
What this solves
- URLs survive the move. Every published URL on the EmDash side maps to a stable URL on the WordPress side — either as itself, or with a 301 redirect that Google honours.
- Schema continuity holds. Article, BreadcrumbList, Organization, Person, FAQ — every schema graph the EmDash site emits is reproduced on WordPress at parity or better.
- Content fidelity holds. Embedded media, custom blocks, TypeScript-typed fields — WordPress renders the same content with the same meaning, even when the underlying primitives differ.
- The editorial team doesn’t lose a week to retraining. The migration is paired with WordPress-specific training, sequenced so the team is fluent the day the cutover lands.
- Search rankings recover inside 60 days. Most well-executed migrations show full traffic recovery within 30 days; structural improvements often produce net gain by day 90.
What’s included
- Pre-migration audit · weeks 1–2. URL inventory across the EmDash install, schema audit, TypeScript-schema to WordPress post-type mapping, custom-plugin inventory, integration inventory (analytics, CRM, search index, marketing automation, MCP-server agent flows).
- Migration plan · week 2. URL map, redirect strategy, content-fidelity rules, schema-to-CPT translation table (with Advanced Custom Fields and Block Bindings where they fit), custom-plugin replacement plan, risk register.
- Migration build · weeks 3–6. Content migration scripts against the EmDash D1 or SQLite export, redirect deployment, schema continuity verification, integration reconnection, WordPress staging environment for QA.
- Pre-launch verification · weeks 6–7. Side-by-side fidelity check on a representative content sample, redirect spot-check, schema validation, performance baseline on staging.
- Cutover + 60-day monitoring · weeks 7–15. Production cutover, Search Console resubmission, ranking and traffic monitoring at 7, 30, and 60 days post-launch.
Process
- Discovery call · joint, 20 min. Confirm migration scope, identify blockers, and name what’s driving the move off EmDash so the WordPress build can answer for it. Deliverable: scope outline.
- Audit · me, 1–2 weeks. Full URL, schema, content-type, custom-plugin, and integration inventory across the EmDash install. Deliverable: audit report + risk register.
- Migration plan · joint, 1 week. Walk findings, agree URL map and redirect strategy, agree which EmDash schemas translate to native WordPress and which need ACF, Block Bindings, or a small custom plugin. Deliverable: migration plan with date stamps.
- Migration build · me, 3–4 weeks. Iterative content moves from the EmDash export, redirect deployment, schema verification on WordPress staging. Deliverable: feature-complete migration on staging.
- Cutover · joint, 1 week. Production move, Search Console resubmission, monitoring activation. Deliverable: live site + 60-day continuity reporting.
Timeline and investment
Typical engagement is 6–12 weeks. Investment ranges from CAD 15,000 to CAD 60,000 depending on content volume, custom-plugin count, and integration complexity. The most common cost drivers are custom EmDash plugins (each one rewritten as a WordPress plugin or replaced with an existing one) and AI-agent workflows that need new homes in WordPress’s MCP-server ecosystem. Sites with under 100 URLs and no custom plugins sit at the lower end; sites with thousands of URLs, several custom plugins, and complex agent workflows sit at the upper end.
Trust cues
- 19 years of WordPress development — the destination platform is one I’ve shipped on at scale for nearly two decades. You’re landing on home territory.
- Migration approach prioritises ranking continuity. Documented track record of 30-day traffic recovery on past migrations into WordPress.
- Risk register is real, not boilerplate — every migration surfaces three to five things the team didn’t know about their own EmDash install.
- Editorial training paired with the migration; the team is fluent the day the cutover lands.
The migration pre-flight checklist
Ten items every team should be able to answer before signing the migration brief. Most teams cannot answer four of them on day one, and that’s the value of the audit phase.
- How many published URLs do you have on the EmDash install? Not “approximately” — the exact count from the sitemap.
- How many of those URLs receive organic traffic in any given month? Pulled from Search Console. The list determines what gets named in the redirect plan and what gets archived.
- How many distinct content schemas are defined in the EmDash codebase? The TypeScript schema files are the source of truth. The count drives the WordPress post-type and ACF / Block Bindings mapping.
- How many custom EmDash plugins is the site running? Each one needs a WordPress equivalent — sometimes an existing plugin off the .org repo, sometimes a small custom plugin built alongside the migration. The most common cost driver.
- Which third-party integrations consume your EmDash data? Marketing automation, analytics, CRM, search index, partner APIs, MCP-server agent flows. Each needs a reconnection plan on the WordPress side.
- Where is your content authored vs where is it published? EmDash and WordPress both allow multiple authoring patterns; choosing the WordPress pattern upfront beats a week of post-launch editorial friction.
- What’s your current schema graph? Article, Organization, Person, FAQ, Product. The destination needs to match or improve.
- What’s your media library size and where does it live? EmDash typically hosts media on Cloudflare R2. The migration may keep R2 as the storage layer with WordPress pointing at it, or move to a managed WordPress host’s CDN.
- What’s the plan if rankings drop in week two? A pre-agreed escalation path beats a panicked Slack message at 2 am.
- Who on your team owns content fidelity decisions? Migration always surfaces edge cases. One named decision-maker keeps the timeline honest.
The pre-flight checklist takes the first week of the audit phase. The teams that arrive with answers in hand save one to two weeks of project time.
Product names referenced on this page — including WordPress and Cloudflare — are trademarks or registered trademarks of their respective owners. Training offered here is independent and is not affiliated with, endorsed by, or sponsored by any of these companies.
Last reviewed May 23, 2026.
