NewBase
Get in touch

WordPress to Astro

Migrate from WordPress to Astro

WordPress runs an enormous share of the web and most of those sites should stay on it. Astro makes sense when the site is mostly published rather than transacted, when the plugin list has become the real architecture, and when somebody is already spending their week on updates that have nothing to do with the content.

Start a project

A migration like this usually takes 3–6 weeks

What actually migrates.

What you have What happens Why
Posts and pages Move Comes across as it is. The content survives the move and the work is transporting it, not remaking it. Exported from the database rather than scraped, converted to Markdown or loaded into whichever CMS the new site reads, and checked by count against the old admin.
Custom post types and fields Rebuild Made again in Astro. The old version is a reference rather than something that can be imported. A post type is a shape somebody defined in PHP or in a plugin's UI. There is nothing waiting to receive it, so the model gets designed before the content can move.
Media library Move Comes across as it is. The content survives the move and the work is transporting it, not remaking it. Files come across and every reference to them gets re-pointed, including the ones living inside post bodies rather than in a field.
Plugin behavior Rebuild Made again in Astro. The old version is a reference rather than something that can be imported. Forms, redirects, SEO fields, galleries and popups were each a plugin. Each one becomes a deliberate decision: rebuild it, replace it with a service, or drop it because nobody has used it since 2022.
URLs Reconfigure The same thing, set up again. Nothing is recreated, but it has to be pointed at the new site by hand. Permalinks stay. So do the archives, the pagination and whatever structure preceded the current one, which is usually larger than the site itself.

Nothing here is a file move.

WordPress exports the output of its system, not the system. Dropping that into Astro gives you the same pages with none of the structure that made them maintainable, and a CMS that no longer exists. Every line below is a decision somebody has to take rather than a file that gets moved. This list is the work.

  • An SEO plugin Metadata in the content model Titles, descriptions and canonicals become fields on the entry rather than rows in a table a plugin owns, which is also how they survive the plugin being uninstalled.
  • A form plugin A form endpoint A service that receives submissions, or a function of your own. Either way the test is a record arriving at the destination, not a success message in a browser.
  • A caching plugin, a CDN and an optimizer Nothing All three existed to undo the cost of rendering per request. A page built before anybody asks has nothing for them to undo.
  • A custom post type A typed collection The shape somebody defined in PHP becomes a schema the build checks, so a missing field fails the build instead of rendering an empty page for a month.
  • A feature nobody has used since 2022 Retired The plugin audit is the migration. Every entry on the list is kept, replaced or dropped, in writing, before anything is built.

Where this migration gets complicated.

  1. 01

    The URL footprint is usually larger than the visible site

    Category archives, tag archives, author pages, date archives, pagination and whatever permalink structure preceded the current one are all live addresses that nothing in the navigation points at. On one migration that came to 773 redirects against a site nobody would have called large.

  2. 02

    Page builder output is not content

    Elementor, Divi and WPBakery store layout inside the post body as shortcodes and serialized markup. The export contains it, so the text has to be extracted from the layout rather than imported with it, and that is manual on every page a builder touched.

How the migration works.

  1. Audit

    Every post type, plugin and live address, written down while the old site is still serving them.

  2. Rebuild

    Templates become components, the theme's inheritance is flattened, and the custom fields get a typed model.

  3. Migrate

    Posts, pages, media and metadata moved and verified by count, with permalinks and archives mapped.

  4. Hand over

    The repository, the migration map and documentation written for somebody who was not here.

What is included.

Every migration includes the front-end rebuild, the content and asset move, the integration work, URL coverage, QA and post-launch monitoring. What changes with the platform is how hard each one is, which is what the rest of the page is for.

  • Design rebuild

    Rebuilt as components, not approximated.

  • Responsive development

    Desktop, tablet and mobile, built and checked.

  • CMS architecture

    Collections and fields mapped before build.

  • Content migration

    Migrated and checked against the source.

  • Asset migration

    Collected, compressed and rehosted.

  • Forms and integrations

    Tested through to the final record.

  • URL coverage

    Every known public address preserved or deliberately redirected.

  • Metadata and canonicals

    Preserved wherever possible.

  • Search footprint preservation

    URLs inventoried before and checked after.

  • Pre-launch QA

    Forms, templates and old URLs verified.

  • Post-launch support

    One week of indexing and traffic checks included.

