Should you repair an abandoned project or rebuild it?
A stalled project does not automatically need to be thrown away. The right choice depends on what still works, what can be recovered and what your business needs next.
Understand the starting point
Before comparing estimates, review the available code, the live system, important accounts and recoverable data. Try building the available version on a separate test system and identify what prevents it from running.
If those basics are missing, an initial assessment may be more useful than a confident completion estimate. The missing-handoff guide and recovery inventory help prepare for that review.
Compare three practical routes
| Option | When it may be worth considering | What to include in the plan |
|---|---|---|
| Repair and finish | The available version runs, useful features work and the main problems can be traced to particular areas. | The repairs, unfinished features, checks for existing behavior and steps for releasing an update. |
| Replace parts in stages | Some parts work reliably while another part is difficult to support or no longer fits the business. | How old and new parts share information, which one controls each record and how to reverse a failed step. |
| Rebuild | The recovered system cannot reasonably support the required work, even after considering repairs or replacing individual parts. | The behavior to retain, data migration, connected services, changeover, training and ongoing running costs. |
Compare the same work in each estimate
A repair estimate and a rebuild estimate are difficult to compare if they cover different tasks. Include the important customer and staff actions, the data to preserve, outside services, accessibility, release work and handoff.
Ask which parts of the estimate are based on checked information and which depend on unknown work. Also ask what finding would change the recommendation. Replacing one unsupported service may be enough in one project, while missing usable source code may change the options in another.
Plan for the time between old and new
The existing system may still receive orders, messages or other records while changes are being made. Agree on where new information belongs, how it will be moved or reconciled and when the old system will stop accepting changes.
Test any data move on a separate copy. Check the records and relationships that matter to the business, rather than relying only on a successful import message.
Make the first stage useful on its own
The first stage should answer concrete questions or deliver an agreed improvement. It might establish which version is live, reproduce a build, restore one important task or show why a particular replacement is needed.
The age of the code or a claimed percentage complete cannot settle the decision on its own. Focus on what users need, what information must survive and what the business will need to maintain afterward.
Get a clearer recommendation before committing
Read about the project rescue assessment or describe the unfinished work. Bring the recommendation you have received and the questions it leaves unanswered.