Migrating from Avada & Fusion Builder to ACF blocks

Avada is one of the best-selling WordPress themes of all time, and Fusion Builder is its page builder — a shortcode-based system bundled into the theme, similar in spirit to WPBakery. Agencies rebuilding Avada clients onto bespoke ACF block themes hit the same wall every time: you cannot swap the theme and keep the layouts. Fusion shortcodes stop rendering the moment Avada is gone. The content has to be extracted from what visitors actually see and mapped into your new block library.

What happens when you switch away from Avada

Fusion Builder stores layouts as shortcodes — [fusion_builder_container], [fusion_text], [fusion_imageframe] and dozens more. Change to a theme without Fusion Builder and those shortcodes do not render. Polished pages become walls of raw tags or empty sections. This is the same class of problem as WPBakery and Divi, with Avada-specific element names and option panels.

Why agencies rebuild Avada clients on ACF blocks

• arrow_rightPerformance: Avada ships a large CSS and JS payload even on simple pages.
• arrow_rightBespoke design: the new build uses your block library, not Avada option panels.
• arrow_rightEditor experience: Gutenberg and ACF blocks instead of Fusion's back-end builder.
• arrow_rightLong-term maintenance: no theme update breaking Fusion layouts on inherited sites.
• arrow_rightPortfolio consistency: one block library across clients instead of per-theme skills.

Performance gains pair with rebuild without losing SEO — cleaner HTML often improves Core Web Vitals once builder overhead is removed.

Fusion elements and ACF block mapping

Every Fusion element maps to a block in your library — or to a manual review queue when automation should not guess.

Avada global and off-canvas elements

Fusion Global Elements — sliders, CTA bars, popups, mega menu sections — inject across pages. They may not appear in a single page crawl the way body content does. Audit the old site admin: which globals are active, which pages they attach to, and what must become template parts on the new theme.

• arrow_rightMega menus and sticky headers → rebuild as theme header template part.
• arrow_rightGlobal CTA bars → footer or section template, or a dedicated block in template.
• arrow_rightOff-canvas and slide-in panels → modal or off-canvas component in new theme.
• arrow_rightFusion sliders → hero block, gallery, or custom slider block — rarely a 1:1 import.

Migrating page body into ACF blocks does not replace global chrome. Plan template parts in parallel with page migration.

Step-by-step migration workflow

1. 1Export URL inventory; note Avada demo content vs client-authored pages.
2. 2Build ACF block library on staging; export field groups as JSON — ACF JSON export.
3. 3Crawl live site — rendered Fusion output only, with Avada still active.
4. 4Classify sections; flag fusion_portfolio and fusion_code_block for manual work.
5. 5Review confidence scores; fix low-confidence pages before import.
6. 6Import drafts; sideload images; rewrite internal links.
7. 7Rebuild header, footer and mega menu in new theme template parts.
8. 8Run QA checklist and shortcode cleanup.
9. 9Launch with redirect map and preserved SEO metadata.

Avada-specific pitfalls

Demo content vs real content

Avada imports ship with placeholder copy and stock images clients never updated. Inventory which URLs are live in Analytics before migrating dead weight. Drop or merge thin demo pages rather than paying to migrate them.

Inline styles and Avada classes

Fusion text elements often carry Avada-specific classes and inline spacing. Your ACF block templates should own typography — strip presentation cruft during mapping so the new theme CSS applies cleanly.

Portfolio and custom post types

fusion_portfolio frequently ties to Avada's portfolio post type. Decide early whether case studies become a custom post type, a block repeater, or static archive pages. Do not snapshot dynamic grids as HTML that goes stale.

Volume and timeline

Avada migrations are volume work — 30 to 80 pages is typical on mid-market sites. Manual rebuild at two to three hours per page is weeks of developer time. Automated classification against your ACF export replaces build with review — often one to two days for the same page count. See how long a rebuild takes for phase breakdown.

Run the staging workflow and full migration checklist. Avada decommissioning is a launch event, not a toggle — coordinate DNS, redirects and builder deactivation together.

Fusion Builder Live vs back-end builder

Avada offers both a back-end Fusion Builder and Fusion Builder Live (front-end editing). Neither is your migration source. Both save shortcodes to the database. Your crawl target is always the public permalink — what Googlebot fetches. If a caching layer or CDN optimises HTML, crawl staging that mirrors production caching rules so you do not migrate pre-optimised markup that differs from what editors expect.

