The decision to save or restart a software project is rarely made on the drawing board. More often than not, it arises under tight deadlines, with a team that has been working overtime for months and a management team that wants answers. That is precisely what makes it dangerous.
A software project can be salvaged if tests are in place, the architecture separates modules, and the data model at its core aligns with the business processes. Starting from scratch is the right approach in cases of total technological failure or an architecture that cannot be expanded. The following factors should be evaluated: seven criteria, and the question of the goal always comes before the technical question.
The Question That's Asked Too Late in a Software Project
People who make decisions under pressure tend either to cling to a dead project because so much has already been invested in it, or to throw everything overboard even though most of the work could still be salvaged. Both mistakes cost time and money. They can be avoided if the decision is based on a set of criteria rather than on the prevailing mood in the room.
Seven Criteria for Decision-Making in a Software Project
A sound judgment requires answers to seven questions, each of which should be evaluated independently.
- Code quality. How much of the existing code has been tested, documented, and is understandable to someone who didn't write it themselves? A system without tests isn't automatically worthless, but every change made to it becomes a risk.
- Architecture. Can parts of the system be replaced, or are all the components inextricably linked to one another? A monolithic structure isn't a death sentence, but it does limit how effectively individual vulnerabilities can be addressed.
- Data model. Does the data structure reflect the actual business processes, or has it been hastily expanded several times over the course of the project? A distorted data model can be fixed. It just often costs more than redeveloping the affected part from scratch.
- Team Knowledge. Who on the team still fully understands the system? When there is high turnover during the course of a project, this number drops faster than the organizational chart indicates.
- Remaining budget. How much is left, and how much would a modernization realistically cost compared to building something new? A rough estimate of the effort required for both options would be helpful here—not just wishful thinking.
- Schedule. Is there a deadline that cannot be moved, for example because a legacy system is being switched off on a fixed date? Such a deadline changes the calculation considerably.
- Contractual situation. What does the contract with an external service provider stipulate regarding acceptance, remedial performance, and termination? This question often determines which options are legally and economically available.
| Criterion | Arguments in Favor of Rescue | Arguments in favor of a fresh start |
|---|---|---|
| Code Quality | Tests are in place; code is readable | No tests; no one understands the logic |
| Architecture | Modules can be replaced individually | Any change affects the entire system. |
| Data Model | reflects the core processes | expanded several times in a makeshift manner |
| Team Knowledge | Several people are familiar with the system | Knowledge has been lost along with the departures |
| Technology | Will continue to be maintained; developers are available | Language or database without support |
| Remaining budget | is sufficient for targeted repairs | It's only enough for a partial scope anyway |
| Deadline | adjustable | Cutoff Date Due to the Shutdown of a Legacy System |
Saving or Restarting a Software Project from a Technical Perspective
Modernization is worthwhile if the codebase is solid—that is, if tests exist, the architecture separates modules, and the data model fundamentally aligns with the business processes. Building from scratch, on the other hand, is the right choice when the technology is completely obsolete—such as a programming language or database that is no longer maintained—or when the architecture is fundamentally incapable of being extended (CodeGuides, 06/2026).
This rule sounds simpler than it is in practice. Most projects fall somewhere in between; they rarely fall at either extreme—such as a solid core architecture with two or three modules that are technically obsolete. In such cases, a partial rescue is often the right approach, in which core components remain intact and individual, clearly defined areas are rebuilt. The 6R Model for Legacy Systems provides the intermediate steps for this.
Why Unclear Goals Are More Often the Problem Than Poor Code
of project failures go back to unclear goals, not to technical quality. Neither modernisation nor a fresh start helps as long as that goal is missing.
ODCUS, February 2026
This is a key consideration when deciding on a solution. If no one can specify exactly what the system is ultimately supposed to achieve, both approaches will pursue the same undefined goal and eventually fail at the same point. Therefore, a decision regarding the project’s scope must be made before any technical decisions are made. There needs to be a shared, written understanding of what the project is supposed to deliver. If this is missing, it’s the first item on the list—not the choice of technology.
The Pitfall of Hiring a Replacement
One pattern often makes the decision even harder: the hasty hiring of a new technical leader in the midst of a crisis. A hasty new CTO hire can set a software project back by 12 to 18 months (Raphael Bauer, 05/2026), because a new executive must first understand the system, the team, and the political dynamics within the company before they are even capable of making decisions. This onboarding period occurs precisely during the phase when the project has the least time.
Those who, instead, first clarify the issue of rescue or a fresh start with temporary external support gain time without having to commit immediately to a permanent appointment. The article describes how such an assessment of the situation is developed The First Project Crisis.
Seven criteria, one well-reasoned recommendationWe evaluate the codebase, the contract, and the team's expertise, and provide a cost estimate for both options—not just the one that benefits us.
How long the evaluation should take
A comprehensive evaluation of all seven criteria can be completed in one to two weeks for medium-sized software projects, provided there is access to code, contracts, and the team from the outset. If access is granted piecemeal—for example, because a previous service provider is reluctant to fully open its repositories—the assessment drags on, and with it, the uncertainty within the team. A clear timeline, communicated to all stakeholders, prevents a two-week review from turning into months of uncertainty.
Ideally, the end result will be a well-reasoned recommendation backed by numbers: the estimated cost of modernization versus new development, the residual risk in both cases, and a clear statement on which option is realistic given the available budget. A simple yes-or-no answer without these numbers will be nearly impossible to understand six months later.
Frequently Asked Questions
How can we make the decision between saving and restarting an objective one?
Through an independent evaluation of the seven criteria—code quality, architecture, data model, team knowledge, remaining budget, schedule, and contractual status—ideally conducted by someone who has not been involved in the project to date. A point-based evaluation for each criterion makes the decision transparent and prevents personal attachment to the existing system—or frustration with it—from skewing the evaluation.
What can actually be salvaged in a fresh start?
Usually more than expected. A functional data model, documented expertise in business processes, individual stable modules, and—above all—the team’s knowledge of past mistakes can all be carried over to a new project. A fresh start rarely means starting from scratch.
Who should make the decision?
The technical assessment should be provided by an independent individual with technical expertise. The decision itself should be made at the level responsible for the budget and deadlines—usually jointly by senior management and the IT department. A Interim CTO can fill both roles on a temporary basis: evaluation and implementation support.
The Next Step
With this decision, torck assumes responsibility for the ongoing project, going beyond a purely external consulting role. Technical leadership and implementation are then handled by a single entity, supported by in-house development teams in Maxhütte-Haidhof, Vienna, and Rabat. Schedule a no-obligation initial consultation, in order to categorize the codebase and options together.
German 
English 
French