A troubled application does not automatically need a rewrite. It needs a decision based on what the business must keep, what is failing and whether the current system can be changed safely. A new codebase can be the right answer, but it also creates a second job: moving people, data and operations without losing the behaviour they depend on.
For a business taking over software from another supplier, the useful question is not “Is this code old?” It is “Which recovery path gives us dependable control and meets the business need, with an acceptable transition risk?” This guide explains how we would compare repair, staged modernisation and replacement.
First-hand observation
Kitek’s My Safety Buddy work involved picking up an existing web and mobile lone-worker safety platform, then continuing production support and feature development. It is a concrete example of carrying useful software forward through a change in engineering ownership. The options below are a decision framework, not a retrospective cost comparison for that project.
Separate the immediate rescue from the long-term decision
If production is unstable or the current developer is leaving, first establish control. Confirm ownership of repositories, hosting, domains, databases and third-party accounts. Preserve backups and the current release, identify who can deploy and agree how urgent incidents will be handled. Do not make a replacement programme the prerequisite for protecting the service that is running today.
The software application takeover checklist covers this handover in more detail. Once the essentials are secure, investigate the system before committing to a delivery approach. Missing documentation or a failed build is an important risk to resolve; neither alone proves that every part of the product must be replaced.
There are usually three options, not two
1. Rescue and maintain the existing application
Keep the core application and address the barriers to dependable operation: defects, release ownership, monitoring, tests, configuration or a concentrated area of fragile code. This is worth investigating when the application still meets the main business need and its significant risks can be understood and contained.
2. Modernise in stages
Retain useful workflows while replacing selected components or changing their boundaries. An integration, reporting process or difficult module might be separated before the rest of the system changes. The plan must specify which system owns each record and how old and new components will interact. Moving risk into an undocumented interface is not progress.
Our guide to modernising legacy software without a full rewrite explains the delivery sequence. In Kitek’s ongoing Metal100 marketplace work, maintenance and product development coexist across supplier catalogues, price lists, search, enquiries and tenders. Understanding those live workflows is part of deciding what a change needs to preserve.
3. Replace the application
Build or adopt a replacement when evidence shows that retaining the current system cannot meet essential requirements at an acceptable risk and cost. This might follow a technical investigation or a change in the business itself. Replacement still needs an interim support plan, data migration, acceptance testing and a controlled cutover.
What evidence should drive the choice?
Ask the engineering team to make the following visible. Separate confirmed findings from assumptions and unanswered questions.
- Business fit: which essential workflows work today, which fail and which new requirements are genuinely mandatory?
- Ownership and reproducibility: can the business obtain the source, build it, access the infrastructure and release a known version?
- Change risk: can a representative change be tested and released safely? Where are the difficult dependencies?
- Security and supportability: which components or access arrangements create unacceptable exposure, and can those risks be removed without replacing everything?
- Data and integrations: where do records originate, which systems depend on them and what would have to survive a migration?
- Operating cost: how much effort goes into incidents, manual work and routine changes? Use actual records where available.
A useful assessment does more than label the code “technical debt”. It identifies the constraint, the business consequence and the evidence for the proposed remedy. Where uncertainty is material, agree a bounded investigation or prototype before treating an estimate as a commitment.
Compare the whole transition, not just the build estimate
A rewrite proposal can look attractive if it includes only the new application. A rescue proposal can look attractive if it assumes every defect is isolated. Ask both proposals to include the work needed to reach an accepted, supportable outcome.
- Discovery: recovering undocumented business rules, permissions, reports and exception handling.
- Delivery: changes or replacement development, integrations, testing and release preparation.
- Continuity: supporting the current service while the work proceeds, including any parallel operation.
- Migration: data cleaning, mapping, reconciliation, rehearsals and treatment of historical records.
- Adoption: user acceptance, training, operational procedures and accountable sign-off.
- Exit: rollback or recovery arrangements, post-release support and retirement of the old system.
Compare options over the same business scope and planning horizon. Show ranges and assumptions, including what could change the estimate. A cheaper first stage is not necessarily a cheaper complete transition; a larger replacement budget is not proof of a better outcome.
When is a full rewrite justified?
Replacement deserves serious consideration when the current system fundamentally cannot support the required operating model, when unacceptable risks cannot reasonably be isolated, or when a credible comparison shows that continued repair would cost more than a controlled replacement. Sometimes an established product can replace bespoke software more sensibly than another custom build.
Before approving a rewrite, ask for a specific explanation of why staged change is insufficient. Require a migration approach, acceptance criteria and a plan for the existing service. “The framework is old”, “the code is untidy” and “a new team prefers a different stack” are starting points for investigation, not complete business cases.
What should the first paid stage produce?
The scope depends on access, urgency and the condition of the system. Rather than promising a universal recovery period, agree a small initial engagement with explicit outputs. A decision-ready assessment might include:
- A current-state map of the application, infrastructure, integrations, owners and critical workflows.
- A prioritised risk register distinguishing immediate operational issues from longer-term constraints.
- An options comparison covering repair, staged replacement and full replacement, with assumptions and unresolved questions.
- A recommended first delivery stage with acceptance criteria, dependencies, cost and turnaround agreed before it begins.
- A continuity plan explaining support ownership, release controls and how the business can recover if a change fails.
If the assessment cannot answer a major question, that should be visible. For example, a migration estimate is provisional until the team has inspected representative data and understood reconciliation requirements. The deliverable should help you decide what to authorise next, not disguise uncertainty as precision.
Questions to ask before approving the next step
Can a new supplier support code they did not write?
That is possible, but it requires onboarding and a review of access, dependencies, deployment and known risks. My Safety Buddy is a genuine Kitek takeover example. It is not a guarantee that every codebase can be supported on the same terms. Our software rescue and project takeover service starts with the current situation rather than assuming the answer.
Can feature work continue during modernisation?
Potentially. The roadmap should reserve capacity for essential support and select changes that do not create conflicting work in the same component. Some work may need to pause around a migration or a high-risk release. Make those trade-offs explicit instead of promising uninterrupted development.
How will we know the chosen approach is working?
Agree measures tied to the original problem: reliable completion of a critical workflow, fewer repeat incidents, a reproducible release, successful data reconciliation or less manual handling. These are suggested measures; establish a baseline before claiming an improvement.
Start with the problem, not a rewrite commitment
Kitek is based in Melbourne and works with businesses worldwide on existing web and mobile applications. We agree communication times and decision points around your team’s location. Start with a 20-minute, no-obligation software consultation. We will discuss the business impact, what access is available and a suitable next step. The scope, price and turnaround of any paid assessment or engineering work are agreed before it starts.
Explore software rescue and application takeover, legacy software modernisation or ongoing application support, depending on the problem you need to solve.