What to test before switching users over in a Bubble migration

QA for a Bubble migration is the evidence that the new system behaves like the old business where it matters, and behaves differently only where you deliberately chose to improve it.

That distinction is important. A migrated app can look close, load quickly, and still be wrong in ways that hurt users: invoices not created, permissions too loose, admin fixes missing, webhooks ignored, files exposed, reports off by a few percent, or a support workflow quietly dropped because nobody thought of it as a feature.

A migration is ready when important business behaviours are proven. Visual QA matters, but the dangerous parts usually live in workflows, data, privacy rules, billing, integrations, admin habits, and awkward edge cases.

If you are already worried about the wider failure modes, start with the broader Bubble migration risks. This piece is about the QA layer: what to test before switching users over.

QA starts with old versus new behaviour

The useful baseline is not "does the new app work?" That question is too vague.

The better question is: for the behaviours the business depends on, does the new app produce the same correct outcome as the Bubble app?

That means testing side by side. Pick a real flow in Bubble, run it with known inputs, record the important outcome, then run the same flow in the new app. Compare the created records, changed fields, emails, external API calls, permissions, billing state, file access, and user-facing result.

For example, "invite a team member" may sound simple. In Bubble it might create a user, create or update an organisation membership, assign a role, send an email, schedule a reminder, add an activity log entry, expose a dashboard, and trigger an admin notification. If the new app only sends the invite email and creates the user, the visible screen may pass while the business behaviour fails.

This is why workflow mapping matters before QA. If the team has not translated Bubble workflows into clear code responsibilities, QA becomes guesswork. The test plan should come from the same evidence used to map Bubble workflows to code: triggers, inputs, permission checks, data changes, side effects, delayed jobs, and failure behaviour.

Data reconciliation is more than record counts

Record counts are useful, but they are a low bar.

If Bubble has 42,000 users and the new database has 42,000 users, that proves an import happened. It does not prove relationships are correct, plan access is right, old records are linked to the right accounts, archived things stayed archived, or support history still makes sense.

Good migration QA reconciles the data at several levels. Start with counts per data type or table. Then check relationships: users to organisations, organisations to subscriptions, orders to payments, files to records, messages to threads, bookings to availability, whatever the app actually manages. Then check derived values and reports against Bubble, especially where the old app used saved fields, scheduled workflows, or plugin state.

This is closely tied to Bubble data migration. If the new system deliberately changes the data model, the QA plan needs to compare business meaning rather than old field names alone. A Bubble list field might become a join table. A set of yes/no fields might become a lifecycle state. A plugin-owned value might become an external reference. That is fine, but the reconciliation needs to prove the new shape still represents the same business facts.

Keep Bubble unique IDs as migration references where useful. They make it much easier to trace one old record to one new record when a client says, "This customer has the wrong access" or "This invoice disappeared." The new system can move past Bubble's shape over time. QA still needs a reliable audit trail.

Permission tests need real roles and awkward records

Permissions are one of the easiest places to get false confidence.

In Bubble, access control may be spread across privacy rules, page redirects, conditional visibility, "only when" workflow checks, role fields, organisation fields, admin flags, and plugin behaviour. A code migration should normally move the real security boundary to the backend, but QA still needs to prove the old access model has been preserved or intentionally changed.

Test beyond happy-path users. Check owners, admins, managers, staff, customers, invited users, suspended users, users with no organisation, users in multiple organisations, expired users, test accounts, and support accounts. If the app is multi-tenant, test records from two different organisations side by side and try to cross the boundary.

The important checks go beyond "can this user see the page?" You also need "can this user fetch the data directly?", "can this user change a record they should only view?", "can this user perform an admin action by calling the endpoint?", and "does a hidden button correspond to a real server-side denial?"

This is where old Bubble privacy rules are source evidence. They tell you what the app was trying to protect. They may also reveal old shortcuts that should not be copied. QA should catch both.

Billing, admin workflows, integrations, and files

The high-risk flows are often the least glamorous.

Billing QA needs its own test set. Trial starts, plan changes, failed payments, renewals, cancellations, refunds, coupons, invoices, tax behaviour, customer portal access, webhook handling, and subscription status changes all need to be tested against the provider. Stripe or another billing system may be the source of truth, so the new app has to handle provider events correctly rather than just display a copied Bubble field.

Admin workflows need the same respect. Mature Bubble apps often have internal buttons that fix data, approve users, resend emails, change ownership, issue credits, trigger exports, impersonate users, or clean up broken states. They can look scrappy, but they are often how the business actually runs. If those tools disappear during migration, support cost goes up immediately.

