Most WordPress migrations are defined by what you carry over. This one was defined by what they left behind.<\/p>\n
A university communications department had run their site on WordPress for 12 years. They had 4,000+ posts, 200+ pages, and 30+ plugins. The usual story: a contact form plugin, an SEO tool, a caching layer, a page builder, and a dozen single-purpose extensions that had accumulated like barnacles.<\/p>\n
They migrated to EmDash CMS<\/a> in 3 days<\/a>.<\/p>\n Not weeks. Not months. Three days.<\/p>\n Here is what they did that most teams get wrong.<\/p>\n The standard WordPress migration playbook is a WXR export. Download an XML file, import it somewhere else, pray the field mappings line up.<\/p>\n That approach breaks on EmDash.<\/p>\n EmDash stores content as portable text \u2014 structured JSON, not HTML. WordPress stores content as HTML blobs inside The university team skipped the WXR export entirely.<\/p>\n They used the EmDash WordPress import plugin, but they did not run it blind. First, they mapped every custom field to a content type schema. Then they transformed the data. The import plugin handled the mechanical part. The schema design was the real work.<\/p>\n WordPress ships with two content types: posts and pages. Everything else requires custom post types, usually managed through a plugin like ACF or JetEngine.<\/p>\n EmDash treats content types as a first-class primitive. You define them in the admin interface or through code. The university team created 7 content types: News Article, Event, Profile, Department Page, Research Output, Publication, and FAQ.<\/p>\n Each type had its own field set. No ACF. No CPT plugin. No meta table joins.<\/p>\n The team’s lead developer said the schema design took 6 hours. The actual data migration took 4 hours after that. Most teams reverse this ratio \u2014 they spend days trying to fix a bad import instead of hours designing a clean schema.<\/p>\n Gutenberg blocks are HTML with comments. Portable text is structured JSON with block-level metadata.<\/p>\n The university team had 1,200+ posts built with the Classic Editor and another 800 built with Gutenberg. They did not try to preserve the exact block structure. Instead, they extracted the semantic content \u2014 headings, paragraphs, images, embeds \u2014 and mapped them to EmDash’s block editor.<\/p>\n They lost some layout fidelity. A few multi-column layouts needed manual adjustment. But they gained something more valuable: clean, machine-readable content that an AI agent<\/a> or API could consume without parsing HTML.<\/p>\n The university ran 30+ plugins. Most fell into three categories:<\/p>\n EmDash ships with SEO, caching, redirects, and form handling built in. That eliminated 8 plugins immediately.<\/p>\n The remaining plugins needed porting. This is where dynamic workers changed the timeline.<\/p>\n EmDash runs every plugin in its own V8 isolate. The plugin cannot touch the database, the file system, or any other plugin unless the capability manifest explicitly grants it.<\/p>\nThe Export Trap<\/h2>\n
wp_posts<\/code>codecodecodecode. A direct 1:1 dump produces a mess. Gutenberg block HTML, shortcodes, and inline styles all get serialized as raw text.<\/p>\nContent Types Are the Bottleneck<\/h2>\n
Portable Text vs. Gutenberg Blocks<\/h3>\n
Why Plugin Sandboxing Accelerated the Migration<\/h2>\n
\n
Dynamic Workers for Plugin Porting<\/h3>\n