Gatsby Is Dead, Now What? Migrating Gatsby Sites

Is Gatsby dead, and do you need a Gatsby migration?

Gatsby isn't switched off, but it's no longer a safe long-term base for a marketing site. Since Netlify acquired Gatsby and wound down Gatsby Cloud, development has slowed, many plugins have gone unmaintained, and upgrading to current React and Node versions has become harder. A planned Gatsby migration now is cheaper than an emergency one later.

You don't need to move this week. If the site builds, deploys and ranks, you have time to choose well. The warning signs that you should start: builds failing after dependency updates, plugins with open security advisories, and a team that avoids touching the site because nobody understands the GraphQL layer anymore.

A Gatsby site is also a natural point to ask a bigger question: should the marketing site stay in code at all? Our hub on moving from code to a visual builder covers that decision in depth.

Where should you migrate a Gatsby site?

Migrate a Gatsby site to wherever the people who edit it will be fastest. That one question narrows four realistic options to one or two.

If your Gatsby site is a blog or docs site that engineers maintain in Markdown, Astro is the closest relative and usually the smoothest move. If it's a marketing site with React components you'd like to reuse in the product, Next.js makes sense. If marketing has been waiting on engineers for every change, the move is your chance to hand them the site with Framer or Webflow.

When should you move Gatsby to Next.js or Astro?

Move Gatsby to Next.js or Astro when developers will keep editing the site and you want to reuse your React components and Markdown content. Both keep a code-first workflow, so the team's habits survive the move.

Gatsby to Astro

Astro ships static HTML by default and adds JavaScript only where you ask for it. Markdown and MDX content moves across with little change, and React components can be used as islands. Large content moves are realistic: zenml.io reportedly moved 2,224 pages to Astro with the help of coding agents.

Gatsby to Next.js

Next.js suits teams whose marketing site sits beside a React app, or who want a headless CMS so non-developers can edit. Static generation and server rendering are both built in, and the component model is familiar. If you go this way, plan the CMS early. A headless CMS such as Payload, Sanity or Contentful gives marketers an editor without giving up the codebase.

In both cases, the GraphQL data layer goes away. Pages read content directly from files or a CMS, which is simpler but means rewriting every page query.

When should you move Gatsby to Framer or Webflow?

Move Gatsby to Framer or Webflow when marketers or designers should own the site and the site is purely marketing. You lose the code workflow and gain editing speed for the people who need it.

This route is a full rebuild. Neither builder can import Gatsby code, so layouts are recreated, content is exported to CSV and imported into the builder's CMS, and Gatsby plugins are replaced by built-in features or embeds. The gain is that changes stop needing a pull request and a build.

• Framer fits design-led teams shipping landing pages often. Our Next.js to Framer migration guide covers the same rebuild pattern from a React starting point.
• Webflow fits teams with relational content, such as posts tied to authors, categories and industries. The Next.js to Webflow migration guide shows how to map Markdown front matter to Webflow fields.
• Both output server-rendered HTML, so crawlability is not a concern if metadata and URLs are carried over.

If you're torn between the two, our Framer alternatives guide lays out where each builder starts to strain.

What breaks in a Gatsby migration?

The parts that break are the ones Gatsby handled for you through plugins: images, sitemaps, redirects, RSS and head tags. List every plugin in your config before you start, and write down what replaces each one.

How do you run a Gatsby migration without losing rankings?

You keep rankings by freezing URLs, carrying over metadata, and testing the new site against a crawl of the old one before launch. The platform matters far less than these three habits.

1. 1

   Crawl the Gatsby site

   Export every URL with its title, description, canonical and status code. Save top pages and backlinks from Search Console.

2. 2

   Audit plugins and content

   List each plugin and its replacement, and mark pages to keep, merge or delete.

3. 3

   Rebuild templates

   Recreate page and post templates on the new platform with the same URL structure.

4. 4

   Move content

   Copy Markdown to Astro or Next.js, or convert and import it into Framer or Webflow CMS.

5. 5

   Compare crawls

   Crawl the staging site and compare titles, canonicals, headings and status codes against the old crawl.

6. 6

   Launch with redirects

   Add 301s for every changed URL, switch DNS, submit the sitemap and watch Search Console.

Changing platform, design and copy at the same time is common and usually cheaper. It also makes it harder to know what caused a ranking change, so keep URLs and core copy stable on pages that already rank. If your Gatsby site leaned on client-side rendering for parts of the page, our guide to Core Web Vitals across Framer, Webflow and Next.js helps you compare the new site's performance.

Our verdict on Gatsby migration

Don't migrate in a panic, but don't wait for the build to break either. Pick the destination by who edits the site, not by which framework is popular this year.

Running costs differ too. Code platforms cost little to host but need developer time, and builders cost more per month but less in engineering. Our model of Webflow vs Framer vs Next.js total cost over three years puts numbers on that trade-off before you commit.