Rescuing a Stalled Software Project: Switching Vendors Safely

The project started with enthusiasm. A schedule was agreed, a down payment was made, and the first demo looked promising. A few months later, progress updates grow rare, deadlines shift again and again, features said to be finished turn out full of bugs, and every question is answered with a promise for next week. This situation is more common than many admit, and it often leaves business owners unsure: continue, stop, or move to another vendor?

This article is a practical guide to assessing a stalled software project, deciding on the right step, and, if needed, switching vendors without losing the work already paid for. We cover warning signs, how to run an objective assessment, the decision options, preparing a handover, and how to keep the next project from repeating the same problems.

Summary

• Recognise warning signs early: progress that cannot be verified, deadlines that keep moving, and declining quality
• Before deciding, commission an independent technical assessment of the code, infrastructure, and documentation
• The options are not just continue or stop; there is joint recovery, rescue by a new team, or a partial restart
• Secure access to code, servers, domains, and third party accounts before the relationship with the old vendor deteriorates
• A rescue project succeeds when it focuses on stabilisation and realistic priorities, not on chasing the whole original plan

Signs a software project is in trouble

Problems rarely appear out of nowhere. There are usually small signs that, if recognised early, give you time to act. Watch for the following patterns.

• Progress is reported only as percentages or words, with no build of the app you can try
• Deadlines move repeatedly without a concrete explanation of the cause
• Features declared finished break again when other features are added
• You have no access to the code repository or do not know where the code is stored
• Vendor team members change often, and every newcomer needs everything explained from the start
• Technical questions get vague or deflected answers, and risks are never discussed openly
• Extra invoices appear without a clear change in scope

A single sign does not necessarily mean the project has failed. Every project experiences delays. What deserves concern is a combination of several signs that persists over time.

First step: secure your assets

Before making big decisions, and before conversations with the vendor become tense, make sure your digital assets are safe. This is not a hostile act but the ordinary prudence of any project.

• Source code: ask for repository access, or at least a complete copy of the code with its change history
• Infrastructure: cloud accounts, servers, and databases should be in your company's name, with administrator access in your hands
• Domain and certificates: make sure the domain is registered to the company and you hold access to the registrar
• Third party accounts: app stores, payment gateway, email service, maps, and other services the app uses
• Credentials: list every password, API key, and other secret, then plan to rotate them after handover
• Documents: requirements, designs, meeting notes, and any technical documentation that exists

Check the contract to understand the terms on code ownership, handover obligations, and how the engagement can be ended. If the contract is unclear, consult legal counsel before acting. This lesson is also why contract terms on ownership and handover deserve attention at the very start of any project.

Running an objective technical assessment

A good decision needs an honest picture of the project's condition. The assessment is best done by an uninvolved party, such as a technical consultant or a prospective new vendor, to avoid bias. An adequate assessment covers several aspects.

Code condition

Is the code well organised and understandable to other developers? Are there automated tests? Is the technology common and still supported? Are there dangerous practices such as passwords written directly in the code or obvious security holes? Bad code does not always have to be thrown away, but it affects the cost of continuing.

Functions that actually work

Compare the requirements list with what genuinely works in the test environment. Categorise each feature: finished and stable, present but problematic, or missing. The result often differs greatly from the progress percentage reports.

Infrastructure and release process

How is the app run, deployed, and monitored? Are there separate environments for development, testing, and production? Can the release process be repeated by someone else, or is it known only to one developer? Practices such as automated testing and CI/CD and observability are indicators of maturity.

Data and security

If the app is already in use, check the condition of the data, backups, and access security. Problems in this area must be handled first, whatever the next decision, because they pose a direct risk to the business and its customers. Also look for outdated third party libraries, as discussed in our article on software supply chain security.

Decision options

Based on the assessment, there are several paths you can take. Each suits a different situation.

Repairing the engagement with the old vendor

If the code is reasonably good and the main problem lies in communication or management, a repair can be attempted. Reset the priority scope, a verifiable demo rhythm, repository access, and clear benchmarks for the next few weeks. If the benchmarks are not met, you have a firm basis for the next step.

Rescue by a new team

If the code foundation is still viable but the old vendor is unable or unwilling to continue, a new team can take over. The new team usually starts by understanding the code, stabilising the problem areas, adding tests, then continuing features according to reworked priorities.

A partial or full restart

If the code is very poor, insecure, or built on technology that cannot be sustained, rebuilding can be cheaper in the long run. The decision is hard because it feels like throwing away investment, but the earlier work still has value: validated requirements, interface designs, and lessons about what did not work. Often the best choice is a mix, for example keeping the database and design while rewriting the most problematic parts.

Stopping or simplifying the project

Sometimes the assessment shows that business needs have changed or that packaged software now fits better. Stopping the project and moving to packaged software is not failure but a rational decision. The right question is not how much has already been spent, but which option gives the best result from this point forward.

Handing over to a new vendor

If you decide to switch vendors, an orderly handover saves a lot of time and money. Try to stay professional with the old vendor, because their cooperation during the transition helps greatly.

1. 01Agree on a handover schedule and a final payment tied to the delivery of assets
2. 02Receive the complete code with change history, database scripts, and environment configuration
3. 03Ask for a technical walkthrough from the old vendor's developers, ideally recorded
4. 04Transfer ownership of cloud accounts, domains, and third party services to your company
5. 05Rotate all credentials once access has been transferred
6. 06Ask the new vendor to verify that the app can be run and redeployed from the handed over code
7. 07Document the list of known issues and unfinished work

The verification step is crucial. Many handovers that look complete turn out to be missing configuration files, scripts, or manual steps that only the old developer knew. Make sure the new vendor can build the app from scratch before the relationship with the old vendor truly ends.

Running the rescue project

A rescue project differs from a new project. Its initial focus is stability and trust, not the speed of adding features.

• Stabilise first: fix critical bugs, secure the data, and set up basic monitoring
• Rework priorities with the business owner: which features are truly needed to launch
• Add tests to the parts that break most often before changing them
• Release in small pieces that can be checked regularly
• Report progress with real demos, not percentages

Communicate the rescue plan honestly to internal stakeholders. Explain the condition found, the new priorities, and the estimated schedule with its assumptions. Realistic expectations from the start are far better than optimistic promises that slip again.

Consider launching a leaner version first, then completing it gradually. An MVP approach helps a late project deliver value sooner while rebuilding the internal team's trust. Run user acceptance testing before launch so problems do not move on to customers.

Preventing the same problems from recurring

A stalled project is an expensive lesson. Use it to strengthen how you work with any vendor in the future.

• Hold access to the repository, cloud, domain, and third party accounts yourself from day one
• Ask for regular demos of a build you can try yourself
• Tie payments to verifiable results, not to elapsed time
• Appoint one internal product owner who is actively involved
• Start with a pilot project before handing over a large one
• Choose vendors with a [structured checklist](/checklist), not on price alone

If you are considering a vendor in another city or country, the same principles apply. Our guide to outsourcing software development to Indonesia covers engagement models and how to keep cross location projects transparent.

Conclusion

A stalled software project is not the end of the road. By securing assets first, running an objective technical assessment, choosing a path based on data, and carrying out an orderly handover, most of the investment already made can be saved.

Most important is to act early. The longer problems are left, the higher the cost and the harder the recovery. If warning signs are already visible, ask for an independent assessment now, while you still have plenty of options.