Anonymised case study

Confidential WordPress to headless migration plan

The client cannot be named. The useful proof is the planning logic: what gets audited before code, which risks are isolated, and how a migration avoids becoming a rewrite with SEO damage.

Starting constraint

The existing WordPress site had editorial value, indexed URLs, historical content, and multiple integrations. The risk was not whether Astro or Next.js could render pages. The risk was losing the editorial workflow, structured data, redirects, and stakeholder trust during cutover.

The migration plan therefore treated WordPress as a content system first and a rendering system second.

Diagnosis

The audit started with content types, taxonomies, URL patterns, canonical rules, hreflang, schema blocks, preview needs, search templates, and integration dependencies.

Only after that did the front-end choice make sense: Astro for mostly content-led surfaces, Next.js when authenticated or personalised flows mattered.

Architecture decision

WordPress stayed the editorial source of truth. The public front moved to a composable layer with edge delivery, strict URL mapping, and a redirect file tested before launch.

The plan deliberately avoided a big-bang rewrite. It grouped routes by risk: static content first, dynamic surfaces later, checkout or account flows only after separate validation.

Risk handling

The migration checklist covered 301 maps, canonical tags, sitemap parity, structured data parity, image dimensions, editorial preview, cache invalidation, and monitoring after DNS or proxy cutover.

Rollback was part of the plan, not a panic option. The old WordPress front remained available until the new front proved parity on the critical templates.

Frequently asked questions

Why not start with the framework decision?

Because the framework is rarely the riskiest part. URLs, schema, preview, integrations, and editor workflow usually decide whether a migration succeeds.

When is Astro the right front end?

Astro is the better default for high-traffic content sites, documentation, marketing pages, and editorial surfaces where minimal JavaScript improves Core Web Vitals.

When is Next.js the better choice?

Next.js is stronger when the site needs authenticated flows, personalised views, session-aware rendering, or application-like product interfaces.

What makes the case study NDA-safe?

It removes identity, screenshots, private URLs, traffic, and commercial metrics. The architecture and decision method remain visible.

Need a migration plan before a rebuild?

Send the current URL structure, content model, and the pages you cannot afford to lose. I will map the migration risk before recommending Astro, Next.js, or staying monolithic.

Request a migration diagnosis