Affordable and Fast Migration

How Evil Martians moved from Gatsby to Astro in nine days without rewriting a single React component

For three years running, Evil Martians couldn’t justify a website migration from Gatsby, even though the framework was winding down. For a busy consultancy, this would mean pulling engineers off client projects, a costly and laborious prospect. But to the team’s surprise, in August 2026, a single engineer moved the entire website to Astro in just nine days.

Homepage JavaScript at load fell 61% overall and mobile Lighthouse performance scores rose from 66 to 90. Without changing any existing React components, their homepage weight decreased from 2.1 MB to 1.8 MB. After optimizing their hydration strategy and fully converting to Astro’s islands architecture, the team saw this drop even further to 1.1 MB.

Challenges

Evil Martians realized that Gatsby could not be the future of their corporate website and blog infrastructure. As their site grew to 1000+ HTML pages, maintenance costs and code fragility were accelerating over time:

• 17 Gatsby plugins in package.json alongside the framework itself, and 4 dependencies that needed hand-written patches to behave.
• A GraphQL data layer sitting in front of a static site, with components and pages pulling their data through Gatsby-specific hooks.
• Dependency security advisories accumulating with no upstream fix available, in a tree nobody was going to update.
• A shrinking pool of Evil Martians with specialized Gatsby knowledge who could safely touch the code.

They needed to migrate to a modern framework to reduce technical debt and keep the site maintainable. But they also needed to do it with as little downtime as possible.

Requirements

The Evil Martians team was looking for a way to make the migration manageable. They identified three non-negotiables:

• Whatever replaced Gatsby had to accept existing React components.
• Gatsby’s GraphQL layer needed an effective replacement, which would cover pages, components, and a custom content pipeline, without becoming its own migration.
• The new framework had to be built alongside the old one in the same repo. This would allow them to migrate as time and resources allowed, swapping new routes for old ones as they became available.

Fortunately, Astro checked all three boxes.

Solution and implementation

Astro’s framework-agnostic, islands architecture and strong plugin ecosystem made the migration from Gatsby straightforward. Astro’s first-party React integration meant that the existing component library ported over without any changes.

Astro’s content collections replaced the GraphQL layer, with no changes needed to the team’s custom content pipeline at all. The existing LiquidJS and JSX transformers continued to run, just behind content collection loaders instead of Gatsby GraphQL resolvers.

Results

Evil Martians was facing an aging framework, a GraphQL layer that was overkill for a static site, and a shrinking pool of engineers to maintain it.

The migration to Astro allowed the team to progressively refactor existing React components, eventually using Astro’s fine-grained control to hydrate each section independently. This change alone reduced the amount of JavaScript shipped on load by 61%.

Islands also made it obvious which parts of the site were heavy. The team discovered that the heaviest element on the homepage was the site search modal. Previously, this was loaded up front on every page, whether opened or not. Deferring this to first open as an island removed 437 KB of load-time JavaScript across the site.

Deleting the GraphQL layer also deleted its expensive prefetch behavior. Gatsby pulled 13.6 MB of query results for links nobody had clicked yet, more than six times the weight of the page itself. Astro’s prefetch feature optimizes navigations, but is much less aggressive, only prefetching linked pages on hover.

Additionally, Evil Martians improved performance and security by reducing dependencies. 17 Gatsby plugins and 4 patched dependencies are now gone. package.json is down from 108 to 86 direct dependencies.

Performance gains

The migration to Astro was a clear success. The following table breaks down the various savings in homepage asset sizes.

Read the full story at Evil Martians’ blog.