Gatsby Is Effectively Abandoned: Migrate Your Drupal Site

Gatsby, the framework behind a large share of decoupled Drupal builds from 2019 to 2022, is no longer being actively developed. It isn’t broken, and Netlify hasn’t declared it dead. But the core team is gone, the release cadence has collapsed to essentially one engineer, and the plugin ecosystem that made Gatsby worth a second codebase is decaying underneath it. That gap, alive but unmaintained, is what makes a Gatsby Drupal migration a real question now instead of a hypothetical one.

For most Gatsby-plus-Drupal sites, that isn’t an emergency today. It’s a clock. That matters most for public-sector and higher-education sites, which adopted decoupled Drupal earlier and harder than most verticals, and which now face a separate deadline for an entirely different reason.

Is Gatsby Still Actively Maintained?

Gatsby is technically still maintained, but barely.

What Happened After Netlify Acquired Gatsby?

When Netlify acquired Gatsby in February 2023, both companies said the framework would continue to evolve, with core contributors moving to Netlify to maintain it. Gatsby's own announcement said as much. Gatsby Cloud, the hosted product built around it, was sunset before the year was out.

How Often Does Gatsby Ship Releases Now?

The release history on GitHub shows what actually followed. The latest core release, 5.16.1, shipped February 10, 2026, as a fix for Head API regressions. The release before it, 5.16.0 in January, added React 19 and Node 24 support. Both came almost entirely from a single contributor plus an automated dependency bot, not a team shipping a roadmap. Nothing has shipped since: as of this writing in August 2026, more than five months have passed with no further release.

Download volume tells the same story differently. npm trends data puts Gatsby in the 200,000 to 300,000 weekly downloads range against Next.js at well over 36 million, a gap of two orders of magnitude that has only widened. Both figures move week to week, so treat the ratio, not the exact count, as the signal. That gap is mostly about where new projects start: Gatsby’s downloads largely reflect CI builds on sites already running it, not new adoption.

Is gatsby-source-drupal Still Maintained?

Yes. gatsby-source-drupal, the official plugin connecting Gatsby to a Drupal backend, is still patched alongside the core framework, most recently in step with the January 2026 core release. The Drupal connection is not the part that is decaying.

What is gone is the team, the roadmap, and most of the third-party plugin ecosystem around Gatsby. That ecosystem is what made Gatsby worth the operational overhead of a second codebase in the first place, and it is where a 2020-era build carries its real risk.

Why Does This Hit Government Drupal Sites Hardest?

Government and higher-education Drupal sites carry an outsized share of Gatsby's decline, because Drupal already dominates public-sector web infrastructure and Gatsby’s short adoption window landed squarely inside that base. Drupal is the dominant CMS across US federal agencies and large state governments, and it is especially entrenched at the scale where decoupled builds were commissioned.

Layer that onto Gatsby’s adoption window, which ran almost exactly from 2019 to 2022 across the Drupal agency ecosystem, and a state agency or university portal that decoupled onto Gatsby during that stretch is unremarkable. Government build cycles run long; a 2020 architecture decision is still live infrastructure in 2026.

A second, unrelated deadline compounds the Gatsby problem for these same organizations. The Department of Justice’s ADA Title II rule, extended in April 2026, now gives state and local entities serving 50,000 or more residents until April 26, 2027, to meet WCAG 2.1 AA, and smaller entities until April 26, 2028. A team that has to touch its front end for accessibility remediation before that date anyway is looking at a natural, budget-justified moment to also retire a front end nobody is driving forward. Waiting for both deadlines to collide at once is the more expensive path.

Image

For teams that decide to move, Next.js is the usual destination. It is React-based like Gatsby; it has a maintained Drupal integration in next-drupal, and it is where most of the Gatsby ecosystem's momentum went. That makes it the default comparison for the rest of this article, though it is not automatically the right answer.

When Should You Not Rebuild in Next.js?

A Next.js rebuild isn't the right answer for every stranded Gatsby-Drupal site. Two situations in particular call for something else.

