How to migrate WordPress to Astro or Next.js?
Keep WordPress as the content backend and rebuild the public front end as a separate site that reads from it. Astro usually fits content sites and marketing pages; Next.js fits front ends with application logic or signed-in users. I measure first, because a slow WordPress site is often slow for reasons a new framework does not touch, and when fixing caching or images is enough I say so.
Who provides WordPress to Astro & Next.js migration?
I do: Mariusz Szatkowski, a WordPress developer since 2006, based in Gdynia, Poland. I work alone, so the audit, the code, the redirect map and the launch are mine, with no team and no subcontractors. This site, wppoland.com, runs on Astro and Cloudflare Pages.
What does WordPress migration to Astro & Next.js include?
Moving the public layer to Astro or Next.js, rebuilding templates and components, reading content from WordPress over the REST API or WPGraphQL, carrying over forms and integrations, and redirects from the old URLs. The editorial admin, roles and publishing flow stay in WordPress unless I agree otherwise. You supply the visual design and layouts; I implement them. If you want the process in detail before hiring anyone, the website migration guide covers it step by step.
Where do I deliver WordPress migration projects?
Remotely, for companies in the UK, Ireland and the rest of Europe. I work by email, written documents and the repository, so every decision is on record. Contracts are B2B under Polish law; invoices carry my EU VAT ID PL7393037445 under the reverse-charge rule.
When a migration makes sense
The bottleneck is rarely WordPress itself; it is usually one layer. Queries a plugin runs on every request, caching that skips logged-in users, images served at their original size, or a theme loading a dozen CSS and JS files. Each is measurable on its own, and several can be fixed without replacing the front end.
A front-end migration pays off when the problem sits in the theme and the rendering, when you want templates in version control and publishing through a build, or when the same content has to feed other channels over an API. It rarely pays off when the site depends on plugins that generate the front end (page builders, WooCommerce with many extensions), because every one of those features has to be rewritten.
Separation also changes the attack surface. Public traffic no longer reaches PHP, but the WordPress installation, plugins, accounts and API still need updates, access control, backups and monitoring. A headless setup does not protect a compromised backend or an insecure integration.
Astro or Next.js? Which to choose?
Both frameworks can generate static pages and render on a server. They start from different assumptions.
| Astro | Next.js | |
|---|---|---|
| Model | multi-page site, src/pages/index.astro is the home page | React application with the App Router (app/) |
| Browser JavaScript | none by default; a component becomes an interactive island only with client:load, client:idle or client:visible | Client Components marked with 'use client' |
| Rendering | output: 'static' by default; a single page renders on demand with export const prerender = false and an adapter | prerendering, dynamic rendering, ISR via export const revalidate |
| Refreshing CMS content | a new build, or pages rendered on demand | revalidatePath, revalidateTag, draft previews through draftMode() |
| Typical hosting | adapters @astrojs/cloudflare, @astrojs/netlify, @astrojs/node, @astrojs/vercel; a static build on any web server | Node.js server, Docker container, or static export (output: 'export') without ISR or Proxy |
| Fits | company sites, blogs, documentation | customer portals, apps with login, data that changes per request |
Astro is not a React framework. React components work in it through the @astrojs/react integration and reach the page as HTML or as islands with a client:* directive. Server islands are the other half: an Astro component with server:defer renders separately, so the rest of the page does not wait for it.
What you get after a headless WordPress migration
- A baseline audit. Representative URLs with LCP, INP, CLS and TTFB measured before any change, and the responsible layer named.
- A front end in version control. Astro or Next.js templates and components in Git, publishing through a build, and a preview before anything goes out.
- Editing stays in WordPress. Same accounts, roles and publishing flow. Content comes from
/wp-json/wp/v2/or WPGraphQL. - Forms, integrations and redirects. Moved across and documented, with the list of URLs to verify after launch.
- A before-and-after report. The same URLs, the same test conditions, both measurement dates, and your field data if you have any.
Consent and analytics on the new front end
The theme takes the plugins that injected your cookie banner and tracking scripts with it, so the new front end has to wire them again. For Irish sites, Regulation 5(3) of S.I. No. 336 of 2011 (the ePrivacy Regulations) requires consent, with clear and comprehensive information, before anything is stored on or read from a visitor’s device. In the UK the equivalent rule is regulation 6 of PECR 2003, substituted in February 2026 by the Data (Use and Access) Act 2025; check its current exemptions in Schedule A1 rather than relying on older guidance. I set up the consent tool and analytics so nothing optional loads before consent, and I check the network tab of the new site to confirm it.
How the migration runs
- Audit and quote. I measure the site, list content types, ACF fields, forms and CRM or analytics integrations, and check which plugins output anything on the front end. Framework choice, scope, assumptions and timeline go into a written quote before any code exists. If I get access to personal data, I sign an Article 28 GDPR processing agreement first.
- WordPress as an API. I tidy the backend, restrict access to the admin and check what the REST API returns. WPGraphQL goes in only when the content structure needs it.
- The new front end. Templates built from your design in a private Git repository, with a preview version where you sign off. Every change comes with a written description.
- Redirects and metadata. WordPress stores the slug it generated, so I read the
slugfield from the API instead of recomputing it. Only URLs we change on purpose (date archives, attachment pages,?p=parameters) go into the 301 map. Titles, descriptions, structured data, canonicals and hreflang move with the content, and I compare a crawl of the old and new versions. - Launch. The old site keeps serving until the DNS record changes. If something is wrong afterwards, switching back means pointing the domain at the old version again. From then on WordPress is not public and serves editors only.
Already on Next.js and moving to Astro?
The official Astro guide for migrating from Next.js lists the conversions:
pages/becomessrc/pages/, and routing stays file-based;app/layout.jsxandhead.jsxmerge into oneLayout.astro, with<slot />in place of{children};getStaticProps()goes away; data is loaded in the component frontmatter withfetch(),import.meta.glob()orgetCollection();- Next’s
<Image />becomes<Image />fromastro:assets, while.jsxfiles keep a plain<img>that Astro does not optimise; <Link>becomes<a href="">, andclassNamebecomesclass.
React components can stay through @astrojs/react. The guide also notes that Astro is content-driven, so interactive dashboards take more work than in Next.js.
Common migration scenarios
Content sites. Blog posts, articles and information pages change rarely and are read often, which suits static generation in Astro. What remains to settle is what triggers a build after publishing.
WooCommerce stores. Catalogue, basket, checkout and customer accounts all have to be rebuilt on the front end in a headless setup. For stores with many extensions I usually recommend staying on a classic theme and fixing its performance instead.
Applications with login. Customer areas and per-user data are Next.js territory: prerender the public pages and render the signed-in sections on the server.
For a public example, read the WPPoland rebuild case study. It covers the Astro content architecture, the six-locale workflow and the technical SEO controls behind this site.
How to start a headless WordPress migration
Send a written brief through the contact form: current stack, target framework, URL constraints, integrations, languages and the business risk you want to reduce. I reply by email with the next steps and a quote that states its assumptions.
Which services relate to an Astro and Next.js migration?
New Next.js work that does not start from a WordPress site is covered by the Next.js developer service. For hiring intent around Poland, see Hire Next.js developers in Poland. The WordPress to Astro migration report describes how this site moved.
