Repair, modernise or rewrite your mobile app?
Compare repair, staged modernisation and a rewrite using evidence, transition effort and risks to users before choosing a mobile app investment.
Choose the smallest change that the evidence shows can meet your product’s needs, while accounting for the effort and risk of the transition. A targeted repair may be enough. A constrained module may need replacing, or the evidence may support a full rewrite. Sometimes the right decision is to defer the change until a specific unknown has been resolved.
Four valid paths
The app’s age, the identity of its original supplier or the use of AI to write code does not, by itself, establish that a rewrite is needed. Start with the user journeys at risk, the state of the product and the constraints on changing it. Then compare options on the same evidence.
Repair means a bounded change to address an identified problem while retaining the surrounding product. It is a candidate when the defect can be reproduced, its boundaries are understood and the existing system can support a safe change. A working fix still needs an agreed way to verify it and to release it.
Modernise means changing selected parts of the product in stages. This may include replacing a module or changing an integration while keeping other working parts. It is a candidate when the problem extends beyond one defect but useful boundaries exist, or can be established, between the part being changed and the rest of the system. A module replacement is not the same decision as replacing the whole app.
Rewrite means replacing the product rather than just a bounded component. Consider it when evidence shows that alternatives cannot meet essential requirements within acceptable constraints. Compare the effort of recreating and transitioning the product, including the less visible work of moving users, data and operational responsibilities. A new codebase does not automatically remove product or integration risks.
Defer and gather evidence when a consequential question remains unanswered. Deferral should name the question, its owner and how it will be resolved. For example, reproduce a failing journey on an agreed build, establish who controls release accounts, or test whether an API boundary can support a proposed module change. Decide what finding would change your choice. This does not mean leaving an active incident without a response.
Build an evidence matrix before choosing
Use the same matrix for each option. The rows are prompts for investigation, not points in an automatic score. Mark an item unknown when evidence is missing, and record who will resolve it. Record remaining risks and who accepts them.
| Dimension | Evidence to gather | Decision question |
|---|---|---|
| Affected user journey | Steps, affected users and the observed consequence for a critical task. | What must improve, and what must continue working? |
| Reproducible defect | The build, conditions and steps that reproduce the issue, plus relevant observations. | Is the problem bounded enough to investigate or repair? |
| Build and release reproducibility | A repeatable build, release instructions, signing and account ownership. | Can the team safely produce and release a change? |
| Dependency and support constraints | Versions in use, documented constraints, known compatibility concerns and alternatives. | Which dependencies limit the available options, and which claims still need checking? |
| Test coverage | Existing tests, manual checks and gaps for the affected and neighbouring journeys. | How will the team detect a regression? |
| Data and API boundaries | Data flows, contracts, integrations and ownership, including what is not documented. | Can the affected part change without disrupting other systems? |
| Team ownership | Access, product knowledge, responsibilities and the people able to operate the product. | Who can make, review and support the change? |
| Rollout and rollback | Available release controls, recovery options, dependencies and decision owners. | How could a change be introduced and what happens if it fails? |
| User and account continuity | Account, identity, consent, stored data and support dependencies relevant to the app. | What must remain available to users through the transition? |
Evidence may point in different directions. A local defect can coexist with an unreliable release process. A difficult dependency alone does not prove the whole product must be replaced: check its reach and the options for changing it.
Compare the whole transition, not just the build
A proposal that describes implementation alone is incomplete. Ask each team to compare the same activities, explain assumptions and identify what remains unknown. Include work done by your own people and dependencies on suppliers. Use the worksheet below without treating blank cells as zero.
| Effort or obligation | Targeted repair | Staged modernisation | Full rewrite |
|---|---|---|---|
| Discovery and evidence gathering | To be determined | To be determined | To be determined |
| Implementation | To be determined | To be determined | To be determined |
| Parallel running, if needed | To be determined | To be determined | To be determined |
| Testing and regression checks | To be determined | To be determined | To be determined |
| Data and integration migration | To be determined | To be determined | To be determined |
| Store rollout and release preparation | To be determined | To be determined | To be determined |
| Support and incident response during transition | To be determined | To be determined | To be determined |
| Recovery or stopping a failed change | To be determined | To be determined | To be determined |
| Opportunity cost and deferred product work | To be determined | To be determined | To be determined |
| Ownership, access, handover and future maintenance | To be determined | To be determined | To be determined |
For each cell, record the basis for the estimate, the owner and any dependency. A small repair may depend on inaccessible release infrastructure; a rewrite may require substantial work to reproduce existing behaviour.
Plan the transition before committing to it
A phased approach can reduce the amount changed at once, but it is not automatically possible for every app. Before proposing one, check whether the relevant module has a usable boundary, how it communicates with the rest of the product, and whether data and account states can remain consistent. Identify the tests and environments available, the release authority and the support team’s ability to handle mixed states.
For cutover, agree what moves, how to check success, who can proceed, what users may experience and how issues will be reported. Establish which recovery or rollback options are feasible; record unresolved questions in the plan.
A hypothetical example
This scenario is invented to illustrate the decision. It does not describe a GMI project or result.
A shopping app owner receives a rewrite proposal after users report delays when opening the basket. At first, there is no repeatable scenario and the team cannot connect the repository to the version in use. The next step is to establish the version, reproduce the problem and examine the data flow. The symptom alone does not justify a rewrite.
If investigation identifies a bounded error in handling an API response, and the surrounding journey can be verified, a repair becomes an option to compare. If the basket module also needs replacing, examine its boundaries and compatibility with the rest of the app. That opens a comparison with staged modernisation.
A full rewrite remains an option if evidence shows the required behaviour cannot reasonably be retained with a smaller change. It still requires comparison of the whole transition. None of these findings is established before the app is examined.
When an audit helps
An audit is useful when an existing app or codebase has material unknowns and a team needs evidence to decide whether to release, repair or modernise. GMI’s mobile app code audit covers React Native and Expo by default, including stability, performance, technical security risks, maintainability and critical flows. Its decision pack includes evidence, prioritised risks and an ordered action plan. Backend and other technology stacks need a separately confirmed scope. Repairs and retesting are separate work.
A further audit is not mandatory if your team already has enough reliable evidence, ownership and an agreed decision process. Use the matrix to document the choice and move to a scoped plan. For a delivery discussion once that decision is supported, explore mobile app services. An audit of existing code is also not the starting point for a product that has no existing app or codebase.
If ongoing ownership is the immediate concern, see mobile app maintenance.
For the continuing work involved in a particular stack, read React Native app maintenance costs.
If the question is whether an AI-built app is ready for production, use the separate production-readiness checklist.
Decide with evidence
If the missing evidence concerns an existing React Native or Expo app, describe your product and the decision you need to make. GMI can first confirm whether the audit fits and agree the scope.
Frequently asked questions
- Is instability the same as an unsupported dependency?
- No. Instability is an observed behaviour; a dependency constraint is a possible risk or contributing factor. Reproduce the problem and investigate the relevant evidence before treating either as the cause or choosing a remedy.
- Can we preserve the parts that already work?
- Possibly. Map their boundaries, integrations and tests first. A repair or staged change may retain them, but the team must check the effect of changes and how the retained parts will be supported.
- Should we rewrite when changing supplier?
- A supplier change alone is not a technical diagnosis. First establish access to the code, builds, accounts, documentation and the people responsible for release and support. Then assess the product and any gaps that affect a safe handover.
- How should we compare two rewrite proposals?
- Ask both suppliers to use the same scope, acceptance criteria, assumptions and transition worksheet. Compare what each will preserve, recreate, migrate, test and support, and identify exclusions and unknowns. Request the evidence behind any claim that a smaller change is unsuitable.
- What if we cannot gather enough evidence?
- Name the missing evidence and its potential impact, assign an owner and agree a bounded next investigation. If it cannot be obtained, document the limitation and decide who can accept the remaining risk. An unknown is not proof that a rewrite is necessary or safe.
Content updated: November 4, 2026
Google Preferred Sources
See GMI more often in Google
Add gmi.software as a preferred source. Google may highlight our new articles more often in Top Stories and supported AI experiences.