AppSavvyBook a call
Canvas (Airdev)

Canvas v5 to v6: Should You Upgrade, Rebuild, or Migrate?

Canvas v5 apps can't upgrade in-place to v6. Here's the honest framework for choosing between rebuilding on v6, staying on v5 with maintenance, or migrating off Canvas entirely.

Will Driscoll9 min read

One of the hardest decisions for Canvas (Airdev's Bubble framework) app owners isn't whether to upgrade - it's that there's no easy upgrade path. Canvas apps on v5 or older can't be upgraded in-place to v6. To use the new Canvas Building Framework template, you have to start over with a new app.

Which means the real choice is more like a fork in the road: rebuild on v6, stay on v5 with active maintenance, or migrate off Canvas entirely. The right answer depends on factors most owners don't know how to evaluate.

This article gives you the framework we use at AppSavvy when Canvas owners ask us "should we upgrade?". The answer is almost never simple.

What the v5 to v6 gap actually is

Canvas v6 introduced a meaningfully different architecture from v5. The big changes:

  • A new Building Framework template instead of the older Canvas Toolkit
  • Updated reusable element library with substantially different conventions
  • Style variable handling that doesn't import from older apps (Bubble's limitation, not Airdev's)
  • Modernised workflow patterns for things like search, modals, and forms
  • Newer plugin conventions for things like access control

The cumulative effect is that an app built on the v5 toolkit and one built on v6 look meaningfully different under the hood, even when they produce identical user-facing behaviour.

Bubble's editor doesn't have a way to "migrate" the v5 abstractions to their v6 equivalents in place. So the v5-to-v6 transition isn't an "upgrade" in the normal software sense - it's a structured rebuild.

The three options

Option A: rebuild on v6

You start a new Bubble app from the v6 Canvas Building Framework template. You re-implement every feature, ideally reusing the data model and as much workflow logic as possible. Then you cut over.

When it's the right choice:

  • The app is small or medium-complexity (under ~100 workflows, under ~25 Data Types)
  • The team has 3-4 months of capacity to dedicate
  • The v6 conventions genuinely solve real problems for your app (style system, plugin updates, etc.)
  • Bubble is still the right long-term platform for the product

When it's the wrong choice:

  • The app is large enough that the rebuild cost approaches a full code migration
  • The team is already shipping at a pace where 3-4 months of feature freeze isn't survivable
  • You're already considering migrating off Canvas - rebuilding on v6 first wastes that work
  • The features that pushed you off v5 aren't actually fixed by v6 (sometimes they're not)

Option B: stay on v5 with active maintenance

The app stays on v5. You invest in keeping it healthy: documenting the codebase, fixing the accumulated tech debt, hardening privacy rules, optimising slow workflows. You don't pursue v6 features.

When it's the right choice:

  • The app is in steady state - it works, it earns, it doesn't need new big features
  • The team's appetite for risk is low (no fundraise pressure, no acquisition track)
  • You have a clear maintenance partner who can keep the app healthy for years
  • The v6 features genuinely don't matter for your roadmap

When it's the wrong choice:

  • You're shipping at a high pace - the v5 ceiling is going to hit you in 12-18 months
  • The app has unfixable architectural debt that v6 doesn't help with
  • Your customers want features that need genuinely modern infrastructure (real-time, AI, multi-tenant complexity)

Option C: migrate off Canvas (and off Bubble)

You don't rebuild on v6. You migrate the app to a modern code stack - typically Next.js + Supabase + Trigger.dev. The Canvas-on-Bubble version gets archived. The new app handles all traffic going forward.

When it's the right choice:

  • The app is large enough that a code migration costs about the same as a v6 rebuild
  • The features you want next are difficult or expensive in Canvas (real performance, complex permissions, AI integration, enterprise compliance)
  • You can hire senior code engineers but struggle to hire Canvas experts
  • The platform risk of Bubble + Canvas (vendor concentration, hiring tax) is now meaningful

When it's the wrong choice:

  • The app is small - code migration is overkill
  • Your team has zero engineering capacity that can absorb a new stack
  • You haven't validated whether Bubble (Canvas or not) is actually the bottleneck

The decision matrix

Here's the rough decision matrix we use when scoring Canvas apps:

Factor Lean rebuild Lean stay on v5 Lean migrate off
App size (workflows / Data Types) Small to medium Small Medium to large
Engineering capacity for 3-4 month effort Yes No Yes
Team comfort with code Optional Not needed Required
Need new features that Canvas can't do Few None Many
Long-term roadmap Bubble continues Bubble continues Bubble exits
Risk appetite Medium Low Medium-high
Budget $40k-150k $20k-60k $80k-250k

No single factor decides the call - it's the combination. Most teams who score "lean rebuild" on size and "lean migrate" on roadmap end up going to a code migration because the long-term direction outweighs the short-term cost.

What the v6 rebuild actually involves

If you decide to rebuild on v6, the work breaks down roughly:

  1. Audit the v5 app to inventory what gets carried forward (similar to a pre-migration audit)
  2. Set up the v6 Canvas Building Framework template in a new Bubble app
  3. Migrate the data model - Data Types, option sets, indexes
  4. Rebuild reusables using the v6 conventions
  5. Rebuild page workflows with the new patterns
  6. Migrate API workflows (which may or may not change between versions)
  7. Update or replace plugins that don't have v6 equivalents
  8. Re-implement custom code escape hatches as needed
  9. Migrate data from v5 app to v6 app via the data API
  10. Cut over - DNS change, v5 archive

For a typical mid-sized Canvas app this is 3-5 months of focused work. The cost depends heavily on how much custom code lives outside the Canvas conventions.

The case for skipping v6 entirely

If you're going to invest 3-5 months in a rebuild anyway, an honest question to ask: would that time and money be better spent on a code migration?

The math often says yes:

  • A v6 rebuild keeps you on Bubble (with all its hidden costs at scale)
  • A code migration to Next.js + Supabase removes those costs and unlocks features that no version of Canvas can deliver
  • The cost difference between v6 rebuild and code migration is often only 50-100% - small compared to the long-term cost difference

This isn't to say v6 is wrong. For some apps it's the right answer. But it's worth doing the comparison instead of defaulting to "v6 = upgrade path = obvious choice."

What to do next

If you'd like a senior engineer (and ex-Airdev veteran) to look at your specific Canvas app and tell you honestly which path is right, book a 30-minute discovery call. We won't try to sell you the most expensive option - sometimes that means recommending you stay on v5 with a maintenance retainer.

If you want a written audit first, our free Bubble app audit covers Canvas-specific signals (version, plugins, framework drift) and gives you a written report.

Read next: The Canvas tech debt audit and Canvas to code: planning a migration path.

Got a Bubble or Canvas app you’d like a second pair of eyes on?

30-minute discovery call. We’ll look at your app live and tell you honestly what we’d do next.

Or grab the Bubble migration playbook PDF.