Search visibility can move during a migration. The goal is to preserve what search engines already understand, and to catch what changed quickly after launch.

And it is yours at the end. The repository sits in your organization rather than mine, the handoff documentation is written for somebody who was not here, and nothing about the project requires me: another developer or your own team can operate it.

Leaving WordPress does not have to mean handing every edit to a developer.

This is the real question behind the CMS decision, and the answer is that it depends on what you choose rather than on Astro. A headless CMS such as Sanity gives editors an interface, a preview and a publish button, and keeps the front end in code. Content collections put the content in the repository, which is cheaper and only suits a team happy in a pull request. Choosing wrong is the mistake people feel a year later, so it gets decided before the rebuild rather than after it.

  1. 01

    Content Collections, in the repository

    For a team that publishes rarely and is happy in a pull request. The content is files beside the code, typed and checked at build time, with no service to pay for and nothing to keep running. It stops suiting you the day somebody outside engineering needs to publish without help.

  2. 02

    A headless CMS, such as Sanity

    For a team that publishes regularly, or where the person writing is not the person deploying. Editors get a real interface, the model is explicit, and the site reads it at build time. It is another system to configure and pay for, and the modeling is the part that decides whether editors can work on their own.

  3. 03

    No CMS at all

    For a site whose pages change a few times a year. Everything lives in components, changes go through the same review as any other change, and there is no editorial layer to maintain. Honest for a small site, and the wrong answer the moment a blog is added.

Content Collections against a headless CMS, and how the choice is made.

A migration is not finished when the new site looks right.

These are acceptance criteria rather than features. The codebase, the site inventory and the connected systems are each checked against what you started with, and the answer is a count rather than an opinion.

  • 01 Codebase

    A codebase your team owns

    Components, routes and styles rebuilt deliberately, not cleaned up from exported markup.

    Verified by Repository and component structure

  • 02 Site

    Everything accounted for

    Collections, content, metadata and existing addresses checked against the source.

    Verified by Source inventory and migration checks

  • 03 Systems

    Handoffs that actually arrive

    Forms, analytics and CRM checked at their destination rather than at the button.

    Verified by Submissions, events and records

The migration is complete when these pass, not when the homepage looks right.

The figures above are an illustration of the report's shape. Yours are counted from your own site.

See everything included in a migration

Built for people and agents to work on.

Moving to code changes how the site can be maintained. Marketing works through the CMS. Developers work against components and routes. A coding agent works against the same repository, the same documentation and the same review as a developer.

The important part is not that an agent can write code. It is that the project is structured well enough for its changes to be understood, reviewed and reversed.

  • Marketing

    Editor or AI assistant CMS Preview Publish

    On the headless CMS answer above. Choose content collections instead and this lane runs through the repository and the review with the developers, which is exactly why that decision comes before the rebuild rather than after it.

  • Developers

    Branch Components and routes Review Deploy

    The same workflow as any other repository, which is what makes a second developer able to pick it up.

  • Coding agents

    Project instructions Branch Review Deploy

    Against the real repository, under the same review a person gets. An agent is only as safe as the documentation and the tests it is working against, which is why those are deliverables rather than extras.

Integrations

Changing the frontend doesn't mean changing your stack.

The site is one part of a marketing stack, and a migration that leaves the rest of it broken has not finished. Each of these is a deliberate integration with a guide behind it, rather than a script pasted into a header somewhere.

All 24 integration guides

Coming from somewhere else?

Or weigh WordPress against Astro before deciding

Reach out and see if we are a good fit.

Get in touch

Currently booking two to four weeks out.