Migrate from Gatsby to Astro or Next.js
Gatsby Cloud is gone and framework releases have slowed to maintenance. Your React components don’t have to go with it: we move them to Next.js or Astro, replace the GraphQL layer and plugins, and keep every URL.
Yegparian PLLC (opens in a new tab)Signs you have outgrown Gatsby
Gatsby made fast static React sites mainstream. These are the moments teams find it has stopped moving with them.
The framework has gone quiet
Since Netlify acquired Gatsby in 2023, releases have slowed to maintenance. Fewer fixes land, and the plugins you depend on update even less often.
Builds take longer every month
Every content edit rebuilds the site, and image processing and page queries grow with it. Editors wait minutes to see a typo fixed.
Gatsby Cloud is no longer an option
Gatsby Cloud was retired after the acquisition, and the hosting, previews and incremental builds it gave you now need to be rebuilt somewhere else.
Plugins block every upgrade
Source, image and MDX plugins pin you to old versions of React, webpack or the CMS SDK. One unmaintained plugin can hold back the whole site.
Hiring for GraphQL glue
New developers have to learn gatsby-node, page queries and the data layer before they can change a page. Most of them already know Next.js.
What happens to your Gatsby plugins
Pick what your site uses today. Each plugin becomes part of the framework, a few lines of code, or turns out not to be needed.
- GraphQL data layerDirect queries per pagePage queries become GROQ, the Payload Local API or your CMS’s own SDK, fetched where the page renders. No schema to keep in sync.
- gatsby-node createPagesFile-based routesProgrammatic pages become dynamic routes in Next.js or Astro, with slugs read from the CMS and the same URLs as today.
- gatsby-source-* pluginsYour CMS, kept or movedKeep Contentful, WordPress or Markdown and query them directly, or move the content to Sanity or Payload by script.
- gatsby-plugin-imagenext/image or Astro assetsResponsive sizes, modern formats and lazy loading are built into both frameworks, without a sharp step on every build.
- gatsby-plugin-mdx / remarkMDX in the frameworkMarkdown and MDX move to Astro content collections or MDX in Next.js, with your custom components still mapped.
- React Helmet / Head APIMetadata built inTitles, descriptions, canonical URLs and Open Graph tags come from the Next.js Metadata API or Astro’s head, fed by the CMS.
- Sitemap and manifest pluginsGenerated in codeThe sitemap, robots.txt and web manifest are generated from your content on every deploy.
- Gatsby FunctionsAPI routesServerless functions move to Next.js route handlers or Astro endpoints, usually with no change to the logic inside.
- Analytics pluginsAnalytics with consentGoogle Analytics or a privacy-first alternative, loaded behind a consent banner where the law requires one.
- Redirects in gatsby-nodeRedirects in the configEvery createRedirect and every changed URL is mapped in the framework or hosting config, versioned with the code.
What changes when you leave Gatsby
Next.js and Astro decide how pages are built. Sanity and Payload are where your team edits. We recommend a pair after the audit.
| Feature | Astro + Sanity | Next.js + Payload | Gatsby |
|---|---|---|---|
| Framework | |||
| Active development and regular releases | Maintenance releases | ||
| Reuse your React components | As islands | ||
| Pages served pre-built from a CDN | |||
| Ships only the JavaScript a page needs | Per route | ||
| Content | |||
| Content edits live without a full rebuild | Cache-dependent | ||
| One GraphQL layer across every source | Query each source | Query each source | |
| Live preview while editing | Depends on the CMS | ||
| Hosting and logic | |||
| Host on any platform | Via adapters | ||
| Server logic and APIs | Gatsby Functions | ||
Sites we've already moved
Different stacks for different jobs: a law firm on Next.js and Payload, a residential launch and our own studio on Astro and Sanity.
Yegparian PLLC
WordPressNext.js + Payload
An Austin trial litigation firm. Practice areas, matters and insights are Payload collections, and every page is pre-rendered and served from the edge.
yegparianpllc.com (opens in a new tab)25 Cuba
WordPressAstro + Sanity
A new residential address in Canary Wharf. Apartments, amenities and galleries are edited in Sanity, and the site ships as static Astro pages.
25cuba.com (opens in a new tab)Celerart
WebflowAstro + Sanity
Our own studio site. Every one of the 164 old URLs was carried over or redirected, and all content is now edited in Sanity.
celerart.com (opens in a new tab)
How we move a Gatsby site
Your Gatsby site stays live until the new one is ready. The switch is a DNS change, not a weekend of downtime.
Audit
Audit
We crawl every URL, read gatsby-node, gatsby-config and every page query, list each plugin, and export your rankings, so nothing is lost by accident.
Data and content
Data and content
Each GraphQL query is mapped to its source. Your CMS stays as it is, or its content moves to Sanity or Payload by script, with rich text converted and images re-uploaded.
Components
Components
React components move over with small changes: Gatsby Link, StaticImage and page-query props are swapped for their Next.js or Astro equivalents.
Front end
Front end
We rebuild the routes in Next.js or Astro, keeping the design or giving it a refresh if one is due, and check every template against the live site.
Redirects and launch
Redirects and launch
Every old URL keeps its address or gets a permanent redirect. Metadata, sitemaps and structured data are compared before the DNS switch.
Handover
Handover
You get the repository, the deploy pipeline and a walkthrough. Then the Gatsby build can be retired.
Questions about leaving Gatsby
Next.js suits sites with logged-in areas, heavy interactivity or a lot of server logic. Astro suits content sites, where most pages need little or no JavaScript, and still runs your React components as islands. The audit recommends one.
Mostly, yes. Components move over with small changes: Gatsby’s Link and image components, and props that came from page queries, are swapped out. The markup and styles usually stay as they are.
They are replaced by direct queries to each source, fetched where the page renders: GROQ for Sanity, the Local API for Payload, or your current CMS’s SDK. There is no data layer schema to keep in sync.
No. If Contentful, WordPress or Markdown works for your team, the new site reads from it directly. If the CMS is part of the problem, we move the content to Sanity or Payload by script in the same project.
Not if the move is planned. Every URL keeps its address or gets a permanent one-hop redirect, and titles, descriptions, Open Graph images and structured data are carried over and checked before launch.
You do. The repository, hosting account and domain are in your name, and the site runs on Vercel, Netlify or your own infrastructure. If you would rather not manage it, we can host it for you, with no lock-in.
It depends on the number of templates, page queries and plugins. After the audit you get a fixed scope and timeline, and the Gatsby site stays live until launch day.
