Mobile modernisation guide
Migrating a legacy mobile app to Flutter
Migrate business outcomes and supported data deliberately. Do not turn a technology change into an uncontrolled attempt to reproduce every historical screen and defect.
The short answer
To migrate a legacy mobile app to Flutter, first decide what product behaviour still deserves support. Inventory critical journeys, data, APIs, native capabilities, distribution and production obligations. Then choose a full rebuild, incremental Flutter add-to-app or a bounded hybrid path.
Stabilise server contracts and observable outcomes before replacing screens. Migrate one vertical slice through identity, local state, backend integration, analytics and support. Release behind a controlled rollout with rollback, then expand only after the new slice performs safely in production.
01
Confirm that migration solves an ownership problem
| Current constraint | Migration may help | Migration alone will not fix |
|---|---|---|
| Duplicated platform delivery | Shared Flutter product and domain layers | Unclear product priorities or release ownership |
| Unsupported framework | Move to a maintained toolchain | Unsupported backend APIs and third-party services |
| Slow feature change | Improve architecture and test boundaries | Approval, scope and organisational bottlenecks |
| Poor stability | Remove known client defects | Unreliable systems, data and operational workflows |
| Inconsistent UX | Create a coherent shared product | Missing user research or conflicting business rules |
Compare Flutter with native development and confirm the long-term team, platform and native-integration fit before committing to the migration.
02
Build an evidence-led legacy inventory
- active users, versions, device and operating-system distribution;
- critical journeys and actual feature usage;
- crashes, hangs, support cases and poor-performing screens;
- API, authentication, notification and deep-link contracts;
- local data, offline queues, encryption and migration requirements;
- camera, location, Bluetooth, USB, background and vendor SDK use;
- analytics, consent, privacy and regulatory obligations;
- store listings, signing, managed distribution and release processes;
- accessibility, localisation and device-specific behaviour; and
- business owners, support owners and safe retirement conditions.
Mark each item as preserve, improve, replace, retire or investigate. A screen count is not a migration scope because one invisible synchronisation or identity dependency may carry more risk than many simple views.
03
Choose full rebuild, add-to-app or hybrid deliberately
| Strategy | Often fits | Main trade-off |
|---|---|---|
| Parallel Flutter rebuild | Bounded product, clear scope and support for the old app during delivery | Longer interval before users receive the new path |
| Flutter add-to-app | Existing native app must evolve while selected screens move incrementally | Temporary dual navigation, build and ownership complexity |
| Hybrid by capability | Most product UI can be shared but specialised native capability remains | Platform interface and test responsibility remains permanent |
| Native modernisation | Deep platform behaviour dominates and cross-platform sharing adds little | Separate platform delivery continues |
Flutter officially supports adding modules to Android and iOS host applications. Its documentation also lists limitations and build considerations. Prototype the exact host, plugin and navigation combination instead of assuming an incremental path is frictionless.
04
Create seams before moving screens
- stabilise mobile-facing API contracts and error semantics;
- separate product state from widget and native screen lifecycles;
- wrap analytics, notifications, identity and deep links behind tested interfaces;
- define platform channels for native capability with explicit data schemas;
- keep generated host files and project-specific native edits in their intended locations;
- align dependency ownership between Flutter modules and host applications; and
- make one journey observable across old and new implementations.
Use the Flutter business application guide for shared architecture and native integration principles.
05
Treat identity and local data as cutover-critical
Decide whether users can retain an authenticated session safely, must sign in again or need an account transition. Do not copy tokens between storage mechanisms without a reviewed security model.
- version the local database and test upgrades from every supported production version;
- preserve durable pending operations or reconcile them before cutover;
- migrate only data the new app is authorised and required to keep;
- protect encryption keys and platform credential storage;
- handle deep links, notification routes and app-to-app callbacks during mixed versions;
- keep backend compatibility for the defined old-app support window; and
- record which release first owns each changed contract.
If the current app supports offline work, use the synchronisation guide to preserve operation identities and known outcomes.
06
Prove parity through outcomes, not screenshots
Functional
Same approved outcome
Compare server records, side effects, evidence and exceptions.
Operational
Supportable release
Verify monitoring, diagnostics, remote configuration and rollback.
Experience
Better task completion
Test accessibility, device sizes, interruptions and real user context.
Technical
Known performance
Measure launch, responsiveness, battery, network, crash and hang behaviour.
- Release to internal and test users.
- Run automated contract, migration and critical-journey tests.
- Use staged store or managed distribution.
- Compare outcome and health signals by version and platform.
- Stop rollout on defined guardrails.
- Retain a tested rollback or feature-disable path.
- Retire old contracts only after the supported population has moved.
07
Prepare the first migration slice
Choose a useful but bounded journey with representative identity, API, navigation, analytics and native capability. Record its current production baseline, dependencies, expected outcome, data migration, test matrix, rollout cohort, support owner and rollback.
Avoid starting with the easiest visual screen if it proves none of the uncertain architecture. Equally, avoid making the first slice the most irreversible business action. Select a path that tests real seams while remaining recoverable.
Sources
Primary references
Questions
Frequently asked questions
Can you migrate an existing mobile app to Flutter?
Yes. You can rebuild the app as a new Flutter product, introduce Flutter screens incrementally through add-to-app, or retain native areas behind platform interfaces. The correct path depends on product risk, architecture and release constraints.
Should a legacy app be rewritten all at once?
Usually only when the product boundary is small, the old app can remain supported during delivery and a parallel release is operationally acceptable. Incremental migration can reduce cutover risk but creates a temporary hybrid architecture.
Does Flutter add-to-app support Android and iOS?
Flutter's official add-to-app capability supports embedding Flutter modules in existing Android and iOS applications. Validate current platform, build, plugin and navigation limitations against the exact host apps.
Should the new app reproduce every legacy feature?
No. Inventory actual usage, business value, legal obligations, support demand and system dependencies. Retire unused behaviour and preserve only approved outcomes, data and operational controls.
How do you reduce migration risk?
Establish observable parity for critical journeys, isolate stable backend contracts, migrate in bounded slices, run old and new paths where necessary, test real devices and define rollback before each release.
Plan the migration
Bring the current apps, usage evidence, system contracts, release constraints and highest-risk native capability.
LCR can assess full rebuild versus add-to-app, define the first migration slice and protect production continuity.