What should a Bubble migration audit include?

A Bubble migration audit should tell you what the app actually does, where the migration risk lives, what can be fixed inside Bubble, and what should move to code. A lightweight review of screens and features will miss the important parts. The audit needs to inspect workflows, backend workflows, data, privacy rules, reusable elements, custom states, option sets, API Connector calls, plugins, files, admin pages, and the rollout plan.

Serious Bubble apps rarely keep the awkward bits in one place. The audit is the bit that stops everyone guessing and makes the system visible enough to decide what stays, what gets cleaned up, and what is worth rebuilding.

What A Bubble Migration Audit Is For

The point of a migration audit is to turn a vague "we should leave Bubble" conversation into a practical decision.

Sometimes the app has genuinely outgrown Bubble. You may need stronger developer tooling, version control, testing, deployment process, backend architecture, infrastructure control, or clearer code ownership.

Sometimes Bubble is taking the blame for an app structure problem. Slow pages may come from loading too much data into repeating groups. Security worries may come from missing or inconsistent privacy rules. Delivery pain may come from tangled workflows, plugin sprawl, unclear naming, or admin processes that only one person understands.

Those are different problems. A good audit separates platform limits from app problems, then recommends the next sensible move: migration, focused Bubble cleanup, or a staged path where Bubble keeps running while the highest-risk modules move to code.

For a broader decision framework, start with the Bubble to code migration guide. If the main question is budget, the Bubble migration cost guide explains why price depends on logic, data, permissions, and rollout risk more than page count.

Bubble Migration Audit Checklist

Audit area	What to inspect	What the audit should answer
Product flows	Signup, onboarding, search, checkout, reporting, fulfilment, messaging, support, cancellation	Which flows create revenue, support load, compliance risk, or customer trust risk?
Page workflows	Button workflows, custom events, conditions, navigation, database changes, emails, API calls	Which visible actions have hidden side effects that must be preserved or redesigned?
Backend workflows	Scheduled workflows, recurring jobs, webhook handlers, bulk operations, delayed actions	Which logic runs away from the page, and what breaks if timing or retries change?
Data model	Data types, fields, list fields, linked records, legacy records, option sets	Which structures represent real product entities, and which are Bubble-era workarounds?
Privacy and permissions	Privacy rules, role fields, organisation membership, admin flags, page conditions	Who should see or change each type of data, and where is access currently enforced?
Reusable elements and state	Reusable element properties, custom states, group variables, URL parameters	Which state is only UI behaviour, and which state affects product logic or permissions?
Integrations	API Connector calls, webhooks, OAuth, Stripe, email, CRM, accounting, automation tools	Which external systems own part of the truth, and which calls need exact behaviour?
Plugins	Plugin actions, plugin-stored data, client-side filtering, file tools, payment tools	Which plugin behaviour must be replaced, removed, or handled differently in code?
Files	User uploads, generated PDFs, private files, imports, exports, contracts, attachments	Who owns each file, who can access it, and how will files move safely?
Admin pages	Internal tools, manual overrides, repair buttons, impersonation, reports, exports	Which operational workflows keep the business running behind the scenes?
Rollout risk	Customer cohorts, parallel running, cutover constraints, QA, rollback thinking	Can migration happen in stages, and how will the team prove each stage works?

A small internal tool may not need weeks of discovery. A live SaaS app with paying users, billing, reporting, files, and admin processes needs more than a demo call and a feature list.

Start With Workflows That Can Hurt The Business

Screens are useful for orientation, but workflows tell you what the product actually does.

A button in Bubble can create records, edit linked Things, schedule backend workflows, call an API, send emails, trigger plugin actions, update custom states, and behave differently depending on conditions. A migration audit needs to trace those actions, especially where they affect money, access, compliance, support, or operational reporting.

The first pass should identify critical workflows: onboarding, billing, checkout, fulfilment, invitations, permissions, approvals, report generation, exports, support actions, cancellation, and anything an admin uses when a customer has a problem.

Backend workflows need their own pass. Scheduled workflows, recurring events, webhook handlers, bulk changes, and delayed actions often carry the logic that makes the app feel automatic. If those behaviours move to code, the new system may need queues, cron jobs, workers, webhook endpoints, retries, logging, and alerting.

The audit should also flag workflows that should change during migration. Some need exact parity because customers rely on the current behaviour. Others only exist because a plugin had a limitation, the old data model was awkward, or the team needed a quick fix during launch week.

Check Data, Privacy Rules, And Files Together

Data migration involves far more than a database export. The useful question is whether the new system can preserve the meaning of the old system.

