Resource Migration checklist
A migration checklist built from three production headless WordPress sites we run for ourselves, plus the headless migrations we have shipped for clients. Currently shared on request, downloadable version in progress.
Headless WordPress migrations fail in predictable places. SEO redirects. Gutenberg block rendering. Editor experience. Performance budget. The checklist below covers all of them, in the order you need to address them, based on what we have shipped to ourselves and to customers.
What is inside
Each phase has a defined deliverable and a defined timebox. The full checklist runs from architecture decision to post-launch monitoring.
01
WPGraphQL or REST? ISR or full rebuild on every change? Where do auth, commerce, and forms stay? Cloudflare Workers, Vercel, or Netlify deploy target. Document each decision with the reasoning. The architecture call shapes everything downstream.
No re-architecting six weeks in.
02
Inventory every URL, every custom post type, every ACF field, every Gutenberg block in use, every shortcode. Map which ones move to the headless frontend and which stay in WP. Surface the orphans and the legacy content that should be archived.
No content surprises mid-build.
03
Every existing URL gets a destination URL on the new architecture. 301 redirects documented, exported as a CSV, ready to load into Cloudflare or your edge router. Sitemap, robots, canonical strategy locked before the cutover.
Zero ranking loss across the cutover window.
04
For Gutenberg block content, decide which blocks render natively, which need custom Astro or Next.js components, which can be deprecated. Document the per-block strategy. Editor visual fidelity preserved on the frontend.
Editors do not see "looks wrong on the frontend" tickets.
05
LCP target, TTFB target, CLS target, JS bundle target, image format strategy. Performance is a deliberate budget, not a hope. The headless architecture only delivers if you spend the budget on what matters.
Performance gains hold past launch week.
06
Soft launch on a staging domain. Smoke test every redirect. Switch DNS or edge routing in a low-traffic window. Monitor Search Console and Core Web Vitals for the first 30 days. Have a rollback plan documented and rehearsed.
Cutover is a non-event for visitors.
The downloadable version is in progress. The current internal version is shared on request and goes out within four business hours. The checklist is the same one we use on customer migrations.
Engineering judgment on architecture decisions. SEO instinct on redirect strategy. Performance optimization on the new frontend. The checklist covers what to do. The "how to do it well" is engineering work.
Every headless WordPress migration we ship goes through this checklist. Architecture decisions documented in the discovery phase. Content audit and redirect map run in parallel during the build. Block parser strategy decided after the architecture call. Performance budget locked before first commit. Cutover scripted and rehearsed before launch.
Common questions
The downloadable version is in progress. The current internal version is shared on request and goes out within four business hours.
Yes for the architectural and SEO items. Some content audit items may not apply if your site is small. The block parser strategy only matters if you use Gutenberg. The performance budget always matters.
A capable WordPress and frontend team can. Most teams find the SEO redirect map and the block parser strategy harder than expected. Those are the two areas where teams ask us for help even when running the migration themselves.
Six to ten weeks for a content-heavy WordPress site. Two to four weeks for a marketing-only site. The checklist applies to both, the depth per item varies.
Planning a headless WordPress migration?
The checklist is yours on request. The full migration service is a fixed-price engagement after a two-week discovery.
