We cut maintenance cost by 40% migrating to Flutter. Here is when not to. 

A few years ago we migrated a client from a native Android codebase to Flutter and their ongoing maintenance cost dropped by roughly forty percent. That number has followed us around ever since, and it comes up in almost every conversation about migration.

It is a real number. It is also narrower than people assume when they hear it, and I have watched at least two prospects reach for a migration on the strength of it when their situation was nothing like the one it came from. So this is the honest version, including the projects where we told a client not to bother.

Where the saving actually came from

Not from Flutter being faster to write. Writing Dart is not meaningfully quicker than writing Kotlin once you know both.

The saving came from something duller. They were maintaining two applications that were supposed to behave identically and did not. A fix would land on Android and take another sprint to reach iOS, or it would land on both and be implemented slightly differently, and three months later a bug would appear on one platform that nobody could reproduce on the other.

Most of what was being paid for was not building features. It was reconciling two codebases that kept drifting apart. When the business logic moved into one place, that entire category of work disappeared.

What the migration actually cost

The rebuild took longer than the estimate. Not dramatically, but enough to be worth saying out loud, because I have never seen a migration case study admit this.

The screens went fast. Layout in Flutter is quick and a developer who knows it can move through UI at a good pace. What ate the time was everything touching the platform underneath.

• Background location, which behaves differently on every manufacturer build and needed testing on real handsets rather than emulators.
• Push notification handling, particularly deep links from a notification when the app was killed rather than backgrounded.
• A payment SDK with no maintained Flutter package, which meant writing a platform channel and maintaining it ourselves.
• Local storage migration, so users updating from the old app did not lose their data. This was three days of work nobody had costed.

None of that is a reason to avoid Flutter. It is a reason to distrust any estimate built by counting screens.

When we tell clients not to migrate

We have talked more than one company out of this, which is a strange sales position but an easier conversation than the one that happens later.

You only ship on one platform and intend to stay that way

The core argument for Flutter is one codebase serving several platforms. If you are Android only and have no iOS plan, you are paying migration cost to buy an advantage you have no use for. Stay where you are.

Your app is mostly platform specific capability

Heavy camera work, Bluetooth peripherals, background audio, anything leaning on recent OS APIs. You will spend the project writing platform channels, which means maintaining native code on both sides plus a Dart layer on top. That is more surface area than you started with, not less.

The existing code is genuinely fine

Sometimes a team wants to migrate because the codebase is a mess, and the mess is architectural rather than linguistic. Rewriting it in Dart produces the same tangle in a new language, plus a migration bill. If the problem is that nobody separated business logic from the UI, that problem is portable.

You have a native team and no Flutter experience

A team fluent in Kotlin and Swift will produce better software in those languages than in a framework they are learning on a live project. Migration makes sense when the people maintaining it afterwards actually want it.

When it is clearly worth it

The pattern is consistent enough to state plainly.

1. Two codebases meant to behave identically, and a history of them not doing so.
2. Feature work that lands on one platform noticeably before the other, and users who have noticed.
3. A small team, three or four engineers, trying to cover both platforms and covering neither well.
4. Business logic that is mostly ordinary. Forms, lists, API calls, state, navigation. This is where Flutter is strongest and where the maintenance saving is real.

Three of those four and the arithmetic usually works. One of them and it usually does not.

How to size it honestly

If you are considering this, the useful exercise takes an afternoon and does not require an agency.

Go through the last six months of commits and sort maintenance work into two buckets. Work that existed because there were two codebases, and work that would have existed regardless. Cross platform inconsistency bugs, the same fix applied twice, features shipped twice, drift between designs. That first bucket is your ceiling. It is the only part a migration removes.

Then get an estimate for the rebuild and be sceptical of it, particularly around anything touching the platform. Divide the rebuild cost by your monthly first bucket figure. That is your payback period in months.

For the client where we saw forty percent, the payback landed around fourteen months and they had a multi year horizon, so it was straightforward. For a company planning a pivot in eight months, the same arithmetic says do not.

The best migration advice we have given was to a company that did not migrate. They extracted their business logic into a shared module, fixed the drift, and kept both native apps.

Still the right call two years later

The summary, without the marketing

Flutter is a good framework and we build most of our mobile work in it. The forty percent is real and we will keep quoting it, because it happened.

But it was a saving on a specific kind of waste, in a specific situation, for a company with a long enough horizon to recover the cost. Read it as a description of what a migration can fix rather than a promise about what yours will save. If your maintenance bill is not mostly two codebases disagreeing with each other, the number does not apply to you, and anyone telling you otherwise is selling a migration.