Move from Betheme to a Next.js storefront

This is the fact that shapes the schedule. Pages built in Muffin Builder are stored in the theme's own structure, so deactivating Betheme does not leave you with clean content — it leaves you with content that only Betheme knows how to interpret. There is no partial migration where half the pages move and the rest keep working normally, and there is no generic parser to buy. The work is a builder-specific extraction, written once against your site, and it needs to run against your twenty highest-traffic URLs before anyone quotes the rest of the project with confidence.

• Muffin Builder content cannot be read without a theme-specific parser
• Deactivating Betheme leaves pages unreadable rather than plain
• Prototype the extraction on your top URLs before pricing the full site
• Pages built in the classic editor extract trivially — count them separately

Third-party comparisons put Betheme around 60/100, the lowest among the widely sold commerce themes, with The7 at 71 for reference. These are independent tests rather than vendor figures. The mechanism is the same one behind every configurable theme: supporting hundreds of pre-built layouts and a settings panel that can restyle anything means shipping the assets for all of it on every template. What makes Betheme's number worse than its peers is the combination — theme options, Muffin Builder, plus whatever the pre-built website installed alongside itself. None of that is recoverable by tuning past a fairly low ceiling, which is worth knowing before you spend a month trying.

Betheme ships an unusually large library of pre-built sites — over 700 — and importing one installs a supporting cast: sliders, form handlers, portfolio tools, sometimes a second builder. Years later the store still loads every one of them on every page, including the ones whose features were removed from the design long ago. Before the migration, list the active plugins and try to point at each one in the live storefront. Anything nobody can locate is not migrating — it is being deleted, and that decision is worth making explicitly rather than carrying the ambiguity into a rebuild.

Betheme applies design settings globally, then allows overrides per page and per post type — and migrations go wrong in the interaction between those layers. One category page looks unlike every other because somebody changed a setting in 2022 and recorded nothing. Work backwards from the rendered site instead: screenshot the ten templates carrying traffic and trace each visual difference to the layer that produced it. Slower than reading the panels top to bottom, and the only method that catches what nobody remembers doing.

Betheme is actively maintained by Muffin Group, so a build from several years ago says nothing about the current version. Update on staging, strip the plugins you could not locate, switch on whatever asset controls the release exposes, and sort out the images. Judge the result on twelve weeks of CrUX, not a Lighthouse run. A proposal that skips this step was written from a screenshot.

A per-template frontend ships only what each template needs — precisely what a configurable theme cannot do by construction. A product page loads product-page code; a category page loads its filters and nothing else. On Betheme stores that difference is usually the largest we see across theme migrations, because the starting point is the heaviest. The usual caveat holds: slowness rooted in an unindexed wp_postmeta or oversubscribed hosting survives the rebuild, because the API reads the same tables the theme did.

Under a few hundred products, with mobile field data green after the optimization pass, this project has nothing to recover and we would rather say so at audit. If most of your pages were built in the classic editor rather than Muffin Builder, you have a much cheaper option available inside WordPress: move to a lighter theme first and re-measure before considering a headless rebuild. And if nobody on your side will maintain a Next.js application after launch, the migration trades a slow store that gets patched for a fast one that quietly rots — which is a worse position eighteen months out, however good the launch metrics look.

Extraction prototype first, on the top twenty URLs, because that is what turns an estimate into a quote and it occasionally reveals that hand-rebuilding is cheaper. Then the settings trace across the ten traffic-carrying templates. Then the rebuild in the usual order: product template, categories and filters, homepage, marketing pages. Checkout stays on WooCommerce through the first launch. Keep Betheme installed but inactive for a fortnight after cutover — with a proprietary builder format there is no partial rollback, so the whole-site switch is the only one you have, and you want the option intact while the redirect map proves itself.