Moving an Existing App to Flutter: Cost and Risk
Pavlo Rubanovskyi
August 28, 2026 · 8 min read
The question is not whether Flutter is good
You already have an app. The interesting question is not which framework is better in the abstract — it is what a move costs, what you keep, and whether the pain you have is the kind a migration actually fixes.
Some of it is not. That is the part most migration articles skip.
Three shapes a migration can take
Screen-by-screen (add-to-app). Flutter runs inside your existing app as a module. You convert one flow at a time, ship continuously, and the old code keeps working. Slowest in total effort, lowest in risk, and the only option if you cannot stop feature work for a quarter. The cost is living with two toolchains, two build setups and a bridge between them for the whole transition.
New surfaces only. Existing screens stay native forever; everything new is Flutter. Sensible when the legacy app is stable and the roadmap is mostly additive. It is not really a migration — it is a decision to stop growing the old codebase.
Full rewrite. Fastest to a clean result and the highest risk, because feature parity is a longer list than anyone's memory of it. Reasonable when the existing app is small, or when it is old enough that rebuilding is happening either way.
We would default to the first for anything with real usage, and only choose the third when the current codebase is genuinely a write-off.
What transfers, and what does not
| Carries over | Has to be rebuilt |
|---|---|
| Backend, APIs, database | Every screen and navigation flow |
| Designs and design system | Platform channel code for native SDKs |
| Store listings, reviews, ranking | Anything depending on an RN library with no Flutter equivalent |
| Analytics history and events | Widgets, home-screen extensions, watch apps |
| Signing keys and store accounts | Deep integrations: camera pipelines, background audio, custom Bluetooth |
The right-hand column is where estimates go wrong. Screens are predictable work. A native SDK with no Flutter package — or one wrapped by a plugin nobody has updated in two years — is where a migration finds its real timeline.
An audit that lists every third-party dependency and its Flutter status is the first deliverable, before anyone quotes a number.
When migrating is the right call
- Your two codebases have diverged. iOS has features Android does not, fixes land twice, and the platforms drift further apart each quarter. This is the strongest reason, and it compounds.
- You cannot staff it. Hiring two native teams for one product is expensive and fragile. One Flutter team covers both.
- Release cadence is limited by duplicated work. If every feature is built twice, you are paying a tax that a shared codebase removes.
When it is not
- "The app feels slow." Profile first. Jank is usually the data layer, image handling, or a list rebuilding on every frame — none of which a framework change fixes. You would rebuild the same mistakes in a new language.
- One platform matters and the other barely registers. If 95% of revenue is iOS, cross-platform buys you little and costs you native ergonomics.
- The app is heavy on platform-specific capability. Deep hardware access, complex background work, or a large native SDK surface means most of the code stays native anyway, and you gain a bridge instead of simplicity.
What we would do first
Not a rewrite. An audit: dependency inventory with Flutter equivalents, a map of which screens are cheap and which are load-bearing, and one representative flow rebuilt in Flutter running inside the existing app.
That last part is the real estimate. Everything before it is arithmetic on assumptions.