Gatsby Migration Services

Gatsby served a lot of teams well between 2018 and 2022. In 2026 it is a framework in maintenance mode: Netlify acquired Gatsby Inc. in February 2023, shut down Gatsby Cloud in September 2023, and Gatsby 5 (November 2022) is still the last major release. There is no roadmap, the plugin ecosystem is thinning, and every React, Node, and sharp release makes the next gatsby build a little less certain. StaticCraft migrates Gatsby sites to Astro or Next.js without losing the search traffic you spent years earning.

Why migrate now

• Dependency rot. Gatsby pins old versions of webpack, Babel, and GraphQL tooling. Security audits flag transitive dependencies you cannot upgrade without forking plugins.
• React compatibility risk. Gatsby 5 targets React 18. As your other front-end code moves on, you end up maintaining two React worlds.
• Gatsby Cloud is gone. Incremental builds, CMS previews, and the build cache that made large Gatsby sites tolerable went with it. Full builds on generic CI are slower and more fragile.
• Hiring. Fewer engineers want to learn a framework with no future; the people who know it best are moving to Astro and Next.js.

None of this means you must migrate this quarter. If the site builds and the team is stretched, our Gatsby maintenance service can stabilize it first. But "stabilize now, migrate later" should be a decision, not a default.

Step 1: free migration assessment

Before we quote anything we run a fixed, no-cost assessment of your repository and production site:

• Plugin inventory. Every gatsby-* plugin, what it does, and what replaces it in the target framework (or whether it was dead weight).
• GraphQL surface. Every page query, static query, and createPages call, mapped to the content source it reads. This is the real size of the migration.
• Traffic and SEO audit. Which URLs carry your organic traffic and backlinks, current structured data, sitemap and canonical setup, and Core Web Vitals baselines.
• Build and hosting review. Build time, Node version, CI setup, and where the site is hosted now that Gatsby Cloud is gone.

You get a written report with a recommended target, a risk list, and a fixed-scope proposal.

Step 2: choosing the target

We recommend one of two targets, and we will tell you which.

Astro for content-led sites: marketing sites, documentation, blogs, and anything where most pages are HTML with small pockets of interactivity. Astro's content collections map almost one-to-one onto Gatsby's markdown/MDX sourcing, it ships zero JavaScript by default, and you can keep your existing React components as islands.

Next.js (App Router) for app-like sites: authenticated areas, dashboards, commerce, or sites that already share a React component library with a product. generateStaticParams replaces createPages, server components replace Gatsby's build-time GraphQL layer, and you keep the React ecosystem you already own.

We do not recommend rebuilding on a framework because it is fashionable. The assessment is where we make the case either way.

Step 3: zero-SEO-loss migration process

Search traffic is the asset most at risk in a migration, so the process is built around protecting it:

1. URL parity. Every indexed URL on the old site either exists at the same path on the new site or has an explicit 301. We generate the parity list from the old sitemap and Search Console exports, not from memory.
2. 301 map as code. Redirects live in the framework config or host config and are tested in CI, so nobody can "clean them up" by accident later.
3. Structured data and metadata. Titles, descriptions, canonicals, Open Graph, and JSON-LD are diffed page by page against the Gatsby output before cutover.
4. Sitemap and robots parity. The new sitemap lists the same canonical URLs; /index-style duplicates and stale paths are dropped deliberately, not silently.
5. Core Web Vitals before and after. Lighthouse and field data are captured on the old site, and the new site must meet or beat them before DNS changes.
6. Cutover and watch. DNS cutover with the old build kept warm as a rollback, then two weeks of Search Console and log monitoring for crawl errors.

Pricing

Migrations are fixed-scope and priced from the assessment, mainly on page-template count, content volume, and plugin complexity:

• Small — a handful of templates, a single content source, few custom plugins.
• Medium — multiple templates, a headless CMS, custom GraphQL source plugins or MDX components.
• Large — multi-thousand-page sites, several content sources, DSG/SSR routes, or custom build tooling.

You will see the band and the number in the assessment report before you commit to anything.

FAQ

Can you keep our existing React components? Usually yes. In Astro they become islands; in Next.js they move largely unchanged, with Gatsby-specific imports (Link, GatsbyImage, useStaticQuery) swapped for framework equivalents.

Will our CMS still work? Contentful, Sanity, WordPress, and similar sources all have first-party or well-maintained loaders for both targets. The migration removes the Gatsby GraphQL layer between you and the CMS, which is usually simpler, not harder.

What about Gatsby 3 or 4 sites? We migrate those too. Sometimes we upgrade to Gatsby 5 first so the site builds reliably during the migration; the assessment decides.

How long does it take? It depends on the band above. The assessment gives you a schedule, and we do not start the clock until the scope is agreed.

Ready to find out what your migration actually involves? Contact us to book the free assessment.