★★★★★ 4.6 CE

FlutterFlow Migration & Switching Guide 2026

FlutterFlow has almost no lock-in: one CLI command exports the complete Flutter source you own and can host anywhere. There's no importer, so moving in is a rebuild.

Website BuildersVerified today

Full review Pricing Official site ↗

FlutterFlow Migration verdict

Verified today·6 sources checked

FlutterFlow has almost no lock-in, which is its strongest card.

There is no importer for an existing site or app, so moving in is a rebuild, but moving out is wide open. One CLI command, flutterflow export-code, downloads the complete Flutter source, or you push it to GitHub, and the result is a standard Dart project you own and can host anywhere Flutter runs.

How to plan the move

FlutterFlow suits teams that want no-code speed without the lock-in: build in FlutterFlow, export the Flutter source, and keep the option to hand off to developers or self-host later. It is less ideal if you need to import an existing app automatically, since the inbound move is a manual rebuild.

Honest limits

There is no importer for an existing site or app, so the inbound migration is a full rebuild of pages and logic in the editor.
FlutterFlow overwrites its own flutterflow Git branch on every push, so custom code must live on a separate develop branch. Re-exporting can overwrite files, so a .flutterflowignore is required to keep native config and your web entry point.
Custom domains require a paid plan, with one free domain included, while the free tier uses a FlutterFlow subdomain.

App import: None (rebuild)
Source code export: Full Flutter (CLI + GitHub)
Custom code: Real Dart, yours
Backend data: Your Firebase / Supabase
Lock-in: Near zero

View sources

This page covers migrating in and out of FlutterFlow. SEO output and pricing live on their own pages.

What moves into FlutterFlow, and can you leave?

Migration & portability receipt

Pick what you are bringing to FlutterFlow, and see exactly what transfers.

Migration read3 transfer, 1 need hand work

Existing site or app (pages/logic): does not transfer, no importer; rebuild in the editor.
Backend (Firebase / Supabase): imports natively, connect your own backend via API calls.
Custom domain: imports natively, one free custom domain on paid plans.
Custom Dart code: imports natively, custom functions and actions are real Dart.

Cutover steps, in order

1Rebuild pages and logic in the editor, no app importer.
2Connect your own backend, Firebase/Supabase + API calls.
3Export the Flutter source, flutterflow export-code (CLI).
4Wire GitHub, edit on develop branch, flutterflow branch is overwritten.
5Protect files with .flutterflowignore, globbing list.

Every row is a documented import/export capability from FlutterFlow and the source platforms, not an effort estimate.

FlutterFlow migration configuration

Install the FlutterFlow CLI and run export-code with your project id and API token to download the complete Flutter project. Flags let you skip assets, pick a branch, run dart fix, or build as a module. The output is a normal Flutter app you build and host yourself.

Export the full source (CLI)bash

dart pub global activate flutterflow_cli

flutterflow export-code \
  --project your_project_id \
  --dest path_to_output_folder \
  --token your_token \
  --no-include-assets \   # optional: skip images/GIFs
  --branch-name main \    # optional: export a specific branch
  --fix                    # optional: run `dart fix` on the output

When you re-export over an existing project, a .flutterflowignore in the project root lists files FlutterFlow must not overwrite, using globbing syntax. Use it to keep native build config and your web SEO entry point across exports.

.flutterflowignore (protect edits)text

# .flutterflowignore (project root, globbing syntax)
my_flutterflow_app/android/app/build.gradle   # keep native Android build config
my_flutterflow_app/ios/Runner/Info.plist      # keep iOS app metadata
my_flutterflow_app/web/index.html             # keep custom web entry / SEO head

FlutterFlow pushes to a 'flutterflow' branch you should not edit directly. Create a develop branch from it for your custom code, then merge FlutterFlow's updates in via pull request and ship from main. This keeps generated and hand-written code cleanly separated.

GitHub branch flowbash

# FlutterFlow pushes generated code to the 'flutterflow' branch.
git checkout flutterflow
git checkout -b develop          # your custom-code branch
# ...edit, commit, push your changes to develop...
# Pull FlutterFlow updates in:  PR  flutterflow -> develop
# Ship:                         PR  develop -> main, then deploy

What moves when you migrate to/from FlutterFlow

