Migrating a Kadence Site to Brndle: Mapping Kadence Blocks to Brndle’s 20 Native Blocks
Kadence Blocks is installed on 600,000+ WordPress sites for one simple reason: the free plugin alone covers almost every section a marketing or content page needs, and it works on whatever theme you already run. If you’re reading this, you’re probably looking at the other side of that equation – a site built on Kadence Blocks, and a reason to move it to Brndle, the free Sage/Acorn/Blade theme this site maintains. Maybe it’s the Liquid Web bundle pricing, maybe it’s wanting blocks that read your theme’s own design tokens instead of carrying a parallel settings panel, maybe it’s just a rebuild.
Whatever the reason, the question this post answers is narrow and practical: if a page is built from Kadence Blocks today, what does it become in Brndle? Not “is Brndle good” – we covered that ground, with real numbers, in Kadence Blocks vs Spectra vs Brndle’s 20 Native Blocks. This is the migration itself: a block-by-block map, what carries over cleanly, what doesn’t map at all, a step-by-step process, and a time estimate we are not going to round down to make Brndle look better. Say it up front, because the rest of this post depends on you believing it: this is not a one-click conversion. Nobody has built one, for this pair of tools or any other page-builder-to-block-theme move we’ve looked at. Budget a rebuild, not an import.
In this guide
- Two different approaches to the same section library
- The block map: Kadence Blocks → Brndle, block by block
- What doesn’t migrate cleanly
- The migration process, step by step
- A realistic time and effort estimate
- Pre-migration checklist
- Questions about migrating from Kadence Blocks to Brndle
- Should you actually do this?
Two different approaches to the same section library
Kadence Blocks registers its own namespaced blocks (kadence/rowlayout, kadence/infobox, and so on) as a standalone plugin. It works on any theme because it doesn’t depend on any theme: it ships its own color palette, spacing scale, and typography controls, layered on top of whatever theme.json the active theme defines. That’s real, durable value if you run client sites on a mix of themes. It also means every Kadence block carries settings that have nothing to do with Brndle, because Brndle doesn’t have a competing settings panel to carry them to.
Brndle takes the opposite approach. Its 20 blocks (confirmed directly against the resources/views/blocks/ directory in the theme’s GitHub source, which is the number to trust over any README summary) are registered by the theme itself through one BlockServiceProvider class and rendered through Blade views that read the same color presets, font pairs, and CSS variables as every other part of the theme. There is no second plugin to configure, no license to buy, and no settings panel maintaining a parallel palette that can drift from your actual brand color. The cost of that integration is the cost of any theme-native approach: the blocks don’t travel anywhere else, and they don’t have fourteen years of a plugin ecosystem built around them either.
A migration between the two isn’t a format conversion, because the two libraries don’t share a format. A Kadence Row Layout and a Brndle Hero block are unrelated block types with unrelated attribute schemas. What you’re actually doing is reading each Kadence section, deciding what it’s trying to say, and rebuilding that in whichever Brndle block (or native WordPress block) says the same thing. The table below is the map for that decision.
The block map: Kadence Blocks → Brndle, block by block
Kadence Blocks’ free tier ships 24 named block types per its own WordPress.org listing. We mapped every one of them, plus the ten blocks that sit behind the Kadence Pro / Liquid Web bundle, against Brndle’s 20. Three outcomes, marked plainly: a direct match (the Brndle block does the same job with broadly the same inputs), a partial match (a Brndle block gets you most of the way but drops real functionality), or none (nothing in Brndle’s 20 covers it; you either lean on core WordPress blocks or accept the gap).
| Kadence block | Brndle equivalent | Match | What changes |
|---|---|---|---|
| Row Layout | Core Columns / Group | None (use core) | Brndle has no competing grid block. Rebuild the column structure with core Columns or Group, styled by theme.json, not a Brndle block. |
| Section | Core Group | None (use core) | Same story: Brndle doesn’t ship a section wrapper block. Core Group with a background color from the theme palette replaces it. |
| Accordion | brndle/tabs-accordion (accordion mode) | Direct | One Brndle block covers both Kadence’s Accordion and Tabs blocks via a display-mode toggle. Content and item count carry over cleanly. |
| Tabs | brndle/tabs-accordion (tabs mode) | Direct | Same block, tab mode. Nested block content (not just plain text) inside each panel is the one thing worth spot-checking after rebuild. |
| Advanced Button | Core Buttons | None (use core) | No Brndle-specific button block; core Buttons styled from theme.json button tokens does the job without one. |
| Advanced Form | brndle/lead-form | Partial | Brndle’s lead-form is a single-purpose email-capture block with REST submission and Mailchimp integration. Kadence’s Advanced Form supports arbitrary field types, conditional logic, multi-step forms, file uploads, and integrations with ActiveCampaign, Zapier, and others. Anything beyond name/email capture needs a dedicated forms plugin alongside Brndle. |
| Advanced Gallery | Core Gallery or brndle/card-grid | Partial | Core Gallery covers a plain image grid. Neither it nor card-grid replicates Kadence’s lightbox, masonry layout, or filterable categories. |
| Advanced Text | Core Paragraph / Heading | None (use core) | Theme typography tokens apply automatically; no Brndle-specific text block exists or is needed. |
| Countdown | – | None | No countdown timer anywhere in Brndle’s 20. A launch-countdown section needs a custom Blade view with JS, or a small standalone plugin. |
| Count Up | brndle/stats | Partial | Stats displays the same kind of numbers, but statically. Kadence’s animated count-up-on-scroll effect isn’t part of the block. |
| Icon | Theme component, not insertable | None | Brndle has an icon Blade component used inside other blocks, but no standalone, freely-placeable icon block an editor can drop anywhere. |
| Icon List | brndle/how-it-works or brndle/card-grid | Partial | Both give you repeating icon-plus-text items, but in a fixed section shape (numbered steps, or a card grid) rather than a free-form inline list. |
| Info Box | brndle/card-grid or brndle/features | Partial | Conceptually close – icon/image, heading, short text, repeated – but the field options and layout rules differ from Kadence’s Info Box settings panel. |
| Lottie Animation | – | None | No Lottie/JSON animation support anywhere in Brndle. If a page leans on Lottie for a hero animation, that’s a custom build or a plugin. |
| Posts | brndle/post-feed | Direct | Both pull recent posts dynamically into a styled feed. Brndle’s post-feed ships several display styles (per the theme’s block catalog); confirm your layout is one of them. |
| Progress Bar | – | None | No progress-bar visualization in any of the 20 blocks. Skills/stats bars need a custom Blade view. |
| Show More | – | None | No collapsible “read more” content wrapper. The closest conceptual neighbor, tabs-accordion, is built for distinct labeled sections, not a single block of truncated text. |
| Spacer / Divider | Core Spacer / Separator | None (use core) | Native WordPress blocks already do this; no theme-specific version needed. |
| Table of Contents | – | None | No auto-generated, heading-aware TOC block. This article’s own table of contents above is a hand-built list for exactly that reason. |
| Testimonials | brndle/testimonials | Direct | Avatar, name, role, quote, and (per the theme’s catalog) a star rating field all carry across with a straight content copy. |
| Vector Illustration | – | None | Kadence’s illustration picker/library has no counterpart. Static images via core Image fill the gap, without the illustration set. |
| Advanced Navigation | Core Navigation | None (use core) | Not a landing-page block in either library; core Navigation, themed via theme.json, is the real replacement either way. |
| Advanced Search | Core Search | None (use core) | Same logic as Navigation above. |
| Advanced Table | Core Table or brndle/comparison-table | Partial | For a plain data table, core Table. For a feature-comparison grid specifically (checkmarks, a highlighted plan column), comparison-table is the closer, purpose-built match. |
That covers Kadence Blocks’ free tier. The ten blocks and features behind Kadence Pro / the Liquid Web bundle map like this:
| Kadence Pro block | Brndle equivalent | Match | What changes |
|---|---|---|---|
| Advanced Query Loop | brndle/post-feed | Partial | Post-feed pulls posts dynamically but with fixed display styles. Kadence’s fully configurable taxonomy/custom-post-type filtering and per-item template control has no equivalent. |
| Advanced Slider | – | None | No slider block in Brndle at all, free or otherwise. |
| Image Overlay | – | None | content-image-split places an image beside text, but nothing in Brndle does a hover/click overlay effect on an image. |
| Modal / Popup | – | None | No modal or popup block. This is a real gap if the Kadence site uses a popup for lead capture or promotions – plan on a small plugin for that specifically. |
| Post / Product Carousel | brndle/post-feed | Partial | Same posts, no carousel motion. It renders as a static feed, not a swipeable/sliding one. |
| Repeater | – | None | Kadence’s general-purpose repeating-field block has no analogue; Brndle’s repeating content lives inside specific blocks (team, logos, card-grid), not as an open-ended container. |
| Split Content | brndle/content-image-split | Direct | Genuinely the closest match in this whole table – both are a side-by-side text/media layout block, functionally equivalent despite the different name. |
| Video Popup | brndle/video-embed | Partial | Video-embed wraps YouTube, Vimeo, or self-hosted video inline on the page. Kadence’s popup-on-click behavior (a thumbnail that opens a modal player) isn’t part of it. |
| Animate on Scroll | – | None | No block-level scroll-reveal toggle exposed anywhere in Brndle’s 20. If motion-on-scroll matters to the brief, it’s a custom CSS/JS addition, not a setting. |
| 800+ pattern Design Library | – | None | Brndle has no pattern library beyond the 20 blocks themselves. There’s nothing to drop in and edit; every section is built from the block’s own fields. |
Add it up and the honest count is this: of Kadence Blocks’ 24 free block types, six are direct or near-direct matches in Brndle (Accordion, Tabs, Posts, Testimonials, plus Split Content and Video Popup from the Pro side), seven are better served by native WordPress blocks than by anything Brndle-specific, and the remaining eleven, plus most of the Kadence Pro tier, have no equivalent at all. That last number is the one to sit with before committing to this move.
What doesn’t migrate cleanly
Three categories of loss show up in almost every real Kadence-to-Brndle migration, and none of them are about the block markup itself.
Settings that live in a Kadence panel and nowhere else. Kadence blocks carry per-block responsive visibility controls, custom CSS fields, animation triggers, and conditional display rules in their own settings tabs. None of that data has anywhere to go in a Brndle block, because Brndle blocks don’t expose those controls. If a page depends on “hide this row below 768px” or “fade in this box on scroll,” that behavior needs to be rebuilt by hand – in theme.json breakpoints, in a utility class, or it gets dropped.
Functionality with no Brndle block at all. The table above marks fourteen Kadence features – Countdown, Lottie Animation, Progress Bar, Show More, Table of Contents, Vector Illustration, Advanced Slider, Image Overlay, Modal, Repeater, Animate on Scroll, and the 800+ pattern library among them – with no Brndle equivalent, full stop. If your Kadence site leans on any of these for anything load-bearing (a countdown-driven launch page, a modal lead-capture flow), the honest options are: write a custom Blade view and register it as a 21st block, bring in a small single-purpose plugin alongside Brndle, or accept the section doesn’t make the move.
Design-token drift that Kadence blocks never had to resolve. This cuts the other way and it’s worth stating plainly: Kadence blocks carry their own color and spacing panel independent of the active theme, which means a Kadence Row Layout on the old site might be using a hand-picked hex value that has no corresponding token in Brndle’s theme.json palette. Rebuilding that section in a Brndle block forces a decision – either add the color to the palette (via the brndle/color_presets filter) or accept the section’s look shifts slightly to match the theme’s actual tokens. That’s a feature of theme-native blocks, not a bug, but it is real work during the migration, not after it.
What does move without friction: post and page text, images (through standard WordPress export/import), products and taxonomy data if WooCommerce is involved, and anything that was never a Kadence block to begin with – core Paragraph, Heading, Image, List, and Quote blocks carry straight across untouched. The layout wrapping that content is what gets rebuilt.
The migration process, step by step
- Inventory every Kadence block in use, by type and by count. Don’t estimate this from memory. Export the site’s content and grep the post content for
wp:kadence/block comments, or check each page in the block editor’s list view, which shows every block instance by name. You want a table: block type, number of instances, number of distinct pages it appears on. This is the single most important step, because it’s what turns the estimate below from a guess into a plan. - Cross-reference the inventory against the mapping table above. Sort into three buckets: direct/partial matches (rebuild in the Brndle equivalent), core-block replacements (Row Layout, Section, Advanced Button, Advanced Text, Spacer, Navigation, Search – these become native WordPress blocks, not Brndle ones), and true gaps (Countdown, Modal, Lottie, and the rest of the “None” rows). The gap bucket is where you decide, per section, whether to write a custom Blade view, bring in a small plugin, or cut the section.
- Stand up Brndle on a staging copy and install it, not the live site. This is a theme switch, and theme switches on a site with real traffic should never happen live first. Clone the site, activate Brndle on the clone, and do all of the following work there.
- Rebuild the shell first: theme.json palette, header, footer, navigation. Pull your actual brand colors and fonts into Brndle’s
theme.jsonsettings (via the Customizer or the filter hooks directly) before touching any content page. Every block you rebuild next reads from this, so getting it wrong here means revisiting every page later. - Rebuild pages in order of traffic, not in file order. Pull your top ten pages by analytics and start there. Each page: identify its Kadence sections top to bottom, replace each with its mapped Brndle block (or core block, or custom build) using the real copy and images from the original, and compare side by side against the live page before moving to the next.
- Handle the gap sections deliberately, not as an afterthought. If step 2 flagged a Countdown block or a Modal popup, decide now: custom Blade view (if you or a developer is comfortable in Brndle’s stack), a lightweight plugin installed alongside Brndle, or drop the section. Don’t discover this mid-rebuild on page six.
- Test every rebuilt page at the breakpoints that mattered on the old site. Kadence’s per-block responsive visibility settings don’t carry over (see the section above), so anything that was conditionally hidden on mobile needs an explicit check, not an assumption that it still behaves the same way.
- Run a link and asset check against the live site’s URL list before cutover. Same discipline as any theme migration: a list of top URLs, a status-code check against each one on staging, and a second pass after cutover to confirm nothing changed.
- Cut over on a quiet window, and keep Kadence Blocks installed (deactivated) for a few weeks. If something surfaces post-launch that the inventory missed, you want the ability to compare against the original block markup without restoring from a backup.
A realistic time and effort estimate
The honest answer to “how long will this take” is: it depends entirely on how many distinct section layouts the site actually has, not how many pages. A 40-page site built from eight repeated Kadence section patterns rebuilds faster than an 8-page site where every page is a bespoke Row Layout arrangement. Use the inventory from step 1 to find your real number, then work from this table rather than a flat per-page estimate.
| Scope | Realistic estimate | Why |
|---|---|---|
| Theme.json palette + header/footer/nav shell | 3–6 hours | One-time setup; everything else depends on getting this right first. |
| Per distinct section layout that has a direct or partial Brndle match (Accordion, Tabs, Testimonials, Posts, Split Content, Video, Info Box, Advanced Table) | 30–90 minutes each | Mostly content re-entry into the new block’s fields, plus spot-checking what setting didn’t carry over. |
| Per distinct section layout replaced by a core WordPress block (Row Layout, Section, Button, Text, Spacer) | 20–45 minutes each | Simpler swap, but still manual – there’s no bulk “convert Row Layout to Columns” tool. |
| Per distinct section layout with no Brndle equivalent (Countdown, Modal, Slider, Lottie, Progress Bar, and the rest) | 2–8+ hours each | Custom Blade view and block registration, or plugin evaluation and integration. Wide range because it depends entirely on the complexity of the thing being rebuilt. |
| QA pass per rebuilt page (breakpoints, links, visual comparison) | 15–30 minutes per page | Non-negotiable, not optional overhead – this is where regressions get caught before launch, not after. |
Put concrete numbers on it: a mid-sized marketing site with 15 pages, built from roughly 10 distinct section patterns, 6 of which have a direct or partial Brndle match and 2 of which are true gaps needing a custom build, lands somewhere around 25–40 hours of focused work from inventory to cutover. A larger site, or one leaning heavily on Kadence Pro features (sliders, modals, the pattern library), moves well past that. Nobody should go into this budgeting a weekend.
Pre-migration checklist
- Full backup of the live site (database and files) taken and verified restorable, before any staging work begins.
- Complete Kadence block inventory: block type, instance count, and which pages use it – not an estimate.
- Every instance cross-referenced against the mapping table above and sorted into direct/partial, core-block, or gap.
- A decision made, in writing, for every gap-bucket section: custom build, plugin, or cut. Not deferred to “figure it out during the rebuild.”
- Brand colors and font pairs pulled out of Kadence’s panels and written down as a starting
theme.jsonpalette, named by role (brand, ink, surface), not by hex shade. - Top-ten pages by analytics identified, so the rebuild order matches what actually matters to visitors and search engines.
- A list of the site’s top URLs saved, for a before/after status-code check.
- Staging environment cloned from production, with outgoing email disabled on the clone.
- Any plugin that hooks into Kadence-specific markup or shortcodes identified and checked for Brndle compatibility.
- A rollback plan: Kadence Blocks and the old theme stay installed and inactive for a defined window after cutover, not removed on day one.
Questions about migrating from Kadence Blocks to Brndle
Is there an automatic converter from Kadence Blocks to Brndle?
No. Nothing in Brndle’s source or documentation does automatic block conversion, and we found no third-party tool that does it either. Text and images move through standard WordPress export/import; section layout is rebuilt by hand, block by block, the same situation as any migration between unrelated block libraries.
What percentage of a typical Kadence site actually converts to Brndle?
It depends entirely on which Kadence blocks the site actually uses, which is why the inventory step matters more than any single number. Going purely by block type: 6 of Kadence’s 24 free blocks have a direct or close Brndle match, 7 are better handled with core WordPress blocks than anything theme-specific, and the remaining 11, plus most of the Pro tier, have no equivalent. A site built mostly from Accordion, Tabs, Testimonials, and Posts converts smoothly. A site leaning on Sliders, Modals, and the 800+ pattern Design Library does not.
Should I rebuild everything in Brndle’s 20 blocks, or mix in core WordPress blocks?
Mix in core blocks deliberately. Seven Kadence blocks in the mapping table (Row Layout, Section, Advanced Button, Advanced Text, Spacer/Divider, Advanced Navigation, Advanced Search) map better to native WordPress blocks styled by theme.json than to anything Brndle-specific, because Brndle doesn’t duplicate functionality core WordPress already provides. Trying to force those into one of the 20 blocks adds work for no benefit.
What happens to Kadence block settings that don’t exist in Brndle, like custom CSS or conditional visibility?
They don’t transfer, because the receiving block has no field for them. Per-block responsive visibility, custom CSS fields, and animation triggers set inside a Kadence block’s settings panel need to be rebuilt separately – in theme.json breakpoints, a utility class, or accepted as dropped functionality. This is the most commonly missed category in a rush migration, since it’s invisible until you test at the breakpoint where it mattered.
Can I run Kadence Blocks and Brndle’s native blocks on the same site at the same time?
Yes, technically. Kadence Blocks is a standalone plugin and will install and function on Brndle like any other block theme, since both register ordinary Gutenberg blocks. Some teams do exactly this during a phased migration – running both while pages are rebuilt one at a time. The tradeoff: pages still using Kadence blocks don’t get the theme-token integration that’s part of Brndle’s pitch, and you’re carrying both the plugin’s CSS and the theme’s until the migration finishes.
What about Kadence Blocks Pro features specifically – the Advanced Query Loop, sliders, and the pattern library?
This is where the gap is widest. Advanced Query Loop has a partial match in brndle/post-feed (dynamic, but fixed display styles instead of fully configurable filtering). Advanced Slider, Modal, Image Overlay, Repeater, Animate on Scroll, and the 800+ pattern Design Library have no Brndle equivalent at all. If the site depends heavily on Kadence Pro, budget significantly more custom-build time, or reconsider whether this migration is the right move at all – see the conclusion below.
Do I need to know Laravel or Blade to do this migration?
Not for the blocks that already exist. Composing a page from Brndle’s 20 blocks works the same no-code way Kadence Blocks does, in the native block editor. You only need Blade/PHP comfort for the gap sections – writing a 21st custom block for something like a countdown timer or a modal, which is the same “developer-required” line any Sage-based theme draws for custom functionality.
Will the migrated site look identical to the Kadence version?
No, and don’t aim for pixel-identical. Brndle blocks read the theme’s own design tokens rather than carrying Kadence’s independent color and spacing panel, so even a direct content match (testimonials, for instance) will render with Brndle’s spacing and type scale, not Kadence’s. Treat this as a redesign within a consistent system, not a reskin that preserves every pixel.
How is this different from migrating off a page builder like Elementor or Flatsome?
The mechanics are the same – inventory, map, rebuild, test, cut over – but the starting point is better. Elementor and Flatsome’s UX Builder store layout as proprietary markup (shortcodes or a JSON tree) that renders as broken text the moment the plugin or theme that registers it is gone. Kadence Blocks and Brndle are both standard Gutenberg blocks, so at minimum the block editor itself keeps working and content stays editable throughout, even mid-migration. We cover the shortcode-specific risk in Page Builder to Block Theme: What Converts, What You Rebuild and Flatsome Theme in 2026.
Is this migration worth it if my site barely uses any of the 11 Kadence blocks with no Brndle match?
That’s precisely the question the inventory step is designed to answer before you commit. If your site’s Kadence usage clusters around Accordion, Tabs, Testimonials, Posts, and Info Box-style content, the match is strong and the rebuild is a reasonable project. If it leans on Sliders, Modals, Countdown, or the pattern library, you’re signing up for a meaningful amount of custom development to close real gaps – worth doing if the reasons for leaving Kadence (cost, lock-in, wanting theme-native blocks) outweigh that cost, not worth it if they don’t.
Should you actually do this?
If your Kadence site is built mostly from the blocks that map directly or close to it – Accordion, Tabs, Testimonials, Posts, Split Content, basic Info Boxes – this is a reasonable, well-scoped rebuild, and the payoff is real: 20 blocks that read your theme’s own tokens, no plugin to maintain, no license to renew, ever. If it leans on Kadence Pro’s sliders, modals, dynamic query loops, or the 800+ pattern library, be honest with yourself about the gap before you start: those sections need custom Blade views or a supplementary plugin, not a Brndle block that doesn’t exist yet.
Either way, start with the inventory, not the rebuild. Count what you actually have before estimating what it costs to move. Brndle’s source and release zip are free on GitHub, so you can install it on a staging clone and test the mapping table above against your own real pages before committing to anything on the live site. And if the brief turns out to need a 21st block Brndle doesn’t ship, our walkthrough on registering a custom Brndle block covers exactly that path, end to end.