MigrateToAstro

WordPress to Astro

Migrate from WordPress to Astro

WordPress runs a third 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.

A migration like this usually takes 3–6 weeks

Why people move

What changes when you move from WordPress to Astro.

What is being compared WordPress Astro
Where the features come from WordPress Plugins, including ones chosen years ago by somebody who left Astro Written once, or a service the site talks to on purpose This is the row that decides most WordPress migrations. A site with four plugins is a short job. A site with forty is an audit before it is a rebuild, because each one is a decision somebody has to make again.
Themes and the design layer WordPress A theme, a child theme, and often a page builder on top of both Astro Components, with no theme underneath them Three layers of inheritance become one layer of markup. It is the part of a WordPress migration that looks like a redesign and is not one.
What you patch WordPress Core, plugins, PHP, and the server they run on Astro Dependencies, on your own schedule, with nothing public to exploit A static build has no admin login, no database and no runtime to reach. That is a genuine reduction in what can go wrong, and it is also the thing people most often oversell.
Publishing at volume WordPress Multiple authors, scheduling, revisions and editorial states, built in Astro Whatever the CMS you choose provides, and nothing by default WordPress is very good at this. If a newsroom runs on it, that is a reason to stay, or to keep WordPress headless and let Astro render the front end.
Extending it WordPress Anything, if somebody writes PHP Astro Anything, if somebody writes JavaScript, and it runs at build rather than per request

A site that mostly publishes gains from this move. A site that mostly transacts, or that runs on a plugin nobody wants to reimplement, usually does not.

Once you have decided

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.

Before you budget it

Where this migration gets complicated.

  1. 01

    The URL archive is larger than the 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 it runs

How the migration works.

  1. 01

    Plan

    Every post type, every plugin and every live address written down while the site is still serving them. The plugin list is the scope: each one is kept, replaced or dropped, in writing, before anything is built.

  2. 02

    Build

    Templates become components and the theme's inheritance is flattened into markup somebody can read. The content model is designed here, because the custom fields have nowhere to land until it exists.

  3. 03

    Migrate

    Posts, pages, media and metadata moved and verified by count, with page builder markup extracted rather than carried. Permalinks and archives mapped, including the ones nothing links to.

  4. 04

    Launch

    Redirects tested against the full address list rather than a sample, forms arriving, analytics firing, then the cutover. Typically 3–6 weeks, then a fortnight watching what the old addresses return.

What you are buying

What is included.

  • 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 parity

    Every public address the same on both sides.

  • 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.

Reach out and see if we are a good fit.

Start a project

Currently booking two to four weeks out.