The case for staying
If your editors are productive, your page speed is acceptable, and your traffic is growing — you do not need to migrate. WordPress with a tuned host, a clean theme, and a short plugin list is faster and cheaper than most headless setups people end up with.
Most "we need to go headless" conversations we walk into are really "our WordPress is a mess and nobody wants to fix it." The honest fix is usually a few weeks of cleanup: cut the plugins, replace the page builder, move to a managed host, set up a build pipeline. That work is often 20% of the migration cost and recovers most of the performance gap.
A migration that solves a maintenance problem with an architecture change is a migration that produces a more expensive maintenance problem.
The case for moving
You are not migrating away from WordPress. You are migrating toward two things: predictable performance and editorial freedom across surfaces. The same content powering web, mobile, in-app, and a Mini App — without rewriting it three times.
Concretely, the reasons that hold up:
- Performance ceiling. WordPress hits a wall on heavy product pages. A headless front-end on modern infra has no ceiling that matters at marketing-site scale.
- Multi-surface content. Web, mobile, in-app, voice, kiosks. WordPress was designed for one front-end; you are paying a tax to fake the others.
- Developer velocity. Modern React tooling, type safety, deploy-on-push. The team ships in days, not weeks.
- Security surface. A headless front-end has no
wp-login.phpto defend. - Editor experience on new patterns. Components, structured content, references between pieces. None of these are native to the WordPress block editor.
If your business hits two or more of these, the math starts to work. One is rarely enough.
The decision matrix
| Signal | Stay | Migrate |
|---|---|---|
| Editorial workflow is healthy | ✓ | — |
| Page speed is a budget item | — | ✓ |
| Multiple front-ends consume content | — | ✓ |
| Plugin sprawl is creeping back | — | ✓ |
| One marketing site, no roadmap | ✓ | — |
| Editors are blocked by the theme | — | ✓ |
| Traffic is steady, not exploding | ✓ | — |
| You are losing engineers to the CMS | — | ✓ |
Three or more rows on the "Migrate" side is a real signal. One or two is usually a sign that a smaller fix is the right call.
What changes for the editor
This is the part most migration plans underestimate. WordPress editors are spoiled — and they should be. Live preview, drag-and-drop blocks, an admin search that actually works, plugins that solve a problem in an afternoon. A headless setup gives all of that away by default, and you have to deliberately put each piece back.
- WYSIWYG previews are harder. Live preview needs a real engineering pass — typically a draft-mode hook on the front-end that fetches unpublished content with an auth token.
- Image handling moves into a pipeline. No more "upload and forget." The CMS hands off a URL, the front-end transforms it. The editor needs guardrails so they do not break the layout with a 5 MB photo.
- Component awareness. The editor needs to know what each block is for. Schema-aware fields, validation, and reference checks are not optional — they are the migration.
- Workflow controls. Drafts, scheduled publishing, role permissions, audit logs. WordPress had all of these for free. Most headless CMSes have them, but they require configuration.
None of this is a problem if you plan for it. All of it is a problem if you discover it the week before launch.
Choosing the CMS
There is no single right answer. The shortlist we evaluate, in rough order of fit:
- Sanity. Strongest editor experience, best for structured content with lots of references. Real-time collaboration works.
- Contentful. Mature, enterprise-friendly, mature integrations. Pricing escalates with traffic.
- Strapi. Self-hosted, full control, customizable. Best when you have engineering capacity to own the infra.
- Payload. Code-first, TypeScript-native, owns its database. Excellent for teams that want the CMS in their repo.
- WordPress as headless. Keep the admin, use the REST or GraphQL API. Lowest-risk migration if the editors love WordPress.
Pick by your team's editorial workflow, not by feature checklists. Every CMS on this list will technically do the job. Only one of them will feel right to the editors who use it daily.
Migration in three phases
The teams that try to flip everything at once usually flip nothing for six months. The phased approach works:
- Freeze the content model. Lock down post types, taxonomies, custom fields, and references before any front-end code is written. This is the highest-risk phase and the one most teams rush.
- Move read traffic first. Ship the new front-end against the old WordPress admin. Editors keep working in WordPress, the new site reads the data. The customer sees a faster site within weeks.
- Move the editor last. Only after the new front-end is stable in production for a few weeks. Migrate content, train editors, switch off the WordPress admin in a final step.
Each phase has a clear rollback. If phase two breaks, the old WordPress site is still there. If phase three breaks, you can keep the new front-end on WordPress for another quarter while the team adapts.
What gets cheaper, what gets more expensive
A migration is a re-allocation of costs, not a reduction. Honest accounting:
| Gets cheaper | Gets more expensive |
|---|---|
| Page speed engineering | Initial setup and content modeling |
| Security patches and plugin hell | Editor training on new tools |
| Adding a second front-end | Live preview and draft mode |
| Cross-team content reuse | Hosting and CDN configuration |
| Engineering velocity over 6 months | Engineering effort in month 1 |
A team that budgets only for the gains will not finish the migration. A team that budgets for both ships.
When not to migrate, ever
There is a category of WordPress site where migration is the wrong call regardless. The pattern:
- A marketing site with mature editorial workflows.
- A small team where the editors and engineers are the same people.
- A traffic level where WordPress can comfortably serve from cache.
- A business where content is not a competitive surface.
For these, a clean WordPress is the best tool. The investment is in the cache layer, the host, and a disciplined plugin policy — not in a new stack.
What we ship in the first month
When a team commissions a migration with us, the first month looks the same on most engagements:
- Content audit. Every post type, every field, every plugin. What stays, what merges, what disappears.
- Model freeze. A documented content model the editors and engineers both sign off on.
- A working front-end against old WordPress. Production-deployable, behind a feature flag.
- A draft-mode preview that the editors actually use.
- A rollback plan that has been tested.
If month one ends without those five, the migration is not safe to continue. The teams that hit those marks finish in three to four months. The teams that skip them are still going at month nine.
The honest summary
Going headless is not a silver bullet. It is a deliberate trade — operational complexity for performance and flexibility. Make that trade with both eyes open, in the order the project will actually need, and the result is a stack the team can ship from for years. Make it because somebody on the team read a thread on Twitter, and you will be migrating again in eighteen months.
Similar news
