Move from Elementor to a Next.js storefront

Hello Elementor is deliberately almost nothing: a stylesheet stub whose entire job is to get out of Elementor's way. It is the second most common WooCommerce theme at 8.6% of stores, and it contributes close to zero of the weight anyone complains about. Everything you would want to migrate lives in Elementor Pro — the widgets, the Theme Builder templates, the global kit, the popups. So the sentence "we want to move off Hello Elementor" describes almost no work, and the sentence "we want to move off Elementor Pro" describes all of it. Getting this distinction wrong at quoting time is how a migration ends up half-priced and half-finished.

Before touching code, export the condition list from Theme Builder. Every template declares where it applies — all products, products in a taxonomy, a specific page, everything but the cart — and the resolution order decides which one wins when two match. This is the routing logic of the store, written in a UI, and it is the single most common source of post-launch surprises. The pattern we hit most often: a store has a general product template plus one override for a category added during a campaign two years ago, nobody remembers it, and after migration those forty products render with the wrong layout because the override was never carried across.

• Export every Theme Builder template with its conditions before development starts
• Map overlapping conditions and resolve which one is actually rendering today
• Check singular, archive, product, cart, checkout and 404 separately — they are separate templates
• Any template whose condition nobody can explain gets tested on live before it is dropped

Elementor stores each page as a JSON tree in the _elementor_data post meta field. Extracting from that tree gives structured content — sections, columns, widget types, settings, the actual text and image IDs — which is what a component rebuild needs. Scraping the rendered HTML gives you Elementor's wrapper divs, its inline styles and its class names, which is what you are migrating away from. The JSON path costs more upfront and it is the only one that produces a clean storefront. There is one honest exception: under about fifteen builder-made pages, writing a parser is not worth it, and rebuilding by hand from screenshots is faster.

• Extract from _elementor_data post meta, not from the front end
• Map widget types to components once, then reuse across every page
• Resolve image IDs to the media library rather than copying rendered URLs
• Keep the text verbatim — rewriting copy during a migration makes ranking changes unattributable

Loop Grid is where Elementor stopped being a layout tool and became a query builder, and it is the widget that most often surprises a migration. Each grid holds a query — post type, taxonomy filters, ordering, offset, related-to-current logic — and on a mature store those queries are scattered across dozens of pages with no inventory anywhere. They have to be enumerated and reimplemented against the WooCommerce API, and the ordering rules in particular need checking, because "manual order" in a Loop Grid maps to menu_order and a rebuild that sorts by date silently reshuffles every merchandised collection. Elementor's own tracker also documents layout shift from off-canvas widgets inside Loop Grid templates, which is worth measuring before you assume the CLS came from images.

Elementor ships several performance features that are off by default, and a store that has never enabled them is not running Elementor at its best — so measuring it in that state overstates the case for leaving. Inline Font Icons renders icons as inline SVG and drops the Font Awesome and eicons libraries with their CSS and font files. Conditional Swiper loading saves 26.7KB of CSS on any page without a carousel. Separate style loading for WooCommerce widgets ships only the widget styles a page actually uses. Enable all three, remeasure, and compare against the original numbers. If the gap closes to where the store is acceptable, you have your answer and it costs a week rather than a quarter.

Two Elementor Pro features have no equivalent on the other side, and both get remembered in launch week. Popups carry triggers and display rules — exit intent, scroll depth, after N sessions — and stores run more of them than they remember, usually including one firing on mobile since a campaign that ended. Forms carry submission actions: email routing, webhooks, CRM handoffs. Decide on each before development, not during it.

• Inventory active popups with their triggers and audit which still convert
• List every form action, especially webhooks and CRM handoffs
• Decide per item: rebuild in Next.js, keep in WordPress behind the API, or retire
• Test form submissions end to end on staging, including the receiving system

Three situations where we tell people not to do this. Where marketing publishes landing pages weekly without a developer, a build that drops the visual editing path costs real money every week it is in service. Scope that path in, or leave the store alone. If Core Web Vitals are already green in field data from CrUX, a rebuild is not going to be quoted honestly on performance grounds and you should ask what else it is for. And if the checkout is heavily customized through Elementor's WooCommerce widgets plus a subscriptions or bookings plugin, rebuilding that path in this project is premature. The safe move is a hybrid launch that leaves native checkout alone; attempting both at once is how migrations slip a quarter.

Product template, top categories, homepage, marketing pages — in that order. Product and category pages hold both the traffic and the tangled Theme Builder conditions, so they go first; marketing pages are cheapest to redo, so they go last. Checkout stays on WooCommerce through launch.