Migration Order Should Sequence Low-Volume High-Complexity Content First

# Migration Order Should Sequence Low-Volume High-Complexity Content First ## Claim When planning a content migration, I should sequence low-volume/high-complexity content types early rather than last, because they're the ones most likely to reveal blocking edge cases and custom-tooling dependencies before the project's timeline has run out to absorb them.  ## Evidence [[3. Resources/Literature Notes/Migrating Enterprise Content to the Block Editor]] reports K. Adam White (Human Made) recommending exactly this ordering for a Sitecore-to-WordPress migration: establish the backbone with broad, simple content first (media, plain text), but tackle low-volume, high-complexity content early rather than deferring it, since it's the content most likely to surface edge cases and block on custom-block development. Sitecore's own two-database content/layout split — the article's [[3. Resources/Literature Notes/Migrating Enterprise Content to the Block Editor#Sitecore splits content and layout into two databases|H1 atom]] — is the concrete instance of exactly the kind of high-complexity condition this sequencing principle anticipates. ## Scope & conditions - Holds for any migration where content complexity varies significantly by type and custom tooling/blocks may need to be built mid-project. - Breaks down if all content types are roughly uniform in complexity, where sequencing order matters less because no type is disproportionately likely to block the rest. - Assumes the project has enough runway left after an early complexity spike to actually build the custom tooling the spike reveals — sequencing complexity early only helps if there's still time to respond to what it finds. ## Links - [[3. Resources/Permanent Notes/Phased Migrations That Ship a Shared Layer First De-Risk the Rest]] — because extends: both are migration-sequencing risk patterns, but that note is about shipping a *shared component* first (a header running on both old and new systems), while this one is about sequencing by *content complexity* — different axes of the same "de-risk the schedule" instinct. - [[3. Resources/Permanent Notes/A Deprecation Needs Adoption Evidence Before It Transfers Migration Cost]] — because applies-in: both are about not deferring the hard part of a multi-phase technical change past the point where deferring it is safe. - [[3. Resources/MOCs/Events/WordCamp Europe 2026 MOC]] — because applies-in: session-index MOC for this WordCamp US 2026 talk. - [[3. Resources/MOCs/WordPress Platform Design MOC]] — applies-in: Joins block-editor migration and platform notes; fit is loose. ## Maintenance - Last tended: 2026-08-19 - Next review: 2026-11-19