Is it worth moving your Gatsby site to Astro?

If you have a Gatsby site, it probably still works. It builds, it deploys, the content updates and nothing is on fire, which is most of the reason so many Gatsby sites are still running in 2026. We had two of our own until August this year, one of them being this website.

Gatsby has not had a meaningful release in a long time and the plugin ecosystem that grew around it has gone quiet with it. That sounds like an emergency and it is not one. What it means in practice is that the cost turns up somewhere much less visible than an outage.

The cost is in the change loop

On our Gatsby site, adding a single field to a page meant editing the CMS schema, then deploying Sanity's GraphQL API so that the schema Gatsby reads was up to date, then editing the GraphQL fragment the page query pulled the field through, then editing the component, and then restarting the dev server before you could see whether any of it had worked. Reloads were twenty to thirty seconds each.

On Astro the dev server is up in five to ten seconds, and a new field on a content module reaches the component without any query change at all. You edit the schema and you edit the component, and the three steps in between are gone.

That difference never appears on an invoice, which is exactly why it goes unnoticed for years.

What it looks like from your side is small changes being quoted higher than they feel like they should be, and, eventually, a site that has drifted away from what you would ask for if asking were cheap.

What we got out of moving our own site

The site now scores above 95 on mobile PageSpeed, with accessibility, best practices and SEO all at 100.

The three biggest changes all came out of the port itself:

• 790KB down to 355KB on the homepage, and 17.1MB down to 7.6MB across the whole site. Every page had been inlining our entire content set into the HTML for the client-side stores to read, including on the pages that render none of it.
• 13 declared typefaces down to 9. Four of them were there because of a single styling choice each, one of those being the active item in the mobile menu.
• Canonical URLs, structured data, the sitemap and the redirects, all rewritten. They had to be, and they came out better than they went in.

How much of that was Astro

Less of it than you might expect, and we would rather say so. Astro shipping no JavaScript by default is real and it does help, but the decision to inline the content set was taken years earlier and then carried across untouched ever since.

None of that strictly needed a new framework. What it needed was somebody looking at every part of the site at once, which is not something anyone schedules on its own.

A rebuild is the one occasion where everything on a site gets looked at, and that is where a good part of the gain actually comes from.

What the work actually consists of

The framework part is the straightforward part. If your components are already React with CSS modules, most of them come across as they are, which was true for us and has held on the projects we have ported since.

The real work is the data layer. Every query that fed those components has to be rewritten, and, more to the point, every one of them has to be checked, because getting a query subtly wrong produces no error at all.

The page still renders, still returns a 200 and still passes every automated check, and the only symptom is something quietly missing from it. More of our time went on proving that had not happened anywhere than went on Astro.

So when we price one of these, the number is driven mostly by how many content types and page modules the site has, and hardly at all by how many pages. A 200-page site built out of a dozen modules is a smaller job than a 20-page site with forty bespoke ones.

The other thing that moves the price is how much of the site's behaviour lives in Gatsby plugins rather than in your own code. Content sourcing and image handling have direct equivalents in Astro, and the further you get from those the more of the port is rebuilding rather than moving. That is an argument for going sooner rather than an argument against going, because those plugins are not coming back, and the same work only gets bigger the longer the site sits on them.

When we would tell you not to bother

• A site nobody edits. If the content has not changed in two years and nobody is asking for new sections, the change loop is not costing you anything, and Gatsby will keep building for a good while yet.
• A redesign that is already going to change how the pages are put together. If the content model and the page structure are both being rethought, porting first is work you then throw away, and building the new thing in Astro directly costs about the same. A visual refresh on the same structure is the opposite case, and there we would port first, because you then make the design changes in the stack you are going to keep.

How to tell which one you are

The useful question is not whether Gatsby is dead, because arguing about that gets you nowhere and the site keeps building either way. It is how often you want to change the site, and what happens now when you try.

If changes take longer than they feel like they should, and you have quietly stopped asking for some of them, that is the argument for moving, and it is a better one than any benchmark we could put in front of you.

We moved our own sites before we started recommending it, which is the main reason we can tell you where the time actually goes rather than where a migration guide says it should.

If you have a Gatsby site and want to know what moving it would involve, here is how we handle these migrations, and you are welcome to just ask us what yours would take before committing to anything.