"Our site is slow," "it's hard to update," "the framework we're using seems outdated." When you bring these three issues to a development agency, the quote that comes back is almost always for a "complete overhaul."
The quote's price tag swells with redesigning and rebuilding pages from scratch. Yet the original consultation was about speed and maintainability; often, not a single word was said about wanting to change the design. Even so, proposals call for a complete rebuild because the work of investigating how much existing code can be reused takes effort, and before looking into it, they conclude that "starting from scratch is faster."
The record of Evil Martians migrating their own company site from Gatsby to Astro in August 2026, highlighted in an official Astro case study in September 2026, provides valuable material to rethink that assumption: One engineer, 9 days, and not a single existing React component rewritten.
What was kept, and what was replaced
What was replaced in this migration was the layer that builds pages and the layer that retrieves data.
In Gatsby, even static sites were structured to retrieve content via GraphQL. After the migration, this was replaced by Astro's content collections, reading data through typed content and standard asynchronous functions. In short, they did not change the parts rendering the site's visuals, but rather replaced the plumbing behind them.
Meanwhile, the React components forming the UI were brought over as-is. Under Astro's Islands architecture, Astro builds the page's outer shell and runs only the specific parts that need to execute in the browser. Because it allows a migration approach of replacing only the outside while leaving the inside untouched, no component rewriting was required.
How the numbers shifted
The published actual measurements are as follows:
| Metric | Pre-migration | Post-migration |
|---|---|---|
| Home page initial load JavaScript | — | 61% overall reduction |
| Mobile Lighthouse performance | 66 | 90 |
| Home page weight | 2.1MB | 1.8MB → 1.1MB |
The home page weight is listed in two stages because they represent different milestones. 1.8 MB is the number from "simply migrating without modifying the React components at all," while 1.1 MB is the result of subsequently reviewing which parts needed to run in the browser.
In other words, the impact of the migration itself and the impact of post-migration tuning are distinct. When these two are lumped into a single line item in a quote, it becomes impossible to tell what is mandatory and what constitutes additional investment.
Can you do the same with your own site?
Whether this case study can be applied directly depends on three conditions.
1. Is your current site built with components? If it is broken down into components with React or Vue, you have reusable assets. HTML templates can also be partially reused, but dependencies for data retrieval and event handling will need to be investigated separately.
2. Do you want to change the design, or can it stay as is? If you want to refresh the design, the benefit of retaining components diminishes. Even then, you can separately evaluate whether the data layer or certain components can be kept. Splitting orders into "making it faster" and "changing the look" clarifies the rationale behind the pricing.
3. Does how you manage content need to change? If you manage articles and case studies with a CMS and are keeping that CMS, only the display side needs migrating. If you are switching CMS platforms altogether, estimate data migration and changes to editorial workflows as separate line items.
If your situation aligns with all three—components exist, design is preserved, CMS is kept—it is well worth asking why assets are not being reused the moment a quote for a complete overhaul appears.
What to look for when choosing a migration target
Regardless of whether you choose Astro, there are key points to consider when evaluating a migration destination.
Are updates released continuously? Astro 7.3 was released on September 3, 2026, and incremental improvements arrive regularly. The issue in choosing a framework is not the abundance of new features, but whether updates will continue years from now and whether your team can integrate those updates into ongoing maintenance.
Is the migration process officially documented? Astro provides an official migration guide from Gatsby in its documentation. Whether procedures are publicly documented directly impacts estimate accuracy. Migrations without established procedures make research hours unpredictable.
Will it result in a setup your team can update in-house? If updating content still has to go through a development agency after migrating, the difficulty of making updates remains unresolved. Be sure to include an architecture your team can manage directly post-launch as a migration requirement.
If you are still debating the choice of framework itself, it will likely be faster to first read about choosing between Next.js and Astro.
Common pitfalls
Do not use "9 days" as a benchmark for your own project timeline. Those nine days represent an in-house engineer migrating their own company's site. In custom development projects where confirming specifications and building stakeholder consensus take time, the same tasks entail a completely different timeframe. What you should reference is not the number of days, but the architectural approach that avoided rewriting components.
Explicitly specify the requirement to preserve URLs. If page URLs change during a migration, search traffic cuts off right there. Whether redirects from old URLs to new URLs are included is not always made explicit in quotes.
Speed improvements do not end with migration alone. As shown in the table above, what made a major difference was the review phase after migration. If completing the migration is treated as the finish line, you will fall short of the expected performance gains. Decide what will be included in the initial phase before getting started.
What to do next
Open your browser's developer tools on your site's home page and check the total size of JavaScript being loaded. Rather than the raw figure itself, the real decision criterion is whether you can explain which on-page feature each script is needed for.
If unexplainable payloads make up the majority, your site may become much lighter simply by changing how it is assembled, without needing a full rebuild.
At GleamHub, we assist with feasibility assessments for migrating existing sites without rebuilds, URL-preserving migrations, and architectural design that enables in-house updates post-launch through our website production and renewal consultations. Because approaches vary depending on current configurations and update workflows, scope is estimated individually. Please reach out via Contact Us.
