Legacy app modernization
Legacy app modernization company: replace the old parts while the app stays live
Your app still works, users still depend on it, and every release is harder than the last. As a legacy app modernization company, we replace outdated code, frameworks and data layers one piece at a time, so you never have to freeze the product for a year-long rewrite. This page goes one level deeper than our app modernization services overview: how the strangler pattern works on mobile, how we make the rewrite-or-refactor call module by module, and how we move data without losing any of it.
- Incremental releases, no feature freeze
- Data migrations rehearsed before go-live
- Decisions logged with evidence
- Code stays in your repository
What counts as a legacy app
Age alone does not make an app legacy. A five-year-old Swift app with tests and clean modules is fine. A two-year-old app built on a framework that has lost support is not. We call an app legacy when its foundations block the work the business needs: store requirements, security fixes, new features or hiring.
The usual signs are concrete. The app depends on a framework or service past end of life. It cannot be built with the current Xcode or Android SDK without patches. Key libraries are abandoned. Only one person understands the data layer. Or the UI toolkit is so old that new developers avoid the codebase.
If the problem is a stalled project or a vendor that has walked away, start with failed app project rescue instead. Rescue secures access and stabilises the app; modernisation is what comes after.
End-of-life dependencies we see most often
These are deadlines and deprecations with dates that are already set. Each one turns into a forced change if nobody plans for it.
| Dependency | Status | What we usually move to |
|---|---|---|
| MongoDB Atlas Device Sync | Deprecated September 2024, end of life on 30 September 2025 | A backend sync layer you control, with SwiftData, Room or SQLite on the device |
| Xamarin | Support ended 1 May 2024 | .NET MAUI or .NET for iOS and Android, or Flutter, React Native or native, via our Xamarin migration services |
| .NET 8 and .NET 9 | Both reach end of support on 10 November 2026 | .NET 10 (LTS), supported until 14 November 2028 |
| FCM legacy APIs | Deprecated June 2023; shutdown began 22 July 2024 | FCM HTTP v1 API with OAuth service-account tokens |
| TensorFlow Lite packages | Renamed LiteRT on 4 September 2024; the .tflite model format is unchanged | LiteRT packages, with models kept as they are |
| ClockKit complications | Deprecated in watchOS 10 and later | WidgetKit complications |
| Play Billing Library v7 and older | New apps and updates must use v8 or later from 31 August 2026 | Play Billing Library v8 (its own deadline is 31 August 2027) |
Sources: MongoDB Device Sync deprecation, Microsoft’s .NET and Xamarin support policies, Google’s FCM, LiteRT and Play Billing notices, and Apple’s ClockKit documentation.
Atlas Device Sync end of life: what to do if your app still depends on it
Many apps built in recent years used MongoDB’s on-device database with Atlas Device Sync keeping it in step with the cloud. According to MongoDB’s deprecation notice, Atlas Device Sync was deprecated in September 2024 and reached end of life on 30 September 2025. We do not propose Device Sync for new work, and an app that still relies on it needs a replacement sync path.
The local database is not usually the hard part. The hard part is everything Device Sync did quietly: conflict resolution, offline writes queued for later, partial sync by user, and permissions. Each of those has to be rebuilt on purpose.
Our usual replacement
- On the device: SwiftData on iOS (built on the
@Modelmacro and integrated with SwiftUI) and Room on Android, which Google recommends over raw SQLite APIs and which checks SQL at compile time. Cross-platform apps use a SQLite-based store. - Sync: an explicit API with change tokens or timestamps, a write queue on the device, and a conflict rule you choose (last write wins, server wins, or field-level merge).
- Backend: your existing MongoDB Atlas data can stay; we add the API in front of it, or move to Postgres if the data is relational. Our mobile databases page compares the options.
The strangler pattern for mobile apps
The strangler fig pattern replaces a system by growing a new one around it. New code takes over one route, screen or service at a time, and the old code is removed once nothing calls it. On the backend this usually means a routing layer in front of the old API. On mobile it works at the screen and module level.
In practice we put a thin seam between the app and each legacy area: a navigation router for screens, a repository interface for data, an API gateway for the backend. New SwiftUI or Jetpack Compose screens sit behind feature flags and roll out to a share of users. If crash rates or key metrics move the wrong way, we switch the flag off without a new release.
The pattern is slower than a big rewrite on paper and much faster in reality, because the app keeps shipping and the business keeps learning. The trade-off is a period where old and new code live side by side, so we set a removal date for every legacy module and track it like any other backlog item.
Seams we use on mobile
- Screen router to swap old screens for new
- Repository interfaces over the data layer
- Feature flags with remote kill switches
- Versioned APIs or a backend-for-frontend
- Interop: UIKit hosting SwiftUI, Views hosting Compose
Rewrite vs refactor, module by module
Our modernization pillar covers the whole-app decision. In practice the answer is rarely one word for the whole app, so we score each module against these questions.
| Question | Points to refactor | Points to rewrite |
|---|---|---|
| Does the module have tests, or can we add them around it? | Yes: tests let us change code safely | No, and the code cannot be isolated for testing |
| Is its framework supported? | Yes, or there is a documented upgrade path | End of life with no upgrade path |
| How often does the business change this area? | Rarely: leave it alone or tidy it | Constantly: slow changes cost money every sprint |
| Is the logic well understood? | Hidden business rules nobody has written down | Rules are clear and documented in tickets or specs |
| Does the UI toolkit block hiring? | Not yet | New developers refuse or struggle to work in it |
Hidden business rules are the strongest reason to refactor rather than rewrite. A rewrite drops every rule nobody remembered to write down.
Running on a framework or service that has lost support?
Tell us your stack, user numbers and the deadline you are facing. We reply within one business day with the first questions to answer and a fixed scope for a modernization audit.
How we migrate data without losing any
Data migration is where modernisation projects do real damage. A screen bug annoys users; a migration bug loses their records. Every migration we run follows these steps.
Inventory and map
List every store: device database, files, keychain or keystore, backend tables and caches. Map each field to its new home and note anything that has no destination.
Write the migration as code
Versioned migrations in Room, SwiftData schema versions, and backend scripts in the repository. No hand-run SQL on production.
Rehearse on real-shaped data
Run the migration against an anonymised copy of production and against the oldest app versions still in use, then compare record counts and checksums.
Dual-run where risk is high
For sync and payments, write to old and new stores for a period and compare. Cut reads over only when the two agree.
Roll out in stages
Use phased release on the App Store and staged rollout on Google Play, watch crash and error rates, and keep a tested way back for every step.
Retire the old path
Once metrics are stable and old app versions have aged out, remove the legacy code, tables and credentials, and record the change in the decision log.
UI modernization: UIKit, XML Views and old cross-platform code
Moving to SwiftUI or Jetpack Compose is often the most visible part of a modernisation, and the easiest to overdo. Google calls Compose its recommended toolkit and says Android is now Compose-first, but that does not mean every working screen must be rewritten this quarter. Both toolkits interoperate with the old one, so we migrate the screens that change most, plus any screen we are redesigning anyway.
Our guides on SwiftUI vs UIKit and Jetpack Compose vs XML Views cover the trade-offs. If the app is due a design refresh, pair the work with mobile app redesign so each new screen is built once.
On Android there is one change you cannot schedule around: for apps targeting API 36, the system ignores orientation and resizability restrictions on screens 600dp wide and up. Old layouts that assumed a portrait phone break on tablets and foldables, so we fix those first.
Choosing a legacy app modernization company
Ask any vendor, including us, how they will keep the live app shipping during the work. If the answer is a feature freeze until the new version is ready, expect the project to run long. Ask to see a sample migration plan with a rollback step. Our checklist on how to choose an app development company applies too.
We are a weaker fit if you need engineers on site every day in US hours, or if the legacy system is a mainframe or desktop platform with a small mobile layer on top. We are a strong fit for mobile apps and their backends where the goal is a modern, maintainable codebase that your own team can take over.
Modernization projects
[[Add 1–2 modernization examples: the legacy stack, what was migrated in which order, how data was moved, and a result the client approved, such as release frequency or crash rate before and after.]]
[[Add a verified client quote with written permission.]] Meanwhile, see our portfolio.
Legacy app modernization: frequently asked questions
What is the strangler pattern in app modernization?
It is a way to replace an old system gradually. New code takes over one screen, module or API route at a time behind a seam such as a router, repository interface or feature flag. Once nothing calls the old code, it is deleted. The app keeps shipping throughout, which avoids the long feature freeze of a full rewrite.
Our app uses MongoDB Atlas Device Sync. What now?
MongoDB deprecated Atlas Device Sync in September 2024 and it reached end of life on 30 September 2025, so you need a replacement sync path. We usually keep a local database such as SwiftData, Room or SQLite and add an explicit sync API with a write queue and conflict rules. Your Atlas data can often stay where it is.
Should we rewrite our legacy app or refactor it?
Usually a mix. We score each module on test coverage, framework support, how often it changes and how well its business rules are understood. Modules with hidden rules or few changes are refactored or left alone; modules on dead frameworks that change often are rewritten. The audit shows the score for each module so you can see the reasoning.
Can you modernize the app without a feature freeze?
Yes, in most cases. Using the strangler pattern and feature flags, new and old code run side by side, and each sprint ships both modernisation work and at least some visible improvement. A short freeze can make sense around a risky data migration, but it is planned in days or weeks, not months.
How do you avoid losing data during migration?
Migrations are written as versioned code, rehearsed against anonymised production-shaped data and the oldest app versions in use, and checked with record counts and checksums. High-risk areas run old and new stores side by side before reads switch over. Rollout is staged through phased App Store releases and Google Play staged rollouts, with a tested rollback.
Plan a modernization you can ship in stages
Book a 30-minute call. Tell us the stack, the deadline and what the business needs next, and we will outline a module-by-module plan before you commit to anything.