Bubble data types often mix product concepts, UI shortcuts, admin patches, and historical leftovers. List fields may represent relationships that should become join tables. Option sets may be labels in one place and workflow logic somewhere else. A yes/no field may be part of a permission model even if nobody calls it that.

Privacy rules need to be reviewed alongside the data model. In Bubble, access can be enforced through privacy rules, page conditions, workflow checks, role fields, organisation relationships, admin flags, and sometimes plugin behaviour. A code migration needs a clear access model rather than scattered assumptions copied from the old app.

Files belong in the same conversation. User uploads, generated PDFs, private documents, CSV imports, contracts, and attachments may have access rules and business meaning. The audit should say where files live, how they link to records, who can access them, and how validation will prove they still belong to the right users or organisations.

If data is the scary part of the project, read the Bubble data migration guide before committing to a rebuild. It goes deeper on redesigning the model instead of dragging every Bubble field into the new database.

Inspect Admin Pages And Human Workarounds

Admin pages are often where the real business process lives. The customer-facing product may look clean while the internal team relies on hidden pages to repair records, approve accounts, refund payments, edit files, run exports, change statuses, impersonate users, or patch data after an integration fails.

A migration audit should ask the people who run the business what they actually do each week. Which admin pages do they use? Which buttons are they scared to press? Which reports does finance trust? Which records get manually corrected? Which workflows are handled in Slack, email, Airtable, Zapier, Make, or a spreadsheet because Bubble never got a proper feature?

A public app can appear migratable until you discover the support team depends on three old admin flows and a monthly export that nobody mentioned. If those processes are missing after launch, the migration has pushed the burden onto the team that keeps customers happy.

Review Integrations And Plugin Behaviour

Bubble integrations can hide a surprising amount of behaviour behind friendly editor actions.

The audit should list every important API Connector call, webhook, OAuth flow, payment integration, email provider, CRM sync, accounting connection, automation tool, analytics event, and plugin action. For each one, it should identify the source of truth, what Bubble stores locally, what happens on failure, and which parts need to be rebuilt.

Plugins deserve particular care. Some only handle display or convenience. Others manage payments, files, search, charts, calendars, PDFs, authentication, or complex API behaviour. A plugin might filter data client-side, store state externally, or call an API in a way the Bubble app depends on quietly.

The migration plan should say which plugin behaviours will be replaced with code, moved to a service, removed, or temporarily supported during rollout.

Decide What Can Be Fixed Inside Bubble

A migration audit should be honest about Bubble.

There are cases where moving to code is the right call. There are also cases where a serious Bubble cleanup would solve the immediate pain more cheaply. If the app is slow because pages load too much data, fixing searches and privacy rules may buy real time. If workflows are tangled, documentation and structure may reduce risk before migration starts.

A cleaner Bubble app is easier to run today and easier to migrate later. Better naming, clearer reusable elements, explicit option sets, stronger privacy rules, simpler workflows, and cleaner admin pages all make the source system easier to trust.

The audit should separate three categories:

• fix now inside Bubble because it reduces current risk
• preserve during migration because the business relies on it
• redesign in code because the current Bubble pattern is holding the product back

That split gives the business a path even if the migration is staged, delayed, or narrowed.

Turn The Audit Into A Migration Plan

The final output should be practical enough to guide delivery.

You should come away knowing the critical workflows, risky data areas, permission model, file strategy, integration dependencies, plugin replacements, admin processes, and recommended rollout sequence. The audit should also call out unknowns. Unknowns are fine when they are named. They become expensive when hidden inside a confident estimate.

For live apps, the plan should usually be staged around business risk rather than page order. That might mean starting with reporting, admin tools, onboarding, billing, a specific customer cohort, or a module that has clean boundaries. Each stage should have a validation plan: data checks, permission checks, workflow tests, file checks, integration tests, and a way for the team to compare the new behaviour against the old app.

If the audit shows that migration is sensible, the next step is to design the route from Bubble into the new system without freezing the business. You can see how NQU thinks about that on the migrate to code page.

The useful principle is simple enough: understand the app before promising the migration. The audit should make the hidden parts visible, separate fixable Bubble problems from code-worthy problems, and give the team a migration plan they can actually test.

Questions This Guide Answers

What should a Bubble migration audit include?

It should inspect workflows, data types, privacy rules, integrations, files, admin tools, plugin dependencies, rollout risk, and what should be fixed inside Bubble before anything moves.

Is a Bubble migration audit the same as a feature list?

No. A feature list describes what users can see. A migration audit looks for the hidden behaviour, data assumptions, permissions, and operational workflows that make the product work.

Why audit before estimating a Bubble migration?

A serious estimate needs evidence. Without inspecting the Bubble source, data, workflows, and business-critical edge cases, the scope is usually built on guesses.