If the only original reason to decouple was Gatsby’s static-site speed, and there’s no real need to serve more than one channel from the same content, Drupal CMS 2.0’s Canvas builder delivers visual, component-based editing natively. For that site, recoupling into modern Drupal is very likely cheaper than rebuilding the same decoupled pattern in a different front-end framework, and it removes a codebase instead of swapping one. We build those on Varbase, our enterprise Drupal distribution, which supplies the component-based theming layer Canvas needs.

Re-coupling also returns something a decoupled front end cannot reach. The AI features in Drupal CMS 2.0, including page generation from prompts and the site-building assistant, work against Drupal's own component model. A site that comes back to native Drupal picks those up. A site that migrates from one JavaScript framework to another does not.

If the team has no dedicated front-end engineering capacity and none is budgeted, the problem was never which JavaScript framework sits in front of Drupal. Moving from Gatsby to Next.js without addressing that gap just swaps one dependency chain, deployment pipeline, and JavaScript maintenance burden for another, without removing the second codebase the team was never resourced to carry.

Our View: A Risk Curve, Not a Countdown Clock

Gatsby's decline is a risk curve, not a countdown clock, and that reframes the question from “how fast can we migrate” to “what’s our actual exposure, and what’s the latest point we can start without the curve catching up to us.” Most of what’s been written about Gatsby’s decline treats it as an emergency: migrate now, before it’s too late. That framing doesn’t match what the evidence shows. The core Drupal-to-Gatsby plumbing still runs and still gets patched. Nothing is on fire.

What’s true instead is a slower, more specific risk. No one is driving the roadmap; ongoing Node and React compatibility work depends on one person’s continued attention, and the third-party plugins a typical 2020-era build leaned on are aging out unevenly, without warning.

There is a structural lesson in the difference between the two halves of this stack. Drupal is community-governed, and it is still shipping releases on a published schedule. Gatsby was venture-funded, acquired, and quietly wound down by its new owner. Both were open source. Only one had a governance model that survived a change in commercial interest.

At Vardot, we build both progressively decoupled and fully headless Drupal, across government, higher education, editorial, and financial-services platforms, work that includes Georgetown University. As a Drupal Diamond Certified Partner with more than 200 platforms launched, this isn’t a case for the bigger rebuild by default: the recommendation depends on what the site actually needs, not on which engagement is larger.

How Do You Find Your Actual Exposure?

Three questions place most Gatsby-Drupal sites into one of three clear paths.

Do you have a forcing function in the next 12 to 18 months?

An accessibility deadline, a security audit, a planned redesign, or a hosting contract renewal all count.

Is your original reason for decoupling still true?

Multi-channel content delivery or genuinely complex front-end interactivity justifies staying decoupled. Static-site speed alone, now that Drupal itself offers native visual, component-based page-building through Canvas, usually doesn’t.

Can You Sustain a Front-End Team for the Next Three Years?

A decoupled architecture only stays viable with a team funded to maintain it for years, regardless of which framework runs it.

A yes to a forcing function and a yes to needing multi-channel delivery means prioritizing a Next.js migration now, tied to the deadline already on the calendar. A site whose only reason was speed, with no channel requirement, is usually better served by evaluating a return to native Drupal. A site with neither a forcing function nor the budget can reasonably put a 12- to 18-month horizon on the decision instead of an emergency one, provided someone actually owns tracking that horizon.

What Does a Gatsby-to-Next.js Migration Keep and Rebuild?

The Drupal backend moves largely intact. What carries over without significant change:

• Content models, editorial workflows, and permissions
• The JSON:API or GraphQL endpoints Gatsby was already reading from
• Most existing React component code, since both frameworks build on React

What doesn’t survive the move is the plumbing underneath the components:

SEO needs deliberate handling through the switch, not an afterthought: preserving URLs, adding redirects wherever structure changes, and carrying over metadata and schema. That matters more for a government or university site with years of indexed, cited pages than for a marketing site starting fresh.

If your team is trying to work out where a specific Gatsby-Drupal build actually stands, an architecture assessment answers that against your own dependencies and forcing functions rather than a generic timeline. It runs as the Align phase of the Vardot Delivery System, and it produces a plugin inventory, an exposure rating, and a costed recommendation.