Bubble Migration Handover Checklist: What You Should Own and Be Able to Run

This handover checklist is for founders and technical leads accepting a rebuilt Bubble app. Use it to agree evidence before the final review: who controls each account, what can be reproduced, and which parts of Bubble still have a job to do. It complements the broader migration process rather than replacing product acceptance testing.

The handover checklist at a glance

• Business-controlled accounts and documented recovery access.
• A fresh-checkout build completed by the receiving engineer.
• A staging deployment traced to a reviewed commit.
• A critical workflow tested with safe test data.
• A restore and application recovery demonstration.
• An owner and retirement condition for remaining Bubble dependencies.
• Explicit acceptance of exceptions and support responsibilities.

1. Separate code ownership from the ability to operate the app

There are three different questions to answer. Your agreement defines rights to the custom work and any exclusions. Your account setup determines who can administer repositories, infrastructure and providers. Your handover evidence shows whether another engineer can actually maintain the product.

An invitation can answer only part of the second question. Ask for an ownership register covering the repository, hosting, database, file storage, domain registrar and DNS, authentication, email, payments, scheduled jobs, monitoring and analytics. Include retained Bubble resources too.

For each resource, record the account or organization, business owner, technical operator, billing owner, recovery contact, access level and a link to the relevant runbook. Record where secrets are managed, never the secret values. Mark anything still owned by the supplier as an explicit exception with an agreed next step.

Keep third-party dependencies visible. Owning your application code does not mean owning a payment provider, licensed component or open-source package. Preserve license notices and document services that remain necessary to run the app.

2. Accept the repository as a working release, not a download

The receiving engineer should be able to identify the commit running in production and reproduce a build from a fresh checkout. Ask for the source, dependency lockfiles, runtime requirements, database migration files, deployment configuration, automated tests and a short setup guide. A runbook is the operating or recovery guide an engineer follows to perform a repeatable task. Include separate repositories if infrastructure or background workers live elsewhere.

Use a clean environment for the handover demonstration. Install dependencies from the documented files, configure non-production access, run the tests and start the app. Record missing steps as handover gaps instead of solving them through private messages that the next engineer cannot find.

Use test recipients and sandbox integrations, restrict access to restored data, and prevent test workers from sending production emails, payment requests or webhooks.

If a repository changes owners, review permissions and integrations afterward. GitHub documents that webhooks, secrets and deploy keys remain associated with a transferred repository. A transfer is therefore not an access cleanup or credential rotation. Agree how to retire unnecessary access without breaking deployments or service integrations.

3. Prove deployment and recovery under your accounts

Ask the receiving engineer to deploy a small, harmless change to staging through the intended pipeline. The evidence should connect a reviewed commit, a successful build and the running release. Confirm who can approve production deployment and who receives failed-build alerts.

Treat hosting, DNS and provider setup as separate items. Moving a Git repository does not move all of them. Provider transfer rules also differ: Vercel documents exceptions and separate handling for some project resources. Review the current transfer checklist for the actual services you use instead of assuming every resource follows the app.

Recovery needs its own demonstration. Can the receiving team restore the previous application release in staging? What happens if the release also changed the database schema or wrote new records? Reverting code does not reverse those changes. Record the supported recovery procedure, compatibility constraints and who decides whether to roll back or fix forward.

Do not run a destructive production recovery drill just to tick a box. Use an isolated environment and agree any production exercise separately. The result you need is a tested procedure with boundaries, not a promise of zero downtime.

4. Hand over data recovery as well as migrated data

Migration acceptance asks whether records, relationships, files and permissions arrived correctly. Ongoing recovery asks whether your team can restore them later. Keep both results in the handover pack; the Bubble data migration checklist covers the first question in more detail.

For recovery, record what each backup contains, where it lives, its retention, who can access it and the last successful restore exercise. Include file storage and required account configuration rather than treating a database export as a copy of the whole product.

PostgreSQL’s SQL dump documentation explains that a dump created by pg_dump represents a consistent database snapshot. It also distinguishes individual database dumps from cluster-wide objects such as roles. Your engineer should identify which objects and external assets the chosen backup method does not cover.

Restore into an isolated destination and validate an agreed sample of relationships, permissions and private-file access. Record the observed recovery time and the age of the restored data. Those measurements help you decide whether the arrangement meets your business needs; they are not a universal recovery guarantee.

5. Make the remaining Bubble dependencies explicit

A migration may deliberately leave an admin interface or other low-traffic capability on Bubble. In that case, use the hybrid migration guide to define the boundary, and keep Bubble ownership, billing, monitoring and access in the operating model. Do not label the whole platform retired while part of the business still relies on it.

Even a full rebuild needs a retirement register. Check scheduled and recurring workflows, external API callers, provider callbacks, uploaded-file references and any support-only screens. Decide what happens to each dependency: retained, replaced, or eligible for retirement after stated conditions are met.

Bubble’s API settings documentation makes one easily missed distinction: disabling the Workflow API endpoint does not itself stop backend workflows. Its scheduler also separates Live and Development schedules, and externally triggered API requests do not appear as scheduled jobs. An empty schedule or disabled endpoint alone cannot prove that Bubble is inactive.

For every remaining business effect, identify the system responsible for producing it. A reminder email should not be sent by both the replacement and a forgotten Bubble job. Keep an explicit recovery window and retention decision before canceling subscriptions, revoking integrations or removing data.

6. Use an evidence register with an actual acceptance decision

A handover document becomes useful when each claim has a test, a result and an owner. The following example is illustrative, not a report from a client project.

Example: a reminder workflow after migration

Capability: send one reminder for an eligible appointment. Current responsibility: the custom-code worker; Bubble is retained temporarily for reference. Required evidence: the receiving engineer locates the scheduler, traces a test reminder through logs, confirms the intended test recipient and checks that the old path cannot send a second message for that test.

Exception: a historical reminder queue has not yet been reconciled. Acceptance decision: do not mark that dependency retired. Name the engineer who will compare pending jobs, record the agreed handling of each group, and repeat the check before closing the exception.

Use this compact evidence record for each critical capability:

• Capability and expected outcome:
• Account owner and technical operator:
• Reproducible check:
• Evidence link, environment and date:
• Status: pass / conditional acceptance / blocked
• Open exception, owner and resolution condition:
• Accepted by:

A pass in staging is staging evidence. Record separately which production checks have actually been completed.

7. Agree support boundaries before the supplier steps back

Collect known defects, accepted limitations and unfinished scope in a shared backlog. Separate a defect against agreed behavior from a new feature request. Confirm who handles incidents, who can authorize an urgent release, which channel to use, and when the receiving team becomes responsible for routine maintenance.

Discuss response time separately from diagnosis, repair and retest time. If a support period or service level is part of the agreement, point to the agreed terms rather than inferring them from a launch date or a developer’s availability during the build.

Bubble to Code’s published approach combines Bubble developers and software engineers, with code, infrastructure and documentation included in handover. Use the team’s approach as a starting point for agreeing concrete deliverables, then test the deliverables for your own app.

A practical final review

Before accepting operational handover, ask the receiving engineer to show five things: a reproducible build, a staging deployment, a traced business operation, an isolated recovery exercise, and the register of remaining Bubble dependencies. Review failures and exceptions openly, with an owner and an agreed resolution condition.

If you cannot identify an engineer who will own those tasks after launch, resolve that before cutover. Moving away from Bubble changes how the product is maintained; it does not remove the need for maintenance.