Migrating from Bubble to Custom Code: What Can You Keep?

TL;DR

• Distinguish a database export, Bubble's application JSON and a deployable codebase. They are different deliverables.
• Compare optimizing Bubble, moving one component and leaving the platform. A slow page or a higher bill does not establish which option you need.
• Keep useful screens and business rules as requirements, but include their implementation, permissions and plugin behavior in the replacement scope.
• Test existing users, old records, private files and subscriptions. A successful new signup does not show that any of them survived.
• Rehearse one complete workflow before the full move, including changes after the first export and tasks still scheduled in Bubble.

Can you export Bubble code?

No. Bubble's application-ownership documentation says its apps run on the Bubble platform and cannot be exported as application code. Leaving requires rebuilding the application logic. Owning the product's design and data is different from having a codebase you can deploy elsewhere.

There is an Export application feature. Bubble's Settings reference describes an application JSON file that can be imported into another Bubble app. Keep it as a reference for the migration, but do not mistake it for a React project or an independently running backend. A repository containing that file is still not a replacement application.

Database exports are separate. Bubble supports CSV, JSON and newline-delimited JSON for database data. The JSON format alone does not tell you whether a file describes the application or contains its business records. Ask a proposed migration supplier to identify exactly what each export contains and what their process produces from it.

What can you keep when you leave Bubble?

You do not need to rediscover how the product should work. Approved screens, customer-facing copy, useful business rules and existing records can all inform the replacement. Retaining those decisions does not mean their Bubble implementation transfers automatically.

Use this planning map to separate assets worth keeping from work the quote must include. It is an editorial scoping tool, not a compatibility guarantee for every plugin or authentication provider.

For each row, name the current location, the proposed destination and the person accepting the result. Mark an item as retained only when the proposal explains how it remains usable. An old attachment URL, for example, is not evidence that the attachment has been moved.

Should you optimize Bubble, move one component or rebuild?

Stay when the problem can be addressed inside Bubble

Start with the feature or operating problem that prompted the move. If one search screen is slow, measure that screen with representative data before treating the whole platform as the problem. Bubble's performance guidance identifies data fetched, filtering and chained searches as implementation choices that affect speed.

Ask for a bounded optimization attempt and compare the result against an agreed requirement. A growing customer count does not set a universal migration deadline. If Bubble still supports the work at an acceptable cost, a rebuild needs another reason.

Move a component when the rest can keep working

A custom calculation service or document-processing worker may be enough when one operation is the constraint. Bubble's API Connector lets the app call external services. In the opposite direction, its Data API lets an external application read and change enabled database records.

That creates possible intermediate arrangements: a Bubble interface with a custom service, or a custom interface with data still in Bubble. Neither is a complete exit. Require a test of the actual handoff, including permissions, response time and recovery when the other component is unavailable. Include the cost of operating both parts.

Check credentials before using a new interface with the old database. Bubble documents that an admin API token bypasses privacy rules. Do not embed that token in the browser or assume a successful administrator request proves customer access is safe. Use an appropriate user-scoped connection or a server-side service that enforces the required access policy.

Leave when the smaller option does not meet the requirement

A fuller replacement is justified when a verified requirement cannot be met acceptably while retaining the relevant Bubble components. That might be control over deployment outside Bubble or a workflow whose proposed partial solution leaves too many conflicting places to update the same records.

Have the supplier explain what would remain blocked after optimization or component replacement. Our fix-or-rebuild decision guide covers how to challenge that recommendation with a bounded test. For Bubble, the additional question is which functions would still depend on its platform after the proposed work.

Export records without losing their relationships

Have the developer identify the live dataset, required data types and fields before taking an export. In the built-in export process, Bubble asks you to select a data type and configure its view. Check that the selected view covers the intended records and fields rather than assuming one downloaded file contains the whole database.

For an API-based extraction, require pagination and a completeness check. Bubble's Data API reference documents cursors, result counts and limits on how far a query can retrieve records. A large dataset may need a partitioned extraction. Do not accept the first successful response as a complete backup.

Preserve Bubble's original identifiers as text in a source-to-destination mapping. If a request references a buyer, a supplier and several attachments, all those links need destinations too. A practical import can create the records first, establish the identifier mapping, then restore their relationships. Keep unresolved references in a review queue rather than dropping them silently.

Specify conversions for lists, dates, status values and blanks. Bubble's export documentation notes a specific issue with date-interval fields: an interval can be exported as descriptive text rather than its underlying millisecond value. Inspect a sample instead of assuming every value is ready for the destination's field type.

