Your app still works. It just can’t keep up any more.
App Modernization & Migration for Mobile Apps
Old framework. Every new feature takes twice as long as the last one. Store rejections you did not see coming. We move your app onto a current stack in stages, while it stays live, and while your users keep everything they have.
52+ apps and products delivered · 7+ years · Upwork Top Rated Agency · 100% Job Success · 54 client reviews
Apps we have shipped and kept running
Apps age in a way that is easy to ignore until it is expensive. The framework goes out of support. The people who wrote it move on. A feature that would have taken two weeks takes two months, and nobody can say exactly why. Then a store deadline arrives and suddenly the oldest decision in your codebase is your most urgent problem.
We move apps onto a current stack in stages, with the old and new code running side by side, so you keep shipping while the work happens. We will tell you which parts are genuinely holding you back and which parts are fine, and we will tell you when the honest answer is to leave it alone.
Why people call us
“Every new feature takes months. It didn’t used to.”
The architecture is fighting you. Nothing is broken, so nothing looks urgent, and it gets worse every quarter.
“We got an email from Google and I don’t understand it.”
A store deadline. These have dates, and the dates are real.
“Our old developer left and nobody wants to touch it.”
The stack is old enough that hiring for it is now the problem, not the code.
“We want to add AI and we’re told the app can’t do it.”
Usually true, and usually fixable. Older apps have no clean API layer and no event history to build on.
Who you’ll actually work with
Anand Yadav
Most people who call me about an old app have already been told to rebuild it. Sometimes that is right. Usually it is not, and the person who said it had not read the code.
So I do it in the other order. I read the code first, I send you the rules I judge it by before I have seen anything, and then I tell you which parts are actually costing you time and which parts are just old. Old is not the same as broken. A lot of what gets called legacy is working fine and should be left alone.
And I will put a payback number in writing. If a migration is not going to pay for itself in a time you find reasonable, I would rather tell you that than bill you for it.
What you actually receive
| What you get | Detail |
|---|---|
| A Modernization Audit report | Written, 4 to 6 pages. What state the code is really in, what is costing you time, what is fine, what to migrate and in what order. Yours whether you continue with us or not. |
| A staged plan with cost and time against each stage | Not one number for the migration. Each stage priced and dated separately, so you can stop after any of them. |
| A written payback estimate | How long before the migration pays for itself in development time, and what has to be true for that to hold. Revised in writing if it moves. |
| The keep-or-rebuild verdict, against published criteria | You get the criteria before we read the code. The report shows you which one your app failed. See section 09. |
| A working app after every stage | Not after the project. After every stage. Old and new code run side by side and you ship the whole way through. |
| A hiring note | What your stack means for hiring: which parts make a developer hard to find, and what changes that. Nobody asks for this and everybody needs it. |
| The code, in your repository, from day one | Plus build and release instructions, architecture notes, and a credential list. |
| A rollback plan for every stage | Written before the stage starts, not improvised during it. |
Sample Modernization Audit report: Sample report needed
07. The dates you can’t miss
The dates you can’t miss
Checked 11 August 2026 · next check 11 November 2026Most reasons to modernize are judgement calls. These are not. They have dates, they come from Apple and Google, and they do not move because your quarter is busy.
Platform deadlines
Apps uploaded to App Store Connect must be built with Xcode 26 or later, using an SDK for iOS 26, iPadOS 26, tvOS 26, visionOS 26 or watchOS 26.
New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play.
An existing app below the target API level will stop being available in Google Play to new users on devices running Android OS newer than what your app targets.
Wear OS and Android Automotive apps must target API 35.
A correction to something we have written ourselves
You will see the Google Play deadline described as “your app becomes uninstallable”. That is not what Google says. Existing installs are explicitly unaffected. It is still serious. You lose every new user on a new phone and you cannot ship updates, but your current users do not lose your app. We would rather you have the accurate version and trust the rest of this page.
Framework support, which has no deadline but has an end
Status as of 11 August 2026.
AngularJS (this kills Ionic v1 apps)
Support officially ended January 2022. Not winding down. Ended.
Source: AngularJS version supportIonic
v8 is active (released 17 Apr 2024). v7 ended 17 Apr 2025 · v6 ended 29 Mar 2024 · v5 ended 8 Dec 2022. Every Ionic below v8 is out of support today.
Source: Ionic support policyReact Native
Supported window is the current release plus the previous two minors. That is all. The New Architecture became the default in 0.76 (23 Oct 2024), and the legacy bridge architecture was frozen on 2 June 2025: no new features, no PRs accepted against it.
Source: The New ArchitectureFlutter
There is no published support window. Flutter’s compatibility policy covers breaking changes and a test registry. It does not promise support for any older version, and the team doesn’t remove deprecated APIs on a scheduled basis. Anyone who tells you Flutter supports N versions back is inventing it.
Source: Flutter compatibility policyObjective-C and Java for Android
Neither is deprecated. Apple has issued no deprecation statement. Google is Kotlin-first, which is a preference, not an end date. This is ecosystem drift, not end-of-life. The real cost is hiring and library availability, not a switch being turned off.
Source: Kotlin-first08. The thing we’re supposed to lie about
Apache Cordova is not dead, and almost everyone will tell you it is
This one costs us work, so read it carefully.
Nearly every agency selling app modernization, including agencies we compete with directly, will tell you Apache Cordova is dead, retired, or abandoned, and that you must migrate off it immediately. We sell Cordova migrations. It would pay us to agree.
It is not true. As of the day this page was checked, Apache Cordova was actively releasing:
| Release | Date |
|---|---|
| File Transfer Plugin 2.0.1 | 10 August 2026 |
| Cordova Android 15.1.0 | 22 July 2026 |
| Cordova iOS 8.1.1 | 7 July 2026 |
| Cordova Plugin InAppBrowser 7.0.0 | 16 June 2026 |
Source: cordova.apache.org/blog. The Apache Software Foundation’s own board report of 17 December 2025 describes the project’s community health as “strong”, with 100 committers and 97 PMC members. Cordova is not in the Apache Attic.
Where the story came from. Microsoft retired Visual Studio App Center’s support for Cordova. That is one company dropping one product’s support for it. It has been repeated so widely that it has become “Apache retired Cordova”, which is a different sentence and a false one.
So should you migrate off Cordova? Maybe. There are real reasons: the plugin ecosystem is thinner than it was, hiring is harder, and performance ceilings are real for some apps. Those are honest arguments and we will make them if they apply to you. But “it is dead” is not an honest argument, and if an agency opens with it, ask them for the source.
One genuine change worth knowing: Capacitor 9 was announced on 8 May 2026, and its headline is that “Cordova is now optional.” That is a real shift in the ecosystem around Cordova. It is still not a retirement.
Why now
Old code is fine until the day it blocks you
A framework going out of support breaks nothing on the day it happens. It breaks the next feature you try to ship. The criteria below are for judging where your app sits on that line.
09. How we decide, and how you check us
Migrate or rebuild: our criteria, published before we read your code
The fear here is obvious and it is correct: a rebuild bills more than a migration, so an agency has a reason to recommend one. A promise not to do that is worth nothing. A published rule is worth something, because you can hold us to it.
You get these five criteria before we look at anything. The audit report then shows you which ones your app passed and which it failed, with the evidence.
| # | We recommend a rebuild when | Why this one |
|---|---|---|
| 1 | The app cannot be built at all from the code you have: missing keys, missing dependencies, no working build machine | If it cannot be built, it cannot be migrated in stages. There is nothing to run side by side. |
| 2 | There are no seams. Business logic, UI and networking are one inseparable mass | Staged migration needs boundaries to migrate along. No seams, no stages. |
| 3 | The product it was built for no longer exists. You are keeping code for an app you have since redesigned twice | Migrating code nobody wants is the most expensive way to preserve a mistake. |
| 4 | A dependency at the core has no modern equivalent and no maintained fork | Sometimes the ceiling is under the floor. |
| 5 | Migration cost exceeds rebuild cost on the staged plan we hand you | This is arithmetic, and you get to see it. |
Fail none or one of these and we will tell you to migrate, in stages, and we will tell you which stage to stop at if the budget runs out. Fail three or more and we will tell you to rebuild, and we will show you the numbers rather than asserting it.
There is a third answer that we give more often than either: leave it alone. Plenty of apps are old and fine. If your app ships features at an acceptable speed, passes store requirements and does not crash, being written in an unfashionable language is not a business problem, and we will say so.
10. Start with the audit, not the migration
The Modernization Audit
Fixed price. Fixed length. Credited back in full against stage one if you continue.
| Field | Answer |
|---|---|
| What it costs | Fee needed |
| How long | 5 working days from the day we get repository access |
| What you get | The 4 to 6 page audit report in section 06, the staged plan with cost and time per stage, the written payback estimate, and the keep-or-rebuild verdict against the five published criteria |
| If you continue | The fee comes off stage one, in full |
| If you don’t | You keep the report. No follow-up sequence, no checking-in emails. |
| What we need from you | Repository access, or the app binary and store access if the code is missing. If the code is genuinely gone, that is App Rescue & Code Audit, not this page. |
Why we charge for it. A free audit has to be paid for somewhere, and it gets paid for by the recommendation. Charging a fixed fee and crediting it back means the verdict is not carrying a sales quota, and it means we can afford to spend five days actually reading the code instead of two hours skimming it to produce a proposal.
11. Ownership and exit
You own it. Take it anywhere.
The code is in your repository from day one. Not ours, transferred at the end.
The Apple Developer account, the Google Play account, the backend, the analytics: all in your name, on your billing. We hold access; you hold ownership.
30 days’ written notice. No minimum term, no exit fee.
If you leave mid-migration, you get a working app. That is what staged migration is for. You do not get half a rewrite and an invoice.
The handover is written and included: architecture notes, what was migrated and what was not, build and release instructions, credential list, known issues, and what we would have done next.
We will do a handover call with whoever takes over from us, including a competitor.
If we have to lock you in to keep you, we have already lost the argument.
12. The reason most people call now
Modernizing to make room for AI
This has become the most common reason clients start a modernization conversation, and it is a legitimate one.
Older apps were not built with any of this in mind. There is usually no clean API layer to call a model from, no structured event history to build on, no feature-flag system to release an AI feature safely to 5% of users, and no place to put the consent screen the stores now require. The AI feature is not the hard part. The three things underneath it are.
Doing both together is meaningfully cheaper than doing them a year apart, because the API layer, the event history and the release tooling are the same work either way. You either build them once for the AI feature or twice, once badly.
What we will not do is sell you a modernization on the promise of an AI feature you have not decided to build. If you know what the feature is, see AI Feature Integration & Assistants. The two pieces of work get planned together and priced together.
13. How we work to spec
| Standard | What it means |
|---|---|
| Staged, always | Old and new run side by side. You ship the whole way through. We do not take a product off the road for a rewrite. |
| Tests before the migration, not after | We write characterisation tests against the old behaviour first, so “nothing your users depend on is lost” is a checked statement rather than a hope. |
| A rollback plan per stage | Written before the stage starts. |
| Your data is migrated with a dry run first | On a copy, with a reconciliation count, before anything touches production. |
| Store requirements are part of the definition of done | A stage is not finished until the build passes review on current SDK requirements. |
| Accessibility is checked, not claimed | Contrast, dynamic type, screen-reader labels and focus order on the screens we touch. The European Accessibility Act has applied since 28 June 2025, with an exemption for microenterprises (under 10 staff and turnover at or below €2m). Confirm with a lawyer whether it applies to you. We could not open the official EUR-Lex text to verify the exemption wording. |
| One named engineer, and you know who | Not a pool. Continuity is the whole point on a multi-stage job. |
14. Industries we serve
Rows with no proof make no claim. That is a rule, not modesty.
| Industry | What we have done | Proof |
|---|---|---|
| Fintech & Banking | Wallets, payments, lending, KYC, crypto. Our strongest evidence and our highest-budget work. | 99.8% uptime and zero security incidents (Fidex Wallet) · settlement 72h to under 60 seconds, support tickets down 45% (QuickChain) · approval 35% to 89% (Hindustan Loan) |
| Retail, POS & E-commerce | Billing, inventory, invoicing, small-business POS. | Five platforms from one codebase · feature delivery +70% · merchant hardware cost down 80% (Vencru POS) |
| CRM, HR & Internal Business Tools | Sales, staff and workflow apps. The best fit for staged modernization, because internal users tolerate a staged rollout. | Admin time down 60%, errors down 95%, scaled 100 to 10,000+ parties (PM Fund Manager) |
| Events, Media & Community | Event, publishing and community apps across three platforms. | 70%+ code shared across three platforms · engagement +65% (Virtue Insight) |
| Energy & Utilities | Field and monitoring apps, integrated with systems the client already runs. | 45% faster lead-to-order · 99% asset tracking accuracy (Tata Power SolaRoof) |
| Legal-Tech | Case management, court data, document automation. Few agencies specialise here. | Case studies: ActivePass · DigitsLaw |
| Healthcare & Wellness | We want this work and we will take it. We do not have a published healthcare case study yet, so we are not going to imply one. | None yet, stated plainly on purpose |
| Real Estate & PropTech | Open to it. No case study yet. | None yet |
| EdTech & Training | Open to it. No case study yet. | None yet |
15. How the work runs
First call
What the app does, what is slow, what deadline you are facing. We tell you on this call whether you want this page or App Rescue. No charge.
Criteria sent
The five keep-or-rebuild criteria in section 09, in writing, before we have seen your code.
Modernization Audit
We read the code, build it, measure it, and write the report. Fixed fee, credited back.
The plan and the payback number
Stage list, cost and time per stage, and a written payback estimate. You can stop here and keep everything.
Stage zero: make it buildable and testable
Build machine, dependency update, characterisation tests, CI. Nothing user-visible. This stage is why the rest is safe.
Stage one: the first real migration
The module with the worst pain-to-risk ratio, migrated and shipped. Old and new side by side.
Stages two onward
One at a time, released as we go. You can stop after any of them and still have a working app.
Handover
Architecture notes, what was migrated and what was not, build and release instructions, credentials, known issues, and what we would do next.
What clients say
Brand-new frontend in record time.
Long and complicated project… executed it flawlessly.
Resolved crash of android version… in no time.
19. What we build with
We are not a Flutter shop. Flutter is what we use most, and it is not the answer to every migration. Native iOS and native Android are the right call often enough that pre-committing to a framework before reading your code would make our audit worthless.
21. Questions
Will our users lose their data or their accounts?
No. Their data and accounts stay exactly as they are. That is the point of migrating in stages rather than rebuilding. Before anything touches production we run the data migration on a copy, with a reconciliation count, and we write characterisation tests against the old behaviour first so that “nothing your users depend on is lost” is a checked statement and not a hope.
Is this cheaper than a rebuild?
Usually, and not always. The audit gives you both numbers on the same page: the staged migration total and an honest rebuild estimate, plus the five criteria in section 09 and which ones your app failed. If migration costs more than rebuilding, that is criterion 5 and we will tell you.
How do I know you won’t just say “rebuild” because it bills more?
Because you get the criteria before we read your code, and the report has to show you which one your app failed. You can disagree with the evidence. That is a much better position than disagreeing with an opinion.
How long does the whole thing take?
There is no honest answer to this before the audit. It depends on how many seams the code has, which is not visible from outside. What we can tell you is the shape: 5 days to the plan, then stages of 2 to 4 weeks each, releasing at the end of every one.
Can we stop halfway?
Yes, and this is the main reason we work in stages. After every stage you have a working, shipped app. You can stop after stage one, or stage four, and what you have is finished rather than half-migrated.
Is Cordova dead? We keep being told to move off it.
No. Apache Cordova was still releasing in July and August 2026, and the Apache Software Foundation’s own board report describes the project’s health as strong. What happened is that Microsoft retired App Center’s Cordova support, and that got repeated until it became “Apache retired Cordova”. There are real reasons to move off Cordova (a thinner plugin ecosystem, harder hiring, performance ceilings on some apps) and we will make those arguments if they apply. “It is dead” is not one of them. Full detail in section 08.
Our app is on an old React Native version. How bad is that?
Depends how old. React Native supports the current release plus the previous two minors, and nothing else. The New Architecture became the default in 0.76 (October 2024) and the legacy bridge architecture was frozen in June 2025: no new features, no fixes accepted. If you are on the old architecture you are not getting fixes, and each release you skip makes the jump bigger. This is the one framework where waiting genuinely costs you more.
What about old Flutter versions?
Flutter publishes no support window at all. Its compatibility policy covers breaking changes and a test registry, not support for older versions. So the question is not “is my version supported”, it is “how many breaking changes are between me and current”. The audit counts them.
Is Objective-C deprecated? Is Java for Android deprecated?
Neither. Apple has issued no deprecation statement for Objective-C, and Google’s “Kotlin-first” position is a preference rather than an end date. This is ecosystem drift, not end-of-life. The real cost is hiring (finding developers who will happily work in these stacks is harder every year) and library availability. Those are honest reasons to migrate. “It stops working” is not.
We have a Google Play deadline. Can you just fix that and nothing else?
Yes, and sometimes that is the right call. Getting to target API 36 is often a much smaller job than a modernization, and if that is all you need we will do that and tell you the rest can wait. The deadline is 31 August 2026, and an extension to 1 November 2026 can be requested in the Play Console.
Do you need our source code?
Yes, for this service. If the source code is missing or nobody can build it, you are on the wrong page. Start at App Rescue & Code Audit, which is written for exactly that situation.
Can you add AI features at the same time?
Yes, and it is normally the cheapest way to do it, because the API layer, event history and release tooling an AI feature needs are the same work the migration does anyway. What we will not do is sell you the migration on the strength of an AI feature you have not decided to build. Detail on AI Feature Integration & Assistants.
Who owns the code?
You do, from day one, in your repository. Store accounts, backend and analytics are in your name on your billing. 30 days’ notice, no exit fee, written handover included, and we will do a handover call with whoever takes over, including a competitor.
What if the answer is that we should leave it alone?
Then that is what the report says, and you have spent an audit fee to avoid spending a migration budget. It happens often enough that we put it in section 09 rather than leaving it as a surprise.
Tell us the problem. We bring the engineering.
A short call, an honest answer on whether we are the right team, and a scope you can hold us to.
Start a project