# Migrating Enterprise Content to the Block Editor — K. Adam White > [!question] Lingering Questions > - What specific criteria determine when a migration should use PHP-only autoregistered blocks versus partially-synced patterns versus block bindings for a given field? > - Will WordPress core extend in-editor preview support to more block-binding source types, closing the editor-vs-front-end gap White flags? > - What would it take to formalize the "Rehydrator" library as a public open-source project? > - At what content volume or complexity threshold does the naive "Convert to Blocks" approach stop being viable? > [!tip] Article Ideas > - "Your CMS migration's real bottleneck isn't the data, it's the block markup" — a piece walking agencies through the PHP-only-blocks / partially-synced-patterns / block-bindings decision tree White sketches live but doesn't formalize. #articleseed > - A comparison-table treatment of the three PHP-side block-generation techniques (editability × complexity ceiling × PHP-generation difficulty) — White himself flags this as a gap in how the talk was delivered. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Migration Order Should Sequence Low-Volume High-Complexity Content First]] — new Permanent note from this article's sequencing claim. #xref > - [[3. Resources/Permanent Notes/A Rehydrator Swaps Content Into an In-Memory Pattern Copy]] — new Permanent note from this article's headline technique. #xref > - [[3. Resources/Permanent Notes/Phased Migrations That Ship a Shared Layer First De-Risk the Rest]] — related migration-risk pattern from a different source (theme migration, not CMS migration); worth holding alongside this one. #xref > - [[3. Resources/Permanent Notes/An AI Migration Agent Leaves Broken Features as Markup That Looks Fine]] — adjacent AI-migration risk from a different platform (WordPress→Astro); this article's rehydrator is a proposed mitigation for a related class of problem (AI-generated markup needing verification). #xref > - [[3. Resources/MOCs/Events/WordCamp Europe 2026 MOC]] — session-index MOC already tracking WordCamp US 2026 references; this talk belongs in its migration/block-editor coverage. #xref > [!quote] Vocabulary > - **Rehydrator** — Human Made's early-stage technique/library: read an existing theme pattern into memory, then swap specific block content/attributes with migrated field values, leaving the theme's own markup ownership intact. > - **Block Bindings** — WordPress API letting a block's content be sourced from post meta or another external source rather than stored literally in `post_content`. > - **Partially-synced pattern** — a synced pattern with per-block `enable overrides` toggled on, turning per-use customization into a small JSON overrides object. ## Bib capsule K. Adam White (Human Made), "Migrating Enterprise Content to the Block Editor: Lessons From a Sitecore-to-WordPress Migration," WordCamp US 2026 (YouTube). A practitioner case-study talk on migrating a large nonprofit off Sitecore into WordPress's block editor, covering planning, AI-assisted content inventory, and PHP-side block-markup generation. ## Author's thesis **Q1 (what's the talk about):** How an enterprise agency plans and executes a migration from a structurally alien CMS (Sitecore) into WordPress's block editor, with the technical core being how to generate valid, well-styled block markup from PHP when block save logic is normally JavaScript-owned. **Q2 (how does it develop that):** White walks through three parts in sequence — planning (content inventory via AI-assisted SQLite querying of exported CSV/JSON, an intermediary JSON schema, a shared team wiki), generating block markup from PHP (three named techniques with tradeoffs: PHP-only autoregistered blocks, partially-synced patterns, block bindings), and Human Made's current preferred approach, a "rehydrator" that reads an existing theme pattern into memory and substitutes migrated content into it field-by-field, applied bottom-up from leaf-node patterns to composed group patterns. ## Key arguments - There is no single "correct" way in WordPress core today to convert non-block content into well-styled, curated block markup at scale — the naive "Convert to Blocks" approach strips styling and doesn't hold past a handful of pages. - AI-assisted workflows (SQLite over CSV exports, agent-queried content inventory, a living Markdown wiki) have compressed the traditionally slow discovery phase of enterprise migrations dramatically in roughly the past year. - Migration sequencing should tackle low-volume, high-complexity content early rather than last, because it surfaces custom-tooling dependencies soonest. ## Claim atoms ### Sitecore splits content and layout into two databases > [!quote] ID:rw_A8IRT9R3Po4_1 > there's a one database that has rows for basically everything we'd imagine to be post meta or posts... Then there's another database that has all of the layout layer. **Where/why**: Mid-talk, during the "planning the migration" section on source-schema difficulty. This is the concrete structural reason White ranks Sitecore migrations as the hardest tier, and it explains why naive field-mapping fails against Sitecore specifically. **Tags**: #xref ### Loading CSV/JSON exports into SQLite speeds AI-assisted mapping > [!quote] ID:rw_A8IRT9R3Po4_2 > we've taken all of the different rows of content and thrown them into a database that we can query in SQLite more efficiently than we can open up a CSV and look through it **Where/why**: During the "AI-assisted content inventory" section, describing Human Made's concrete export-handling workflow. A specific, reusable technique other agencies could adopt directly, not just a general "use AI" claim. **Tags**: #xref ### JS normally owns block save markup, not PHP > [!quote] ID:rw_A8IRT9R3Po4_3 > if we're going to write that save method for a static block, that's done on the JS side. There's nothing inherently in most cases that exposes that to PHP. **Where/why**: During the "block markup" section framing the talk's central technical problem — the root constraint that motivates every technique discussed afterward (PHP-only blocks, partially-synced patterns, block bindings, rehydrator). **Tags**: #xref ### Rehydrator swaps migrated data into an in-memory pattern copy > [!quote] ID:rw_A8IRT9R3Po4_4 > Read in this pattern. Leave all of the ownership of this markup and the theme, but bring the pattern content into memory, and then let me go in and say within this pattern, find the first header block. **Where/why**: During the "rehydrator" section, White's core description of the technique's mechanism — the talk's headline technique and the clearest concrete solution offered for the PHP-vs-JS block-ownership problem. **Tags**: #xref ## Permanent candidates - **Migration order should prioritize low-volume, high-complexity content first** — promoted to [[3. Resources/Permanent Notes/Migration Order Should Sequence Low-Volume High-Complexity Content First]]. General enough to apply past this one migration (risk-first sequencing in any multi-phase project with unevenly distributed unknowns). - **The rehydrator technique itself (reading a pattern into memory, then swapping content field-by-field)** — promoted to [[3. Resources/Permanent Notes/A Rehydrator Swaps Content Into an In-Memory Pattern Copy]]. Distinct from the sequencing claim: this one is a mechanism-level answer to the PHP-vs-JS block-ownership problem, generalizable past WordPress to any "preserve validated structure, swap the data" migration pattern. - Checked existing Permanents first: no direct duplicate found for either claim (searched for "rehydrat", "migration sequenc", "low-volume high-complexity" — no hits). ## Processing checklist - [x] All claim atoms have header + verbatim quote + where/why - [x] Triage callouts populated for every tagged highlight - [x] Checked existing Permanents first — no duplicates found; two genuinely distinct claims promoted - [x] Connected into MOC — [[3. Resources/MOCs/Events/WordCamp Europe 2026 MOC]] (already tracks WordCamp US 2026 references) ## Links - [[3. Resources/MOCs/Events/WordCamp Europe 2026 MOC]] — session-index MOC covering both WCEU and WCUS 2026 talks; this belongs in its block-editor/migration coverage - [[3. Resources/Permanent Notes/Migration Order Should Sequence Low-Volume High-Complexity Content First]] — because evidence-for; new Permanent note from this article - [[3. Resources/Permanent Notes/A Rehydrator Swaps Content Into an In-Memory Pattern Copy]] — because evidence-for; new Permanent note from this article - [[3. Resources/Readwise/Articles/Migrating Enterprise Content to the Block Editor Lessons From a Sitecore-to-WordPress Migration]] — source document - [[3. Resources/MOCs/Events/WordCamp US 2026 MOC]] — applies-in: the MOC lists this note under 🏢 Agency & Business Workflows.