WooCommerce on Avada

Avada + WooCommerce sites add product archives, cart fragments and Avada-specific shop layouts. Product URLs and category slugs need explicit redirect rows. Do not migrate shop loops as static HTML — wire live queries on the new theme. Budget ecommerce QA separately from marketing page migration; checkout is a launch blocker.

Handover documentation for editors

After migration, editors need a block-to-block guide: which old Fusion patterns became which ACF blocks, how to edit repeaters, where global CTAs now live in template parts. One hour of editor training prevents six months of support tickets asking why 'the old slider' is now three image blocks in a repeater.

Performance before and after Avada

Document Lighthouse mobile scores on three representative URLs before migration — homepage, a long landing page, a simple text page. Repeat on staging after ACF migration with production-equivalent hosting. Clients understand 'the site feels slow on mobile' when you show screenshots, not DOM depth metrics. Performance improvement is a legitimate rebuild selling point alongside editor experience.

Avada-specific optimisations (lazy load, combined CSS) disappear with the theme — ensure your new theme implements image lazy-loading and critical CSS so you do not trade builder bloat for neglected basics.

Testing Avada migration on staging

Pick five representative URLs for pilot migration before batch processing: homepage, longest landing page, simplest text page, one blog post, one page with fusion_portfolio or tabs. Run full QA on those five — images, links, heading order, mobile — then scale. Avada sites fail in edge elements, not in plain text blocks. Pilot catches fusion_code_block and nested container issues before you import forty pages that share the same wrong mapping.

Licence and support considerations

Avada licences are per-site. During parallel running of old production and new staging, both may need valid licences if client edits continue on Avada. Plan Avada decommission date in writing. Support contracts that covered 'theme updates' do not cover migration — scope migration as separate professional services. If client inherited Avada from a previous agency, confirm demo content licence for stock images before bulk sideloading into new Media Library.

Post-launch Avada decommission

Schedule Avada theme and Fusion Builder plugin removal after launch monitoring week one — not launch hour. Keep a database snapshot with Avada meta for ninety days. Document licence termination if client will not renew Avada support.

Search old database for fusion_ shortcode remnants in post_content after migration — hybrid pages edited post-import may reintroduce shortcodes. Run the shortcode cleanup checklist before declaring migration complete.

Content parity verification

Side-by-side parity checks matter on Avada sites because Fusion hides structure in shortcodes. Open old URL and new draft in two browsers; compare visible headings, images, CTAs and form placements — not pixel-perfect design. Word count within ten percent is a reasonable heuristic for text-heavy pages. Missing sections usually mean a Fusion element mapped to fallback text block — find it in review queue before client sees staging. Video and map embeds need separate checklist items; they often live in fusion_code_block.

Avada migrations benefit from a dedicated redirect review pass on fusion_portfolio archive URLs — they often use custom slugs clients forgot existed.

Summary

Avada migration is crawl rendered Fusion output, map to ACF blocks, rebuild globals as template parts, launch with redirects and SEO preserved. Volume sites need automation plus review — manual Fusion rebuild does not scale past twenty pages on agency margins.

Fusion Builder version differences between Avada releases can change shortcode attributes — note Avada version in project README. If client updates Avada mid-migration, re-crawl affected pages before final import. Global header changes on Avada often require re-crawl of entire site because every page inherits the update.

Working with Avada support and updates

Disable automatic Avada updates on the migration source site during the project window — a Fusion Builder update mid-crawl changes shortcode output and invalidates classification rules you tuned last week.

If client insists on updates, re-crawl only the pages that changed in release notes. Avada changelog is long; most releases do not affect front-end HTML on existing pages, but major Fusion releases can.

Schedule Avada licence cancellation conversation for after handover — client may think they need Avada on new site when they do not.

Pair this guide with the WordPress migration checklist and staging workflow — Avada projects fail in handoff between migration and launch, not in classification alone.

What to read next on this rebuild

Avada Fusion portfolios are a two-layer problem: Fusion shortcodes on archive pages plus CPT entries holding project meta. Migrate both — see CPT migration and Salient migration for similar portfolio patterns. Fusion sites are image-heavy; plan media migration before QA sign-off.