Bubble Migration Cutover Plan: When Rollback Is Safe

Keeping the old Bubble app available is useful. It is not enough to make rollback safe. Once customers create orders, upload files or change subscriptions in the replacement, the old application may no longer describe the business accurately.

This guide gives founders and technical leads a practical way to review that boundary before launch. Use it alongside your data migration checks: those establish whether the transferred data is correct; this plan establishes who can change it next and what happens if the launch must stop.

Start with two different recovery situations

Before the replacement accepts new business writes, recovery may mean returning traffic to the old system and resuming its paused operations. Even then, confirm that queued work and external services have not changed the underlying state.

After the replacement accepts new writes, recovery also needs a data decision. Can the new records and changes be represented in Bubble? How will you preserve their relationships and avoid repeating payments or notifications?

AWS’s cutover guidance makes the same fundamental distinction between rollback without new data and rollback after transactions have changed the target. That principle applies to a Bubble rebuild even when AWS is not your hosting platform.

Ask the team to name the exact point at which the simple traffic-reversal procedure stops being sufficient. A promise to “keep Bubble for 30 days” does not answer that question.

Map every route that can still change the business

The visible website is only one source of activity. A maintenance page can stop someone clicking Save while an API workflow continues changing records behind it.

Create a write-path inventory covering:

• Customer and staff screens that create, edit or delete records.
• Bubble API endpoints and incoming integrations.
• Scheduled API workflows, recurring events and database-triggered workflows.
• Payment-provider events, email delivery events and automation tools.
• Background queues, imports and file uploads that have already started.

For each path, record its current owner, its replacement, the switch or pause mechanism, and the evidence that it is inactive. Include test-environment integrations: a staging system must not send real customer emails or alter live billing during a rehearsal.

Bubble documents separate controls for canceling scheduled workflows and recurring events. Scheduled workflow cancellation uses the returned workflow ID; a recurring event can be canceled by setting its frequency to None. Inventory those controls before the window rather than assuming one application-wide switch will cover everything. Cancellation is not proof that an action which already ran has been undone.

For a hybrid Bubble migration, do this per capability. An admin tool may remain on Bubble, but it still needs a defined route for writing to the authoritative data source.

Choose who is allowed to write during the switch

There are two broad approaches. Neither should be selected solely to support a “zero downtime” claim.

A controlled write pause

Stop or queue the relevant incoming work, complete the final transfer, verify it, switch traffic, and then reopen writes on the replacement. This creates an interruption that must be communicated and measured. It can make the ownership boundary easier to reason about.

Specify what users see and what happens to work submitted during the pause. “Please try again” is different from “We saved your request and will process it later.” The system must support whichever message you show.

An engineered overlap

If uninterrupted writes are necessary, the team needs a designed coexistence mechanism. That might include a shared write service or a change-transfer process with a clearly identified source of truth. Two applications being online is not, by itself, a synchronization strategy.

Ask how failed transfers are retried, conflicting edits are resolved, deletions are represented and progress is measured. If both systems write independently, ask who detects a write that succeeds in one place and fails in the other. Do not accept “dual write” as a substitute for those answers.

For either approach, old browser sessions and integrations must be unable to bypass the chosen boundary. A domain change cannot enforce database write permissions.

Build a cutover record the team can actually use

A useful runbook is an ordered set of actions with owners and pass/fail evidence. It should remain readable while something is going wrong.

For each step, fill in these fields:

• Action and named operator.
• Preconditions, including the last verified data checkpoint.
• Expected result and where to find evidence.
• Stop condition and the person authorized to decide.
• Recovery action, including its data consequences.
• Start time, completion time and outcome.

Keep credentials out of the document. Reference the authorized place to retrieve them instead.

The overall sequence should cover readiness approval, controlling writers, final reconciliation, traffic and integration routing, critical-path checks, and reopening business operations. Reserve time for recovery rather than spending the entire window attempting fixes. AWS’s pre-cutover guidance recommends rehearsing the plan and accounting for both fix-forward and rollback time.

