Legacy app modernization means bringing an ageing app back to a state where it’s safe to change, cheap to run and able to support where the business is going. There are four honest options: leave it alone, refactor it in place, rebuild it module by module while it stays live, or rewrite it from scratch. Most apps should be refactored or rebuilt incrementally. A big-bang rewrite is justified far less often than teams think, and it’s the option most likely to stall halfway.
Dreambit has shipped 150+ products over 14 years (5M+ downloads, 4.9★ across 114 reviews), and much of our work is on apps someone else started: inherited codebases, apps stuck on old frameworks, products that outgrew their first architecture. This guide is the decision framework we use: how to tell which option fits, how incremental migration works on mobile, and what each path really costs. When the answer is a staged rebuild, we run it as an app modernization engagement, with the old app live throughout.
What makes an app “legacy”?
Age alone doesn’t make an app legacy. A five-year-old app with clean architecture and current dependencies is fine. An app is legacy when it starts costing you more than it should:
- Every change is slow and risky. Small features take weeks, and fixes break unrelated screens.
- The platform is moving on without it. Frameworks, SDKs or language versions are out of support.
- Store requirements are closing in. Google Play requires new apps and updates to target a recent Android API level, and Apple raises its minimum SDK requirements every year. An app that can’t be rebuilt with current tools eventually can’t ship an update.
- Knowledge has left. The people who understood the code are gone, and the documentation never existed.
- It blocks the roadmap. The business wants subscriptions, AI features or a web version, and the architecture can’t take them.
Start with an audit, not a decision
The most expensive modernization mistake is choosing the approach before looking at the code. “We need to rewrite it” is often a feeling, driven by a few painful areas, when most of the app is perfectly serviceable. An independent review of code, security, performance, UX and release health tells you which parts are actually rotten. We cover what that involves in our guide to the mobile app audit. If you want it done for you, our fixed-scope App Quality Audit delivers exactly that report.
The four options for legacy app modernization
1. Leave it alone (and maintain it)
If the app is stable, its stack is supported, and the roadmap doesn’t need anything the architecture can’t handle, the right move is disciplined maintenance: keep dependencies current, fix what the audit found and move on. It’s unfashionable, but often correct.
2. Refactor in place
Improve the structure without changing what the app does: separate UI from business logic, introduce a proper state-management approach, add tests around critical paths, upgrade dependencies, and remove dead code. Refactoring fits when the app still matches the business and runs on a supported stack. A focused refactor of a mid-size app typically takes weeks to a few months, and users never notice except that things get better.
3. Rebuild incrementally (strangler fig)
Replace the app piece by piece while it stays live. New modules are built properly, old ones are retired one at a time, and at no point is there a risky “big switch”. The name comes from Martin Fowler’s strangler fig application pattern: the new system grows around the old one until the old one can be removed.
4. Full rewrite
Start again on a new codebase and switch over when it’s ready. It’s justified when the data model is fundamentally broken, when the framework is so far out of date that upgrading is itself a rewrite, or when security flaws are built into the architecture. Even then, a rewrite should ship in stages where possible.
A big-bang rewrite has to rediscover every business rule the old app encoded, including the undocumented ones, while the business keeps asking for new features on the old app. That’s why rewrites so often run long. One widely cited industry survey found that 74% of organisations that started a legacy modernization project failed to complete it. Incremental approaches don’t remove that risk, but they cap it: every stage ships value on its own.
How incremental modernization works on mobile
The strangler fig pattern was described for web systems, where you can put a router in front of the old application. Mobile needs its own version of that seam:
- API layer first. Put a clean, versioned API between the app and the backend so either side can be replaced independently.
- Feature flags. Ship new screens or modules behind flags, turn them on for a small percentage of users, and roll back instantly if something breaks.
- Module-by-module replacement. Rebuild one flow at a time, such as onboarding, checkout or settings, inside the existing app, especially where the new framework can be embedded. Flutter, for example, can be added to an existing native iOS or Android app screen by screen.
- Run both, measure, retire. Compare crash rates, performance and conversion between old and new paths, then delete the old code once the new path is proven.
This approach also keeps the business moving. New features can be built on the new foundation while the migration happens, instead of being frozen for a year.
Refactor, rebuild or rewrite: how to decide
Use the audit findings to answer these questions in order:
- Is the data model sound? If not, plan for a rewrite of the data layer at least. Everything else depends on it.
- Is the stack supported and upgradable? If yes, refactoring is on the table. If upgrading means touching everything, lean towards incremental rebuild.
- Is the structure salvageable? If business logic can be separated from UI with reasonable effort, refactor. If it’s tangled through every screen, rebuild module by module.
- Is the roadmap blocked? If a critical capability (subscriptions, offline sync, a web version, AI features) can’t fit the current architecture, rebuild the parts that block it first.
- Can the business tolerate a feature freeze? Almost never. That alone rules out most big-bang rewrites.
What legacy app modernization costs
Ranges vary widely with app size and the state of the code, but as a rough guide:
- Targeted refactor: a few weeks to a few months of a small team, often in the tens of thousands of dollars.
- Incremental rebuild: spread over several months to a year or more, but paid for in stages that each deliver value.
- Full rewrite: comparable to building a new app of the same scope. See mobile app development cost for those ranges, plus the cost of running two apps in parallel during the switch.
The hidden costs sit almost entirely on the rewrite side. They’re shown in the iceberg chart below and explain why “just start fresh” is rarely the cheap option it looks like.
Modernizing onto Flutter
Many of our modernization projects move an app from two ageing native codebases, or an early cross-platform framework, onto a single Flutter codebase. This is the core of our cross-platform app development work. The reasons are practical: one codebase to maintain instead of two, a clean layered architecture from the start, and the ability to migrate screen by screen inside the existing native apps rather than in one leap. We describe the architecture we target in clean architecture for scalable Flutter apps, one real migration in our clean architecture case study, and a staged adoption plan in a realistic Flutter adoption roadmap.
We’ll also tell you when it isn’t the answer. If your native apps are healthy and your team is native, a framework migration is cost without benefit. The Flutter vs React Native comparison covers when cross-platform makes sense at all.
Keeping the app live during modernization
- Never freeze the old app completely. Security fixes and OS-compatibility updates must keep shipping.
- Migrate users’ data deliberately. Local databases, cached content and stored preferences need an explicit migration path and a rollback plan.
- Watch store ratings. A migration that ships a buggy screen to everyone at once undoes years of reviews. Use staged rollouts.
- Keep analytics continuous. If event names change between old and new code, you lose the ability to tell whether the new version is better.
- Test on real devices. Our approach is in mobile app testing services.
Common legacy app modernization mistakes
- Deciding to rewrite before auditing. The painful 20% of a codebase is not a reason to discard the other 80%.
- Freezing features for a year. The business won’t wait, and the rewrite ends up chasing a moving target.
- Rewriting the bugs too. Without tests capturing current behaviour, the new app quietly drops rules nobody wrote down.
- Changing the architecture and the team at the same time. Keep at least someone who knows the old system through the transition.
- No definition of done. Legacy code that’s “mostly” retired keeps costing money. Plan the deletion, not just the replacement.
Inherited an app you’re not sure about? Send us the repo access or a short description of the stack, and in a free 30-minute call we’ll tell you whether to leave it, refactor, rebuild or rewrite, and what each would cost. Book a call · Example of a cross-platform product we shipped: R-Easy.
Key Takeaways
- Legacy app modernization has four options: leave and maintain, refactor, rebuild incrementally, or rewrite.
- An app is legacy when it costs too much to change, not when it’s old.
- Store target-SDK requirements eventually force the issue. An app that can’t be built with current tools can’t ship updates.
- Audit first. Most apps need refactoring or an incremental rebuild, not a rewrite.
- On mobile, the strangler fig pattern runs through an API layer, feature flags and module-by-module replacement.
- Big-bang rewrites carry hidden costs: rediscovered business rules, data migration, parallel running and feature freezes.
- Keep the app live, shipping and measured throughout the migration.
Frequently Asked Questions
Legacy app modernization is the work of bringing an ageing app back to a state where it is safe to change, affordable to run and able to support the business roadmap. The four options are to leave it alone and maintain it, refactor it in place, rebuild it incrementally while it stays live, or rewrite it from scratch.
Refactor when the app still matches the business, runs on a supported stack and its business logic can be separated from the UI with reasonable effort. Rebuild, ideally module by module, when the structure is tangled through every screen, when upgrading the framework means touching everything, or when the architecture blocks a critical capability on the roadmap. Commission an audit first so the decision rests on evidence.
A full rewrite is justified when the data model is fundamentally broken, when the framework is so outdated that upgrading is itself a rewrite, or when security flaws are built into the architecture. Even then, ship it in stages where possible, capture the current behaviour in tests first, and keep someone who knows the old system involved.
It is an incremental migration approach: the new app grows around the old one until the old code can be removed. On mobile it usually means putting a clean versioned API layer between app and backend, shipping new modules behind feature flags to a small share of users, replacing one flow at a time, comparing crash rates and conversion between old and new paths, and deleting the old code once the new path is proven.
A targeted refactor usually takes a few weeks to a few months. An incremental rebuild is spread over several months to a year or more but delivers value at each stage. A full rewrite takes about as long as building a new app of the same scope, plus time spent running both versions in parallel during the switch.
A big-bang rewrite has to rediscover every business rule the old app encoded, including undocumented ones, while the business keeps requesting features on the old app. It also carries data migration, parallel running and feature-freeze costs that rarely appear in the original estimate. One widely cited industry survey found 74% of organisations that started a legacy modernization project failed to complete it.