Integrations need provider-level tests. API Connector calls and plugin actions often hide mapping details, retries, rate limits, webhooks, and weird provider responses. QA should verify both directions: what the new app sends out, and how it handles events coming back in. Idempotency matters here. A webhook delivered twice should not create two subscriptions, send two refunds, or duplicate a critical record.

Files deserve their own pass too. Bubble file fields can be deceptively simple. The new app needs to prove that files migrated, previews work, downloads work, private files are private, old links are handled, and users cannot access files attached to records they should not see.

Migration QA checklist

Use this as a practical starting point before switching users over:

• Compare old and new behaviour for the flows that create, edit, delete, charge, invite, approve, publish, export, or expose data.
• Reconcile record counts, relationships, derived values, reports, and sample records across Bubble and the new database.
• Test permissions with real roles, edge-case users, multi-tenant records, admin accounts, suspended users, and direct backend calls.
• Check billing flows for trials, upgrades, downgrades, renewals, failed payments, cancellations, refunds, invoices, coupons, and webhooks.
• Test admin workflows that support, operations, finance, or founders use to keep the business moving.
• Verify integrations by checking outbound requests, inbound webhooks, retries, error handling, logging, idempotency, and provider-owned state.
• Confirm files migrated correctly, render where needed, remain private where needed, and link to the right records.
• Test emails, notifications, scheduled jobs, background jobs, and delayed workflows with realistic timing.
• Run browser QA for the main user journeys on the devices and browsers the customer base actually uses.
• Check analytics, audit logs, activity feeds, exports, and reports that teams use to make operational decisions.
• Define launch blockers, acceptable known issues, and manual workarounds.
• Prepare rollback or pause criteria before launch day, not while users are already stuck.

The checklist should be shorter for a simple internal tool and much deeper for a revenue-critical SaaS app. The point is not to test everything equally. The point is to test the behaviours that would actually hurt if they broke.

Staged rollout makes QA more honest

Big-bang launches create bad incentives. Everyone wants the test pass to be clean because the launch date is close, the old app is still running, and nobody wants to reopen architecture questions.

A staged rollout gives you better evidence. Move one module, one customer cohort, one internal team, one admin workflow, or one reporting surface first. Validate it against real data and real users. Keep the Bubble app available while the new system proves itself in a controlled slice.

That is the logic behind a staged Bubble migration. It does not remove the need for QA. It makes QA less theatrical: prove smaller parts under real conditions, then use what you learn before widening the rollout.

Staging also helps with rollback thinking. A rollback plan needs more than "turn Bubble back on." You need to know what happens to records created in the new app, provider events received during the test window, files uploaded by users, emails sent, payments processed, and admin changes made after the switch. Some flows can roll back cleanly. Some need a pause plan. Some need a one-way cutover because reconciling both systems would be worse.

QA should make those constraints visible before launch.

When the migration is actually ready

The new app is not ready because every page has been recreated. It is ready when the important business behaviours have been tested, the known differences are intentional, and the team understands what will happen if something goes wrong.

That usually means the riskiest workflows have old/new comparison evidence. Data reconciliation has been reviewed by someone who understands the business rather than the schema alone. Permissions have been tested from hostile angles. Billing and integrations have been tested with provider events. Admin users can still do the operational work they need to do. Files are accessible to the right people and hidden from the wrong ones. Rollback or pause decisions are written down.

There will still be bugs. That is normal. The useful question is whether the remaining bugs are ordinary product bugs or migration-risk bugs. A typo in a settings page is annoying. A user seeing another customer's records is a launch blocker. A renewal webhook failing silently is another.

If you are planning a serious Bubble migration, QA should be designed at the same time as the migration plan, not bolted on at the end. Our migrate to code work starts from that assumption: understand the app, map the risky behaviour, decide what moves when, and prove the new system before asking users to trust it.

Questions This Guide Answers

What should QA include for a Bubble migration?

QA should cover user journeys, data reconciliation, permissions, billing, integrations, files, admin workflows, scheduled actions, notifications, audit trails, and rollback behaviour.

How do you test migrated Bubble data?

Compare record counts, relationships, important statuses, files, permissions, reports, billing state, and workflow outcomes between Bubble and the new system.

When is a Bubble migration ready for users?

It is ready when critical journeys pass, migrated data has been reconciled, permissions are verified, support workflows work, observability is in place, and the rollout plan has a fallback.