Improve or rewrite an existing application?

01

Distinguish taking over, redesigning and rewriting

An application that is slow, difficult to maintain or no longer convenient may call for several responses. Start by describing the problems: a failed action, a slow process, a change that cannot be delivered or an interface that no longer fits the business. The age of the technology does not explain their cause on its own.

Changing suppliers does not, by itself, require replacing the entire application. A UX/UI redesign can improve journeys while retaining some of the implementation. A rewrite may cover a component, the server or the whole product. Identify precisely what will be kept, changed or replaced to compare proposals.

02

Start with an audit of the product and its implementation

A useful audit connects technical findings to application journeys. It examines code, dependencies, environments, data, integrations and the process for releasing a change. It should also gather user difficulties and the changes your organisation expects.

Check that the team can prepare a working environment, run the application and understand how the live version is produced. Gather necessary access according to roles, available documentation, known incidents and operational accounts. If information is missing, record that absence and the resulting limits of the assessment.

Ask for evidence: a reproduced issue, a response time measurement, an identified dependency or a test journey. The deliverable should distinguish urgent work, possible improvements and unknowns to resolve. A defect list without consequences or priorities does not yet establish a direction.

03

When improving the existing codebase remains appropriate

Taking over the application deserves priority consideration when the product still supports essential usage, the code can be understood and problems can be located. Slow data access, confusing screens or insufficient tests can sometimes be addressed through targeted changes. Verify that possibility with an initial representative change.

Here, technical debt means the work needed to make changes more reliable and sustainable: clarifying a responsibility, updating a dependency, adding a test or documenting a rule. Its presence does not invalidate the entire codebase. Examine its practical effect on incidents, delivery time and product risks.

A first work package can combine a useful improvement with the necessary safeguards around that journey. Compare results with the initial state: behaviour, regressions, ease of delivery and the team’s ability to explain the change. If structural blockers remain despite this evaluation, reassess the direction.

04

Consider incremental modernisation

For a backend or web service, Microsoft’s documented Strangler Fig pattern replaces features in stages by routing requests to the old or new implementation. It requires identifiable boundaries and planned coexistence. It is not automatically suitable for every application.

For your project, first identify a scope that can evolve within understandable boundaries: a search function, a viewing area or a particular process. Describe exchanges with the remaining product and responsibilities for data. Demonstrate the separation in a concrete case before turning it into a migration schedule.

Coexistence also requires work: maintaining connections, testing exchanges and deciding when to retire the old part. Include this transitional effort in the comparison. An apparent division in the interface does not prove that rules or data can be separated in the same way.

05

When a rewrite deserves a full assessment

A rewrite may become appropriate when structural constraints prevent essential changes, technology can no longer be maintained acceptably or the product’s operation needs to change substantially. A small, clearly bounded application may also suit complete replacement. Compare these hypotheses with the work needed to retain and improve the existing implementation.

Define the new scope around usage to preserve and current needs. Some old features may no longer be useful; others contain implicit rules that users apply every day. Gather exceptions, permissions, calculations and exchanges before assuming that a screen describes all the required behaviour.

A rewrite budget also includes understanding the old product, migrating data, testing equivalence, transitioning users and keeping the service running during delivery. Funding a new codebase does not remove these tasks. Also specify what would trigger a reduction in scope or a revision of the decision.

06

Compare options using six practical criteria

For each option, identify known information, evidence gathered and remaining uncertainties. Compare the same expected service over a common horizon covering delivery, transition and maintenance. Avoid comparing an isolated fix with a new application that includes additional features.

The framework below organises tradeoffs. A blocking constraint must be addressed explicitly; an average score cannot cancel it out. The following situations are fictional illustrations, not client results.

07

Prepare migration and cutover conditions

Start with data: information to migrate, relationships, documents, permissions and history. Run trials in a suitable environment, verify mappings and define acceptance criteria. An available backup should be accompanied by a restoration test; its presence alone does not establish readiness to restore service.

Plan for changes during the transition: which system records a new request, how losses or duplicates are avoided and how information is reconciled after a failure. Returning to the old version may require handling data already created or changed. Test this procedure and assign responsibility for it.

For services that support it, Google SRE describes a deployment limited in time and to a subset of users, evaluated before wider rollout. Define signals to observe and stopping conditions. This mechanism complements testing performed before the service goes live.

Mobile needs particular attention: Google Play explains that halting a staged rollout does not remove the version already received by affected users. Plan compatibility with the server and how an installed version will be fixed. A mobile application cutover therefore differs from a website cutover.

08

Define a useful first intervention with Gaspa

An initial intervention should create an actionable understanding of the application: an assessment, priority risks and reasoned options. If technical uncertainty determines the choice, plan a targeted trial. You can then define a first work package, its acceptance criteria and ongoing support arrangements.

Gaspa supports UX and technical audits, application redesign and maintenance. Hummingbird illustrates a modernisation assignment: UX/UI redesign, iOS and Android development, a back office and store publication. This reference documents delivered scope; it cannot establish the right technical path for another application.

The expected deliverable is a decision your team can understand: what stays, what changes, transition conditions and responsibilities after delivery. The application should be able to evolve with shared access arrangements, documentation and quality criteria.