Bricks to Next.js: A Precise Migration for a Developer-Built Site

The builder that tells you where it keeps things

Bricks Academy publishes a data model. Each page has three content areas stored in post meta: _bricks_page_header_2, _bricks_page_content_2 and _bricks_page_footer_2. Each area is a flat array of elements, not a nested tree. Every element carries the same eight fields: id, name, parent, children, settings, selectors, label and themeStyles. Templates are posts of the bricks_template type. Global data sits in the options table under names like bricks_global_classes and bricks_components.

That is unusual candor for a page builder, and it changes the job. With most builders we reverse-engineer a format. With Bricks we read a documented one, write an extraction script against it, and check the output against the live pages. Nothing is guessed. The result is still a rebuild, not a conversion: Bricks elements become React components and clean content fields, not a translated copy of the builder's output.

The second advantage is human. Bricks is a tool developers choose on purpose, so the site you are leaving often has real global classes, components with properties and query loops in place of copy-pasted sections. That structure carries straight across. A site built by stacking one-off styles on every element is slower to move, and we will tell you which kind you have after the first look.

What to pull from Bricks, and where each piece lands

Current Bricks versions have a unified Import / Export in the builder's Settings that packages theme styles, global classes, variables, color palettes, breakpoints, components, templates, custom fonts, icon sets, global queries and selected settings into one ZIP with a manifest. Templates can also be bulk exported from Bricks, Templates as JSON or ZIP. We take both, plus a database copy, before any work starts.

Components and classes: the design system you already paid for

Bricks components are reusable blueprints. Change the main component and every instance follows, while each instance keeps its own content through properties: text, rich text, image, link, toggle, even a query loop. Slot elements mark places where an instance can drop in its own content. Read that description again with React in mind. A property is a prop. A slot is children. A well-built Bricks component library is a rough draft of the Next.js component library.

Global classes work the same way. A site styled with a disciplined set of classes and variables translates into a small, predictable stylesheet, and the variable names often survive intact. Element-level styles, the one-off padding and colors set directly on an element, are what we hunt for in the extracted arrays. Each one is either folded into a class or recognized as a mistake. If the Bricks CSS files stop updating on the live site, that usually traces to the same tangle of external files and per-element settings.

In a well-built Bricks site, a component property is already a prop and a slot is already children. The migration is translation, not excavation.

Query loops, rewritten as data fetching

Query loops are where a Bricks site does its real work, and where the move pays off. Bricks supports five query types: posts, terms, users, API and array. Each loop has parameters: post type, taxonomy, order, posts per page, offset, sometimes a custom PHP query written in the query editor. We record every loop and its settings, then rewrite each one as a server-side fetch from Athena with the same filters and the same order, so the listing a visitor sees is identical.

• Posts loops become statically generated lists, refreshed on a schedule or when an editor publishes.
• Terms and users loops become category pages and team or author directories with their own fields.
• API loops become direct calls in server components, with caching set in code rather than in a plugin.
• Query Sort, Filter and Live Search become filters on prebuilt data, which removes a database query from every click.
• Pagination keeps its old URLs, or each page gets a redirect, so no indexed archive page goes missing.

The third option

Athena CMS, with AI agents on staff.

Not a theme and not a blank Next.js repo. The content system we put behind every custom site: plain fields, a real preview, every version kept, and AI agents that handle the chores a plugin only nags you about.

• PPicassoImages
• AApolloSite analysis
• AAresCompetitor watch
• PPrometheusContent holes
• AAtlasPage depth and structure
• DDelphiAI search visibility

ZDAOAand 12 more agents. Two come with Athena; the rest are monthly add-ons.

Meet the agentsTake the Athena tour

PPicassoWeekly · ImagesAApolloWeekly · Site analysis

Custom code gets a review before it gets a home

Bricks lets developers run PHP, HTML, CSS and JavaScript through the Code element once Code Execution is enabled for a role, and since version 1.9.7 that code needs a valid signature to run. Bricks also ships a Code review under Bricks, Settings, Custom code that lists every piece of executable code added through the builder. We run it first. It is the fastest honest map of what the site does that no element does.

Every snippet gets one of three outcomes. Logic the business needs (a price calculation, an API call, a form handler) is rewritten as a tested server function. Tracking scripts from the custom code settings move to next/script with sensible loading. Workarounds for old builder quirks are deleted. Custom elements registered in a child theme get the same treatment: we read the PHP, keep the behavior and rewrite it as a component.

From Bricks export to launch day, step by step

1. 1

   Copy the site to staging

   Bricks does not count local and staging sites against its license limit, so a working copy for extraction costs no seat.

2. 2

   Export globals and templates

   Run Global Import / Export for classes, variables, components, breakpoints and global queries, and bulk export templates from Bricks, Templates.

3. 3

   Run the Code review

   List every executable snippet, query editor and Code element, and decide rewrite, replace or delete for each one.

4. 4

   Extract content from post meta

   Script the header, content and footer arrays into structured content for Athena, separating copy and images from layout.

5. 5

   Crawl and map URLs

   Record every URL, title, description and canonical, then write the redirect map for anything that changes.

6. 6

   Build components, layouts and loops

   Rebuild the component library and templates in React, then the query loops as server-side data fetching.

7. 7

   Compare on a preview address

   Check each template against the live site at every breakpoint, including the mobile menu, which on Bricks depends on the Nav (Nestable) toggle. The Bricks mobile menu guide explains that quirk.

8. 8

   Launch and watch

   Move DNS, test redirects in production, submit the sitemap and monitor Search Console.

Stores, images and search equity on a Bricks site

Bricks includes a full WooCommerce builder: product archive, single product, cart, a multistep Checkout v2 and an account builder. Those templates are rebuilt like any others. The store data underneath, products, orders, customers and subscriptions, is the larger task, and the WooCommerce to Next.js guide covers it.

Images hide in two places. Some are in the media library; others are referenced inside element settings, such as section backgrounds, and only show up when you read the post meta arrays. Our script collects both, then the image migration process resizes, renames and describes them. Titles and descriptions come from whichever SEO plugin the site runs. Every URL is kept or redirected following the redirect guide and URL structure guide, and the whole checklist is in migrating without losing SEO.

Licensing, timing and the case for staying

Bricks licensing is friendlier to a migration than most. Per its Terms of Service, after at least one successful, non-refunded yearly payment you may keep using Bricks after you cancel; updates stop. Owners of the $599 Ultimate Lifetime plan have nothing to cancel at all. The caution is the gap: a Bricks site that stops receiving updates is acceptable for a short migration window and a poor idea for a year. Plan details are on our Bricks pricing page.

Timelines follow the structure you have. A site with tidy components and classes moves faster than one styled element by element, and every custom query or Code element adds a little. The timeline guide and cost guide explain the drivers. We quote a fixed price after a free site audit.

Some Bricks sites should stay. If your developer maintains it well and the owner never needs to edit layouts, a Bricks site can be fast and stable; our Bricks speed guide and Bricks developer service exist for that case. Move when the 2.4 release regressions, a builder that will not load or an owner who cannot safely edit the site keep costing time. Then Athena CMS gives that owner plain fields, a real preview and every version kept, while Argus watches links and forms and Atlas flags thin or orphaned pages. Compare first in Bricks vs Next.js, browse the WordPress to Next.js section, or go straight to our Next.js development service.