Ask for a reconciliation report showing what was imported, deliberately excluded or left unresolved. Then inspect known relationships and histories. Matching record counts would not reveal that a request was assigned to the wrong supplier.

Plan existing logins and private files separately

Existing users need an identity migration

An exported user row does not establish that the same person can sign in to the replacement. Bubble's user-account documentation describes the password as an invisible field, including to the app developer. Do not price an ordinary data export as a transferable password store.

For a full move away from Bubble-managed password login, plan secure account activation or password recovery through the destination authentication system unless a supported, tested alternative has been established. Do not ask users to send passwords to the developer or start storing passwords in an ordinary database field to make migration easier.

If the app already uses an external identity provider, investigate retaining it. Test that its returned identity maps to the existing account, not an empty new profile. Preserve company membership, paid access and record ownership separately from the email address used to sign in.

Accept the migration with an existing test account: the person completes the agreed login or recovery flow and reaches their old records. A new signup is a different test. An old browser session is also a separate condition; do not promise it will survive merely because the domain stays the same.

File references are not the files

Bubble's file documentation explains that file and image fields store URLs, not the file contents. Its native private files also depend on their attached database record and privacy settings. Importing those URLs leaves a storage and access dependency to resolve.

For files that are moving, request a manifest linking the source record, source file, destination object and intended access. Download and transfer the contents through an authorized process, then verify representative files from the destination. Test a permitted user and an unrelated user, including a direct request for a private file.

If files already live in a separate storage account that will stay, verify the new app's access to that account instead of copying them unnecessarily. Either way, test without relying on the old Bubble session. Do not make confidential files public to get the demonstration working.

Rebuild the work that happens after the click

Record more than page layouts. For each important action, document its trigger, inputs, conditions, records changed, external calls and delayed work. Include failed attempts, cancellations and repeat submissions. A button that looks identical can still omit a backend rule.

Review pending work as well as workflow definitions. Bubble's API workflow scheduler shows upcoming server-side workflows and maintains separate Live and Development schedules. A reminder queued before migration needs an explicit decision: finish in Bubble, recreate in the destination or cancel because it is no longer valid.

For plugins, demonstrate the behavior they provide. A document plugin may contribute formatting, file storage and email delivery, not just a download button. Identify which parts belong to an external service that can stay and which are tied to Bubble. Do not promise reuse of plugin source that the project does not possess or have permission to reuse.

Keep payment accounts separate from application access

Suppose the app uses Stripe subscriptions and the same Stripe account will remain. Preserve the customer and subscription references rather than creating replacement subscriptions just because the application changed. This is a same-provider-account scenario; moving payment accounts or providers needs a separate plan.

Stripe's subscription guidance requires the application to respond to billing events and keep access in step with subscription state. Rebuild the event handling and access policy that previously lived in Bubble. A working checkout does not test an existing customer's next renewal.

Stripe also documents duplicate deliveries and non-guaranteed event order. During the transition, decide which system applies each event's effects. Test repeated and delayed events so two handlers cannot independently grant the same credit or send contradictory notices. Reconcile provider state with the destination's access records before retiring the old handler.

Rehearse one complete workflow before the full move

Hypothetical example. A supplier marketplace built in Bubble lets buyers send requests, suppliers reply with a private attachment, and staff review disputes. Suppliers pay for access through an existing Stripe account. This is a migration exercise, not a Caemcore client case.

Use synthetic users, documents and a payment sandbox. Choose a representative request and run the proposed extraction and replacement through these checks:

1. Preserve the old transaction. Import a request with its buyer, supplier, replies and attachment references. Trace each relationship back to its Bubble identifier. Explain any excluded or unresolved record.
2. Let the existing people complete the work. The buyer signs in through the agreed migration flow and opens the original request. The supplier adds a reply, and the buyer opens the correct private attachment. A different buyer cannot retrieve either the request or its file.
3. Exercise the hidden rules. Repeat the reply submission and simulate a failed notification. Check the agreed retry behavior. Cancel a request with a reminder already queued in the old environment and show why no obsolete reminder will be sent later.
4. Handle a change after the initial export. Create a reply and remove an attachment in the authoritative test environment after the first copy. Run the catch-up procedure. Verify both changes, including the removed reference; copying only newly created rows would miss it.
5. Carry access and new work through a failed switch. Simulate a subscription renewal and a repeated provider event. After the destination accepts another reply, rehearse the agreed recovery procedure. The reply must remain accounted for and paid access must match the provider's state.