DNS deserves its own check. A DNS record’s TTL influences caching, but changing a record does not move every client instantly. Cloudflare’s TTL documentation notes that local caches can take longer to update. Verify behavior at both old and new destinations during the transition; do not reopen the old system for writes just because some traffic still reaches it.

Keep payment events and background work under one owner

Suppose both the Bubble workflow and the new webhook handler receive the same payment notification. They must not each send a receipt, grant access or initiate the next business action independently.

Stripe’s webhook documentation warns that deliveries can be duplicated and are not guaranteed to arrive in generation order. It recommends tracking processed event IDs, with additional object-and-event-type handling for some duplicates. Signature verification remains necessary on the receiving endpoint.

For the cutover, define one owner for each side effect and record the transfer checkpoint. Test retry and delayed-delivery behavior in a sandbox. A second endpoint can observe events without acting on them, but only if that separation is explicitly implemented and verified.

Carry forward or consult the record of actions already completed before ownership moved. A new handler with an empty duplicate-event log cannot recognize an event that Bubble has already processed. Test an event processed before the switch being delivered again afterward.

Do not equate switching a webhook URL with migrating billing state. Keep provider identifiers and reconcile application records against the provider before replaying work. Turning the domain back will not reverse an email already sent or a payment already taken.

Before reopening writes, decide how the team will identify every change accepted after the final checkpoint, including deletions, file references and external actions. Record how those changes will be preserved, mapped back if necessary, and checked for completeness. A recovery plan that depends on discovering the changed records during an incident has not yet been demonstrated.

Rehearse the failure after new writes, not just before them

A rehearsal that stops before the first new order misses the difficult case.

Use a controlled test environment with representative, appropriately protected data. Keep outbound integrations sandboxed or directed to test recipients. Create a few traceable changes in the replacement: a new record, an update to an existing one, a deletion, a file upload, and a delayed external event. Then exercise the recovery procedure.

Check whether each change survives, whether identifiers still connect the right records, and whether a replay repeats a side effect. If the replacement has fields or relationships that Bubble cannot represent, resolve that mismatch before presenting rollback as available.

Illustrative decision: an order exists only in the replacement

Imagine a customer creates order DEMO-104 after launch, and the new application then fails its order-management checks. Bubble still has the pre-launch snapshot.

Pointing traffic back immediately would leave staff unable to see that order. A safe decision needs more information: was payment taken, was fulfillment started, and can the order and its relationships be transferred back without repeating either action?

The team might choose a temporary write pause while it reconciles the order, or repair the new system and continue forward. This is an illustrative decision exercise, not a client case or a universal recommendation. The right route depends on tested recovery capability and the business impact of waiting.

Set launch gates around outcomes, not a green homepage

Before launch, agree which failures require stopping, which can be repaired while operating, and who makes that call. Avoid inventing a generic error-rate threshold for every application.

Your evidence should cover the critical user journey, authorization between roles or organizations, the authoritative record after a write, pending-job handling and integration outcomes. A successful HTTP response alone does not prove the right business action happened.

After writes reopen, watch new records and side effects as well as availability. Record unresolved discrepancies with an owner. Retire Bubble only after the remaining dependencies, recovery needs and data-retention obligations have been reviewed; a calendar date alone is not evidence that it is safe to remove.

Questions to bring to a migration review

Ask your team these five questions before approving the window:

• Which system owns each write path during every stage?
• What evidence proves the final data checkpoint is complete?
• What changes after the first write in the replacement?
• Can we recover that write without repeating an external action?
• Who can stop the launch, and what tested procedure will they use?

Bubble to Code combines practicing Bubble developers with software engineers, as described on its team and approach page. That combination matters here: a cutover review needs both the Bubble workflow inventory and the replacement’s recovery design.