Migration element	On FlutterFlow	Detail	Source
Existing site or app import	Not supported	No tool converts an existing site/app; rebuild it in the FlutterFlow editor	—
Full Flutter source code (out)	Native export	flutterflow export-code downloads the complete Dart/Flutter project you own	—
GitHub	Native push	Connect a repo and push code; FlutterFlow writes to a 'flutterflow' branch	—
Custom Dart code	Travels with the export	Custom functions and actions are real Dart that ships in the exported project	—
Backend data	Your own backend	Data lives in your Firebase/Supabase and API calls, not a proprietary store	—
Custom domain	Paid plans (1 free)	All paid plans include one free custom domain, more purchasable	—

Source-to-FlutterFlow mapping

What you are moving	Where it lands	Caveat	Source
Existing app pages/logic	Rebuilt in the editor	No importer; this is the bulk of the inbound work	—
FlutterFlow screens	Dart/Flutter widgets (on export)	Standard Flutter project; build and run with the Flutter toolchain	—
Custom functions/actions	Native Dart in the project	Already real code; nothing to re-implement when you leave	—
Hand edits after export	Develop branch on GitHub	Edit on a develop branch; merge FlutterFlow's flutterflow branch in via PR	—
Files you must not lose	Protected by .flutterflowignore	Globbing list keeps native config and web/index.html from being overwritten	—
Backend records	Stay in your backend	Firebase/Supabase and APIs are yours; not exported because never imprisoned	—

FlutterFlow migration timeline and rollout

Phase	What happens	Effort	Source
1. Rebuild app	Recreate pages and logic in the editor	High, no importer for an existing app	—
2. Connect backend	Point to your Firebase/Supabase and APIs	Medium, your data stays in your backend	—
3. Export the code	flutterflow export-code via CLI	Low, one command, repeatable	—
4. Wire GitHub	Push to a repo, edit on a develop branch	Low, standard git flow	—
5. Protect edits	.flutterflowignore keeps custom files	Low, one globbing file	—

What to verify before you commit to FlutterFlow

Getting out is cheap and documented: one CLI command downloads the full Flutter source, so unlike a proprietary-engine builder you are never trapped, the application itself is portable
Getting in is the cost: there is no importer for an existing site or app, so the inbound migration is a full rebuild of pages and logic in the editor
Custom code needs branch discipline: FlutterFlow overwrites its own flutterflow branch on every push, so keep hand edits on a separate develop branch and protect files with .flutterflowignore
Your data is never the hostage: records live in your own Firebase/Supabase and are reached through API calls, so the backend is yours independent of FlutterFlow

FlutterFlow Migration FAQ

Can I export my FlutterFlow app's source code?

Yes, in full. The FlutterFlow CLI command flutterflow export-code downloads the complete Flutter and Dart project, and you can also push it to a GitHub repository. The output is a standard Flutter app you can build with the normal toolchain and host anywhere, which is why FlutterFlow has near-zero lock-in compared with proprietary-engine builders.

Can I import an existing app into FlutterFlow?

No. There is no importer that converts an existing site or app into a FlutterFlow project, so the inbound migration is a manual rebuild of pages and logic in the editor. The effort is on the way in, while the way out is a one-command export.

How do I manage custom code I add after exporting?

Use a GitHub branch model. FlutterFlow pushes its generated code to a branch named flutterflow and overwrites it on every push. So you create a develop branch from it for your hand-written code, merge FlutterFlow's updates in via pull request, and ship from main. A .flutterflowignore file also protects specified files from being overwritten on re-export.

Where does my data live in FlutterFlow?

In your own backend. FlutterFlow apps read and write through API calls and connect to services like Firebase or Supabase that you control, rather than a proprietary database tied to the platform. Because the data was never imprisoned, there is nothing to extract when you leave, since you already hold it.

What is the catch with FlutterFlow's portability?

The catch is on the input side and in code hygiene, not lock-in. You cannot import an existing app, so building it the first time is real work. And once you add custom code, you must respect the branch model, keeping edits on develop and never on the flutterflow branch. Maintain a .flutterflowignore too, or a re-export will overwrite your changes.

Sources & verification

Verified by ComparEdgeMethod: Vendor docs, official pages, and selected independent sources

Source	What was checked	Last checked
Flutterflow Official	Official product page	July 10, 2026
Flutterflow Developer docs	Flutterflow CLI Exporting	July 10, 2026
Flutterflow Developer docs	Exporting Push To Github	July 10, 2026
Flutterflow Developer docs	Custom Code Custom Functions	July 10, 2026
Flutterflow Developer docs	Backend Query API Call Query	July 10, 2026
Flutterflow Developer docs	Accounts Billing Manage Custom Domains	July 10, 2026

Every fact on this FlutterFlow page is tied to a named source and a verification date. Freshness-sensitive figures trace to the sources above; verify against the vendor before relying on them.