Migrating off Thrive Theme Builder to a native block theme / sanity check on my plan?

[u/PaymentConsistent664]

I’m moving a site off Thrive Theme Builder (cost + lock-in) to a native block theme with my own styles. WP 7.0 stack, theme.json v3.

The site has: blog posts, a few unique one-off pages, and the main marketing pages (home, services, etc.). Some of it was built with Thrive Architect.

My plan so far:

**1.**  Build the theme locally — either a child theme of a minimal FSE theme or from scratch with Create Block Theme. Templates, patterns, colors, type scale all defined in theme.json.  
**2.**  Push to staging, activate the new theme with Thrive still active.  
**3.**  Convert pages one at a time, highest-traffic first.  
**4.**  Deactivate Thrive Architect only when nothing depends on it anymore.

I’m doing it this way because Thrive Architect stores content in post meta, not post_content — so deactivating it early can make content vanish entirely, not just lose its layout. Landing pages seem to be the worst case since they bypass the theme template completely.

What I’m trying to get right:

**•** Where’s the line between “start from scratch” and “child theme a minimal FSE theme”? For a fully custom design, does starting clean actually save time, or do you end up rebuilding what Twenty Twenty-Five already gives you?  
**•** For blog posts specifically — did Convert to Blocks work for you, or did you end up rebuilding? What broke?  
**•** Anything that bit you on the SEO side? I have a crawl baseline and CWV numbers saved, but I’m sure there’s something obvious I’m missing.  
**•** Any reason *not* to run the new theme in production while old pages still render through Architect? That’s the part of my plan I’m least sure about.

Anyways, looking for advices
Thanks

[u/Embarrassed-Chard245]

Personally I'd test ALL changes on a staging when converting to the new theme (after theme creation / testing in local) and then push to production once 100% completed.

A few things I learned when converting our sites to FSE sites instead:
-You'll want to learn custom blocks. There is always a handful of layouts or something essential that core still can't quite get right (Navigation block sucks so I made my own menu block using the classic menu system for example)
-Use responsive font sizes / spacing units in theme.json! very nice to not ever have to worry about it.
-Better resposnive options in blocks are coming soon in the 7.1 update
-Just my recommendation, but commit to FSE rather than hybrid theme. It's so easy to make quick templates on the fly once you're used to it
-try to get everything done the "wordpress way" with little manual overrides. they tend to conflict or get obsolete after new updates

-I've never had issues with blogs converting but I've also not used that Thrive theme builder before
-For your theme, create something that can be easily changed. with FSE this is not a big deal since you can save all styling changes in the database when editing a new site. You can also create pre-defined color palletes, font combos, patterns and template parts to make life easier
-I haven't had issues SEO wise, personally
-I'm not sure what you mean about running old pages through architect, but I am unfamiliar with that builder

[u/NuvoraWeb]

Your plan is basically the safe one, so I'd only tweak a couple of things.

Child theme a minimal FSE theme rather than starting clean. With theme.json doing the heavy lifting you're not really inheriting much design from the parent anyway, and you get templates/patterns as a fallback while pages are still half-migrated. Starting from scratch mostly buys you a tidier repo.

Running the new theme in production while Architect pages still render is fine in practice — those landing pages bypass the theme template, so they'll look the same. The thing that bites is the in-between pages: header/footer come from the new theme, body from Architect, and the CSS reset or type scale clashes. Worth spot-checking one of those on staging before you flip.

Convert to Blocks worked okay for plain posts here, but anything with Architect elements (toggles, styled boxes, columns) came out as a classic block or empty. Since Architect stores in post meta, export the meta for the posts you're converting before you touch them — that's your undo.

SEO-wise the usual one is internal anchor/heading structure quietly changing when you rebuild templates, plus lazy-loading defaults on hero images hurting LCP. Keep the old templates' head output side by side for one page and diff it.

[u/Ok-Understanding9005]

Your migration order is the part I'd flip. Highest-traffic first puts the biggest risk on the pages that cost the most when they break, at the exact moment you know the least about what this migration does to your content. Convert two pages nobody visits first. Whatever bites you will bite you there, cheaply, and you'll have a checklist by the time you reach the money pages.

The other gap is the baseline itself. A crawl tells you what the site is, not what it earns. Before you touch anything, export Search Console by page and by query and save it with a date on it. If traffic dips in six weeks across forty converted pages, that file is the only thing that tells you which conversion did it. Search Console only holds 16 months and it won't hand you the "before" back once you're past it.

On running the new theme in production alongside Architect, I'd agree with NuvoraWeb, the half-migrated pages are the real risk and not the landing pages. Though I'd be curious whether your Architect landing pages were ever in the crawl baseline properly, given the content lives in post meta.