Record the tested version, results and remaining failures. This rehearsal establishes evidence for the chosen migration slice, not a complete security assessment or proof that every feature has been rebuilt. Add the product's remaining workflows to the same acceptance process.

Agree the switch and the price before rebuilding everything

The proposal should name the retained Bubble components, replacement workflows, data and file scope, identity migration, integration work and acceptance tests. Include deployment, monitoring, operating instructions and responsibility after launch. Price new product features separately from preserving existing behavior.

Ask what the estimate assumes about extraction time and continued activity. Bubble's export guide warns that exports share the scheduler with API workflows and can be delayed by queued work. A planned write pause must be based on a rehearsal, not an assumed instant download.

For a system that keeps accepting work, define how edits, deletions and external events reach the destination after the first copy. Give each kind of write one authoritative system at every stage. Changing the domain alone does not explain what happens to an old browser tab, scheduled workflow or payment notification.

Recovery must cover records created after the switch. Decide whether a failed release returns to Bubble with those changes reconciled or is corrected in the destination. Keep the old environment available until the agreed checks pass, but do not leave two independent versions writing indefinitely.

Compare one-time delivery with the full operating arrangement: retained Bubble charges during transition, new infrastructure, external services and maintenance. A lower hosting bill alone does not establish a cheaper system. Our rebuild cost guide provides a checklist for comparing proposals on the same scope.

The useful first commitment is a reviewed migration map and a tested workflow. When a smaller change meets the requirement, keep the working parts. When leaving Bubble is justified, use that evidence to scope the rest of the move rather than buying a visual recreation and discovering the missing behavior at launch.

About Caemcore

Caemcore builds custom software for companies that outgrew off-the-shelf tools.

Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.

You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.

Built it on no-code or AI tools and it stopped changing? We start with an audit, not a quote. 30 minutes, free: what we keep, what we rebuild, what blocks launch, the range and the timeline.

You get that whether we work together or not.

FAQ

Can AI convert my Bubble app to React?

An AI tool may help generate a replacement from the information you provide. Treat its output as a new implementation to review, not proof of a complete migration. Ask it to demonstrate backend rules, access restrictions, integrations and existing-record migration as well as the interface. A generated React screen does not establish what happens when a payment fails or a private file is requested.

Do I need to choose React, Node.js or another stack before requesting a quote?

Start with the workflows, deployment requirements and people who will maintain the app. Ask suppliers to explain how their proposed stack meets those needs and what another team would need to take over. A frontend framework is only part of the system. The proposal must also cover data, server-side behavior, authentication and operations.

Can nontechnical staff still change content after the migration?

Yes, when the replacement includes an appropriate editing interface or connects to a content system. List what staff currently change in Bubble, such as text, catalogue entries or approval settings, and distinguish content edits from changes to business logic. Put the required editing tools and permissions in the scope. Access to a code repository is not a substitute for those tools.

Do we have to move every historical record into the new live database?

No. Define which history the active workflow needs and which records can remain in an accessible archive. Check how staff will find an old transaction and its files before excluding it. Preserve necessary links from current work to archived records, and have the responsible business owner approve any retention or deletion decisions.

Can another team migrate the app if the original Bubble developer is unavailable?

Potentially, provided you have authorized access to the app and the required data and service accounts. Ask the receiving team to inspect workflows, privacy settings, plugins and scheduled tasks, then separate confirmed behavior from assumptions. A walkthrough and representative transactions help recover missing context. Missing access or undocumented business decisions should remain explicit dependencies in the estimate.

Sources

• Bubble, Application and data ownership. Checked 16 September 2026.
• Bubble, Settings tab: application export and import. Checked 16 September 2026.
• Bubble, Exporting data. Checked 16 September 2026.
• Bubble, Performance. Checked 16 September 2026.
• Bubble, The API Connector. Checked 16 September 2026.
• Bubble, Data API requests: guide. Checked 16 September 2026.
• Bubble, Data API privacy rules. Checked 16 September 2026.
• Bubble, Data API requests: reference. Checked 16 September 2026.
• Bubble, User accounts. Checked 16 September 2026.
• Bubble, Files. Checked 16 September 2026.
• Bubble, API workflow scheduler. Checked 16 September 2026.
• Stripe, Using webhooks with subscriptions. Checked 16 September 2026.
• Stripe, Webhooks. Checked 16 September 2026.

Platform details were checked on 16 September 2026 using Bubble and Stripe documentation. The retention map, proposed checks and supplier-marketplace scenario are editorial planning tools, not tested migration results or a Caemcore client case. The billing example retains the same Stripe account. No migration vendor, conversion tool or app-specific credential-transfer route was independently tested.