Move from Astra to a Next.js storefront

Astra sits on roughly 480,000 WooCommerce sites by CartFlows' count, more than any other theme, and its performance reputation is deserved at the theme layer. The slowdowns that bring stores to us are almost always downstream: a Starter Template that installed Elementor Pro plus four companion plugins, an Astra Pro addon bundle enabled wholesale, or a product page assembled from builder widgets that each ship their own CSS. Before quoting a migration we measure the three layers separately, because if Astra itself is 37KB of a 2.4MB page, removing Astra is not the fix — replacing the 2.3MB is.

• Measure theme assets, builder assets and plugin assets as three separate numbers
• Compare a Starter Template page against a page built in the block editor on the same site
• If Astra's own assets are under 10% of transferred bytes, the migration case has to come from somewhere else

This is the first hour of every Astra project, and it decides the price. Astra ships no builder of its own, so page content lives in one of four places, and stores that have been running for three years often contain all four at once. Starter Templates come in an Elementor version or a Beaver Builder version, never both, which means the import date tells you which builder the store inherited. Pages built later in Spectra or the block editor sit in a different format again. Each format needs a different extraction path, and the mixed case is the expensive one. Past three formats on one site, automated extraction stops being worth writing — hand-rebuilding the twenty pages that matter is cheaper than a parser for the long tail nobody visits.

• Elementor: content is JSON in post meta, extractable but nested
• Beaver Builder: serialized module data, needs its own parser
• Spectra and core blocks: block markup, the cheapest case by a wide margin
• Classic editor pages: plain HTML, trivial
• Astra Pro custom layouts: PHP-hooked fragments that no export includes

The astra-addon plugin lets you inject content at WordPress hook points — a shipping notice above the add-to-cart button, a trust row before the footer, a banner on category archives only. These fragments are invisible to page exports because they are not part of any page. They are rules. Nobody remembers all of them, and the store owner is usually surprised by two or three during the audit. We enumerate them from the Astra Pro custom layouts screen, decide which ones still earn their place, and rebuild the survivors as components with explicit placement rather than implicit hook order. Roughly a third get dropped, because nobody could say what they were for.

Astra Pro's WooCommerce module supplies quick view, off-canvas cart, sticky add-to-cart, infinite scroll on archives, and a set of gallery behaviors. Each is a small conversion feature the store has leaned on for years without anyone writing it down, and each needs a decision in the rebuild. Sticky add-to-cart and off-canvas cart usually come across: cheap, and they earn their place on mobile. Infinite scroll usually should not. It breaks the back button, it makes a category page impossible to link into, and past about 300 products it becomes a scroll trap that costs you crawlability for nothing.

• Keep: sticky add-to-cart, off-canvas cart, gallery zoom
• Rebuild deliberately: quick view, only if analytics show it is used
• Drop: infinite scroll on archives past ~300 products

Starter Template imports create pages the store never asked for — sample services, an about template, a blog stub — and they have been indexed for years. Pull twelve months of URLs from Search Console rather than the sitemap. The sitemap tells you what exists; Search Console tells you what earned something.

• Export twelve months of Search Console URLs, not the sitemap
• Classify each: keep, improve, 301 to a relevant page, or noindex
• Point removed template pages at the nearest real page, never the homepage
• Verify redirects on staging with a crawler before launch, not after

A migration off Astra stops paying for itself in three cases we see often enough to name. A store under roughly 200 products with pages built in the block editor is already close to the ceiling a headless rebuild would reach — the gap is not worth the project. A store whose slowness traces to database queries, an unindexed wp_postmeta table or an oversubscribed shared host will carry that problem into Next.js unchanged, because the REST and GraphQL endpoints hit the same database. And a team of one person who edits pages weekly in Elementor will lose more in workflow than they gain in milliseconds, unless the rebuild keeps WordPress as the editing surface. Fix hosting and queries first; if the store is still slow, the frontend is genuinely the bottleneck and the case is real.

Week one is measurement and inventory: three-layer performance breakdown, builder format audit, Astra Pro hook enumeration, Search Console URL export. Week two rebuilds the product template and the top three categories. That is where money and traffic concentrate, and if the schedule slips it slips here, not at the end. Week three connects product data, implements the redirect map and wires the checkout handoff so WooCommerce keeps owning payment, tax and orders. Week four is staging validation and a rehearsed rollback. Launch early in the week, while the people who can fix things are at their desks — a Friday launch buys you a weekend of nobody watching. Then hold still for fourteen days and read Search Console. Crawl rate, indexation and rankings all move on a lag, and shipping through that window is how teams lose the ability to attribute what happened.