Your customer portal has a public address, returning users, and requests still awaiting a response when the builder hands it over. It must remain usable after that person leaves. Evaluate Bubble alternatives against that running service: WeWeb is worth testing for a browser portal with a code-export requirement, while FlutterFlow belongs on the shortlist when Flutter or mobile delivery is part of the requirement.
Keep Bubble when its hosting arrangement and the people maintaining its workflows meet your needs. Moving an established portal means rebuilding behavior and checking existing records, not just recreating pages. This comparison uses official documentation checked November 2, 2026; the migration checks are proposed acceptance criteria, not results from a hands-on benchmark.
Set the handover requirements before choosing a builder
Use the same customer task for every option: sign in, open a request, attach a document, and read its status later. Include the staff workflow that changes that status and the notification telling the customer what happened. The replacement needs to preserve those relationships and unfinished requests, even if its internal implementation differs.
Separate identity from authorization. Identity establishes who signed in; authorization decides which customer records and actions that person can access. Decide where those checks run, how membership is revoked, and which service owns the customer-to-account relationship. A visible login page does not establish that a copied request link or attachment is protected.
Then specify who controls the app workspace, domain, data, deployment, and service credentials after handover. Ask the next maintainer to release a change and restore the prior version using those accounts. Compare subscription costs only after assigning these responsibilities, because a hosted runtime and a code download leave different work with your team.
| Option | Reason to retain or evaluate it | Handover constraint |
|---|---|---|
| Bubble | Keep the existing portal when its runtime and maintenance model fit | Independent hosting requires rebuilding application logic |
| WeWeb | Browser portal with a self-hosting requirement | Export does not move stored records or uploaded files |
| FlutterFlow | Flutter ownership or mobile delivery is an explicit requirement | A maintainer must support the exported app and its backend |
Bubble: retain a working portal when the runtime fits
Fit: Bubble is the baseline when the portal already serves customers and the handover can remain within its editor and hosting model. Start by documenting the existing workflows and checking whether the next maintainer can support them. Replacing a functioning implementation needs a requirement the current arrangement cannot meet, such as independently deployable application code.
Ownership and migration: Bubble’s ownership documentation says user-created data can be exported through CSV or accessed through its API, but apps run on Bubble and cannot be exported as code. Leaving requires rebuilding application logic. Include privacy rules, plugins, scheduled jobs, and external service calls in that rebuild inventory; exported rows do not contain their behavior.
Decision: Stay if the access checks, operating arrangement, and measured cost are acceptable, then complete the account and maintenance handover. The Bubble pricing article covers workload budgeting in detail. A migration budget should compare that ongoing arrangement with the rebuild and operation of the replacement, rather than comparing starting subscription prices.
WeWeb: evaluate export for a browser portal
Fit: WeWeb supports interface-only and full-stack self-hosting. Its full-stack deployment documentation describes separate interface and backend exports connected to PostgreSQL. Evaluate it when the portal needs a browser interface and your team can operate the selected backend.
Ownership and migration: WeWeb’s export documentation says its exported backend and authentication can run on your infrastructure. Stored records and uploaded files need separate transfer, secrets need configuration, and email delivery needs setup. Keep an existing external backend only after testing the new portal against its access rules.
Decision: WeWeb warns that exported code is difficult to maintain outside its editor and cannot be imported back. Choose it with an agreed editing and release process, rather than assuming export creates a conventional developer handover. Confirm current export eligibility before purchase; the WeWeb pricing article separates builder access, hosting, and backend costs.
FlutterFlow: shortlist when Flutter or mobile is required
Fit: FlutterFlow’s ownership documentation says creators own the output of their work, including exported code. Its web publishing documentation covers browser deployment alongside mobile apps. Include it when the next maintainer wants a Flutter application or the product must serve a defined mobile requirement as well as the portal.
Ownership and migration: The FlutterFlow CLI documentation describes project code export, including branch and asset options. That provides a code handoff to evaluate, while the existing customer data, backend services, and access rules still need a migration plan. Confirm the plan’s current export rights and the licenses of dependencies before committing to delivery.
Decision: Require the receiving developer to build and release the exported project, then change a workflow without losing custom work in a later export. FlutterFlow documents web compatibility warnings for some widgets and actions, so test the actual browser journey. A mobile requirement should justify the additional platform work; a responsive customer page alone does not establish that need.
Separate the export package from the running service
Require a handover inventory that names what the package contains and what remains elsewhere. Application files, database records, attachments, and secret configuration are separate deliverables. An export demonstration should state which of them it covers, then show how the destination obtains the rest without relying on the departing builder’s account.
Assign the runtime obligations too: renewing the domain, operating the database, monitoring failures, restoring backups, and releasing fixes. Have the receiving owner demonstrate a restore with permitted sample data. A downloadable application can still depend on an unavailable service, and source ownership alone does not identify who will restore customer access.
App files, data transfer, configuration inventory
Identity, access, hosting, recovery, updates
Where Permute fits: reuse governed data behind the portal
Permute sells connected business data and custom applications. We have a commercial interest in the data and application work behind a portal. Where customer status depends on project, CRM, or accounting records, we can reconcile identifiers and preserve source evidence in a shared output rather than rebuilding the interpretation inside each screen.
We encode the approved definition of an open request, its owning customer, and the source that establishes its status in reusable logic. A report and a custom app can consume that governed result under current permissions. Keeping the definition outside a particular page reduces the business logic that a frontend change needs to reproduce.
An account manager can inspect why a customer status differs from the source, including the matching evidence and refresh time. An unresolved identity stays visible for review instead of attaching another customer’s record to the portal. The same governed data can support Claude, ChatGPT, and Copilot when authorized users need to investigate the result.
Inspect the records behind a customer status
Start with permitted source data and examine which identifiers, definitions, and evidence a recurring output needs.
Accept a migrated customer journey before switching traffic
Use permitted test records to trace the same request from the existing portal into the replacement. Preserve its customer association, identifier, status history, and attachments. Decide how accounts will sign in after cutover, including whether users must reset credentials; do not assume a record export also transfers working authentication.
- Open another customer’s request and attachment through copied URLs, and confirm that the data service denies both.
- Revoke customer membership and retry from an existing session, including a saved download link.
- Submit the same request again after an interrupted response, and check that the retry does not create duplicate business work.
- Restore a prior release with its compatible data and configuration, then complete the customer journey again.
Keep status changes and notifications under review during the rehearsal. If the destination sends an email while the old portal still runs, the customer may receive conflicting instructions. Agree which application owns writes during the final transfer, how late changes are captured, and which conditions trigger rollback before redirecting the live domain.
For each candidate, obtain the cost of builders, production hosting, data services, file storage, authentication, email, and ongoing support. Migration and operation totals remain unknown until the receiving team scopes the real workload. If the requirement expands beyond this portal, the business AI app builder comparison covers a broader range of development models.
Scope data access separately from portal hosting and migration
This article promises no native Bubble, WeWeb, or FlutterFlow connector and no automatic conversion between them. We do not supply their subscriptions or claim that Permute hosting is a drop-in runtime for their exports. The public customer audience, identity service, source access, and any permitted writes need an explicit implementation scope.
The shared-data example reads permitted source records; it does not promise external write-back or a replacement for every portal backend. Customer submissions, notifications, and record changes need their own authorized execution path. Keep those responsibilities with named owners (including support after the original builder leaves) before setting a launch date.
Choose the service your next maintainer can operate
Keep Bubble when the current portal and its runtime meet the handover requirements. Evaluate WeWeb for a browser portal with an export path, and FlutterFlow when Flutter ownership or mobile delivery justifies that choice. In either move, accept the customer journey, data transfer, and access checks before redirecting traffic. The handover is complete when the receiving owner can maintain and restore the service that customers use.
Scope the shared data behind your portal
Bring the customer journey and source inventory to discuss reusable outputs, access requirements, and delivery responsibilities.
Questions about moving a customer portal
Does changing agencies require changing the builder?
No. First check whether the receiving agency can work in the current editor and take control of the required accounts. Complete a release and recovery rehearsal before accepting the handover. A platform move adds a rebuild even when the original issue was account ownership or missing documentation.
What happens to links customers have already saved?
Include old request and attachment URLs in the cutover inventory. Decide which can redirect to an equivalent destination and which need a customer notice, while preserving authorization on every route. A redirect must not turn a formerly restricted file into a public download.
When should the old portal be removed?
After the owner accepts the migration and the agreed rollback period has ended, resolve remaining requests and retention requirements before removal. Revoke obsolete credentials and service access as part of that closure. Keeping an unused portal running indefinitely leaves another place where customer access must be maintained.