How to Audit Your Bubble App Before You Commit to a Migration

Before you commit to a migration, you should know what you're migrating. Sounds obvious. In practice, the discovery phase is the most-skipped step of every migration we see done badly.

A real audit isn't "we looked at the app and it seems fine." It's a systematic catalogue of every Data Type, workflow, option set, integration, plugin, page, and reusable element - with each one classified as clean (carries forward as-is), refactor (carries forward with changes), drop (not needed), or AMBIGUOUS (needs a decision before migration).

This article gives you the 50-item checklist we run before quoting any migration at AppSavvy. You can do this yourself before committing to any partner - or before deciding whether to migrate at all.

Why the audit matters

The audit produces three things you can't get any other way:

1. A realistic scope. Without it, the migration price is a guess.
2. The AMBIGUOUS list. These are the things that block migration if you don't decide them upfront.
3. A leverageable artefact. Even if you don't migrate, the audit doc is useful for refactoring, onboarding, or selling the company.

The audit takes 1-2 weeks for a typical mid-stage Bubble app. If anyone offers to migrate your app without one, they're either selling you a rewrite (which will fail) or they're going to discover the scope mid-project (which will fail in a different way).

The 50-item checklist

Data model (12 items)

1. List every Data Type with row count, expected growth, and field count
2. Document every field with type, whether it's used (some never are), and any custom code that reads/writes it
3. Map relationships between types - 1:1, 1:N, N:M, and recursive references
4. Identify soft-deletes disguised as boolean fields
5. Identify duplicate or near-duplicate types that grew from naming drift
6. Identify orphan records - fields pointing at things that don't exist
7. List option sets with their members and any places they're referenced
8. List computed/derived fields that are stored vs. calculated on read
9. Flag denormalised data that's now out of sync between copies
10. Identify time-zone behaviour for Date fields
11. Catalogue file/image fields that store URLs to Bubble's CDN
12. Look for fields that store JSON-in-text (almost always a sign of escape-hatch usage)

Workflows (10 items)

13. Inventory all page workflows - what they do, what they touch, when they fire
14. Inventory all API workflows - scheduled, recursive, triggered
15. Identify recursive workflows still running in production
16. Flag workflows with race conditions (look for "make changes to thing" actions on the same record from multiple workflows)
17. Identify the "everything fix-it" workflow that's been growing for years
18. Map workflow → Data Type dependencies (which workflows touch which types)
19. Find workflows that depend on plugins (they need separate planning)
20. Catalogue workflows that send email (and what email service they use)
21. Catalogue workflows that move money (these need the most testing during migration)
22. Flag any workflows with TODO/FIXME comments as AMBIGUOUS

Pages and reusables (8 items)

23. List every page, with role(s) that can access it
24. List every reusable element and how many times it's used
25. Identify near-duplicate pages (admin vs. user views of the same data, etc.)
26. Identify pages with custom states doing business logic
27. Catalogue conditional formatting that's actually authorisation logic
28. Find pages with embedded HTML/JavaScript
29. List pages that are only reachable by direct URL (no nav)
30. Find pages that should have been deleted (early prototypes, A/B test losers)

Integrations (6 items)

31. List every external API connector with what it does and what it consumes
32. List every webhook receiver - URL, expected payload, what it does
33. Identify integrations that require recurring auth refresh (OAuth tokens, etc.)
34. Find integrations using deprecated APIs of third-party services
35. List every email service used (often there are 2-3 different ones over the app's life)
36. Catalogue payment integrations with all the touchpoints in workflows

Plugins (5 items)

37. List every plugin installed with its publisher and version
38. Identify abandoned plugins (no recent updates, missing publisher)
39. Identify paid plugins with their monthly cost
40. Flag plugins that override standard Bubble behaviour in non-obvious ways
41. Identify plugins doing things that should be done server-side (auth, payment, etc.)

Performance & infra (5 items)

42. Measure current page load times for top 5 pages
43. Measure current database query times in the debugger
44. Get the last 3 months of WU consumption broken down by workflow if possible
45. Identify the slowest workflow and the most-fired workflow
46. Document the current Bubble plan and any capacity boosts

Security & privacy (4 items)

47. List every Data Type's privacy rules - what's exposed via the data API
48. Identify "open" types (privacy rule allows public read)
49. Find fields that should be encrypted but aren't (passwords, SSNs, etc.)
50. Document the auth model - how users log in, how roles work, how reset works

Classifying each item

For every item in the audit, mark it as one of four states:

• CLEAN - migrates as-is. The simpler the data and the logic, the more things land here.
• REFACTOR - migrates with intentional changes (renaming, simplifying, splitting, merging).
• DROP - not migrating. Either it's unused, replaced by a better pattern, or it was a mistake.
• AMBIGUOUS - needs a decision before migration can proceed. The most important category.

The AMBIGUOUS list is the riskiest part of the audit. These are the questions like "this workflow seems to update users wallets twice in some edge case - is that intentional?" or "this Data Type has 2,000 records with a NULL value for the required field - what should happen to them?"

If you don't surface AMBIGUOUS items in discovery, they surface during the build phase as defects, scope creep, and missed deadlines.

Document the audit

For each item, the minimum you need to record:

• Name / identifier
• Brief description of what it does
• Where it's used (links to other items, like "used by Workflow X, Page Y")
• Status (CLEAN / REFACTOR / DROP / AMBIGUOUS)
• Notes / decision needed

The format doesn't matter. A spreadsheet works. A Notion database works. The point is that someone reading the audit document can see, for any feature, exactly what's going to happen to it during migration.

What you should expect to find

Some patterns that show up in nearly every audit:

• 15-25% of Data Types have unused fields that nobody removed
• 5-10% of workflows have never been fired in production (built for a feature that didn't ship)
• 2-3 plugins are doing critical work that should be replaced rather than kept
• At least one "AMBIGUOUS" item that becomes the most important conversation of the migration
• A non-trivial number of soft-deleted records in older Data Types

None of these are red flags. They're normal. They just need to surface during discovery rather than during the build.

When the audit changes your mind about migrating

The audit can also tell you migration isn't the right move yet. The two cases we see most often:

• Your app is much smaller than you thought. If the audit finds 8 Data Types, 30 workflows, and 5 plugins, your app might be three months of refactoring away from running smoothly on Bubble for another two years.
• Your AMBIGUOUS list is huge. Migration is built on knowing what each feature does. If 30% of features are AMBIGUOUS, fix that first - usually through targeted refactoring on Bubble - before considering migration.

We've turned away migrations because the audit told us the client should refactor first. We've also fast-tracked migrations because the audit told us it was overdue.

What to do next

If you'd like us to run this audit for you, it's the first phase of any migration engagement. The output is yours whether you proceed with us or not.

If you'd rather start with a lighter external audit, we offer a free Bubble app audit covering security, performance, maintainability, and migration risk.

Read next: Bubble to Next.js migration guide and Migrating Bubble data to Postgres.