Taking Over a Stalled Software Project From Another Vendor: Stabilise First, Then Deliver

The launch date has moved for the third time. Updates from your current vendor have become vague, and every new release seems to break something that used to work. You know the project needs a new team, but you are worried that switching will simply restart the same cycle.

You are not alone. In a study of more than 5,400 IT projects, McKinsey and the University of Oxford found that large IT projects run 45 percent over budget and 7 percent over time on average, while delivering 56 percent less value than predicted.

The good news is that a stalled project can be recovered. But when you take over a software project from another vendor, you cannot treat it like new development. The fastest route back to delivery is to stabilise first, then deliver.

This guide explains how to approach a takeover the right way, so you can turn a stalled project into one that delivers again.

Signs Your Software Project Has Stalled and Why a Takeover Needs a Different Approach

Before deciding how to recover a project, it helps to be honest about where it stands. Most stalled projects show the same symptoms, and recognising them early makes the case for change much easier to put to the board.

Warning signs that a project has stalled

• Repeatedly missed deadlines with no credible revised plan. The team has usually lost control of the scope or of the codebase itself.
• No documentation, or documentation that no longer matches the code. Critical knowledge lives only in the previous developers’ heads.
• Unstable code. Fixing one bug creates two more, and production incidents keep coming back.
• Nobody can explain how key parts of the system work, including the business logic behind important calculations or workflows.
• Budget keeps burning while visible progress stays flat.
• The vendor is slow to respond, or key developers have left the project.

If several of these signs sound familiar, the project needs a recovery approach, not more of the same.

Why taking over a project is different from new development

A new team that takes over a stalled project inherits decisions, shortcuts and technical debt it didn’t create, and often can’t see at first.

In new development, the main risk is building the wrong thing. In a takeover, the main risk is breaking what already works, because there are usually no tests and little documentation to show what “working” actually means.

Because the risks are different, the first priority has to be stability, not speed.

How to Take Over a Software Project From Another Vendor: A Step-by-Step Approach

A successful takeover runs in a deliberate order. Each step reduces the risk of the next one, and skipping ahead to new features is the most common reason takeovers fail a second time.

Secure access → Assess → Prioritise → Test baseline → Stabilise → Process and quality control → Recover and deliver

Each step covers why it matters to the business, what the team actually does, and what the client receives at the end.

Step 1 – Secure access and ownership before day one

This step is often overlooked, yet it decides whether a takeover is smooth or painful. Before the new vendor writes a single line of code, you need full control of everything the project depends on. Without it, the new team is working blind, and the old vendor still holds the keys.

Make sure you have secured:

• Source code repositories, including the full commit history
• Hosting, servers, cloud accounts, databases and backups
• Domains, DNS, SSL certificates and app store accounts
• API keys, credentials and licences for third-party services
• Contract terms covering IP ownership, handover obligations and notice periods

One rule matters above all: don’t terminate the old contract until you have confirmed access to everything on this list.

Step 2 – Run an initial assessment of what you’ve inherited

The assessment replaces guesswork with facts. Its purpose is to give you an honest picture of the project’s condition before anyone commits to new timelines or costs. A good assessment covers seven areas, each answering a question the business needs answered.

Technical debt deserves particular attention. The Consortium for Information & Software Quality (CISQ) estimated that accumulated software technical debt in the US had reached approximately $1.52 trillion in 2022, and it identified technical debt as the largest obstacle to making changes in existing codebases (Synopsys).

The outcome of this step is a project health report: a red, amber or green rating for each area, the main risks and the recommended next steps. It gives everyone, from engineers to the board, the same view of where the project really stands.

Step 3 – Analyse and prioritise issues

A stalled project usually has issues scattered across emails, spreadsheets, chat messages and old tickets. Nobody knows the true total, and everything feels urgent. This step turns that chaos into a clear, agreed list.

• One central issue tracker becomes the single source of truth for every bug and request.
• Reproduce every bug and find the root cause, so the team fixes causes rather than symptoms.
• Prioritise by business impact, ranking revenue, customer experience, compliance and operations above cosmetic issues.
• Separate bugs from enhancements, so scope creep can’t hide inside bug fixing.
• Agree priorities with the client, so both sides share the same expectations from the start.

When everything is urgent, nothing gets fixed. Prioritising by business impact puts the team’s effort where it matters most.

Step 4 – Build a testing baseline before changing code

Without tests, every change to an unstable codebase is a gamble. Tests create a safety net, so the team can fix problems without breaking other parts of the system. That is why testing comes before stabilisation, not after.

• Unit tests for critical functions such as pricing, payments, permissions and calculations
• Automated regression and integration tests to confirm that existing features still work after every change, and that connected systems still talk to each other
• Browser automation for key user journeys such as login, checkout and core workflows, testing the system the way real users use it.

If your team lacks the capacity to build this baseline, Arestós’s QA and testing services can set it up alongside your developers.

Step 5 – Stabilise the system before adding new features

This is the heart of the takeover. Stabilisation means making the existing system reliable before anything new is built on top of it. It can feel slow, but it is what makes later delivery fast and predictable.

• Fix critical bugs and performance issues first, starting with those that affect users or revenue.
• Refactor problem code with targeted improvements to the worst areas. This is not a full rewrite.
• Improve error handling, logging and monitoring, so problems are caught before users report them.
• Apply security fixes, patching outdated dependencies and closing the vulnerabilities found in the assessment. The OWASP Top 10 is a useful reference for the most critical web application security risks.

Stabilisation often means a temporary feature freeze, which can be a hard message for the board. It helps to frame it correctly: the freeze isn’t a pause in progress. It reduces risk and protects the investment already made, so that new features are delivered on a foundation that won’t collapse.

Step 6 – Put process and quality control in place

A project rarely stalls because of one bad developer. It stalls because the process around the code is missing. This step ensures the project doesn’t end up back in the same place, whoever works on it next.

Good process also protects you from ever being locked into a single vendor again.

Step 7 – Recover the plan and resume delivery

Only once the system is stable and protected does the focus shift back to delivery. The aim now is to rebuild stakeholder confidence with a plan that is realistic, visible and kept.

• A recovery plan and roadmap based on the assessment findings, not on the original optimistic timeline
• Clear milestones, plus early quick wins that show visible progress within the first weeks
• Realistic timelines with buffers for the unknowns that remain
• Regular, transparent progress updates such as weekly reports, demos and a shared dashboard
• Feature development resumes once the agreed stability criteria are met

Buyer’s Checklist: Before You Switch Software Vendors

Step 1 covers what the new vendor needs on day one. This checklist comes earlier: it helps the reader decide whether they are ready to switch, and which vendor to trust. The risk level shows what each gap means for the takeover.

How to read the risk levels: a Blocker must be resolved before giving notice to the old vendor. A High risk should be settled before signing with the new vendor. A Medium risk can be agreed during the first weeks of the engagement.

Still deciding how to structure the new engagement? Our guide to offshore IT staffing vs IT outsourcing compares the two models.

Why Choose Arestós to Take Over Your Stalled Project

When a project has stalled, Arestós follows the same stabilise-first approach described in this guide: we find out where the project really stands, make it reliable, and only then move delivery forward.

• An honest assessment first. We review your code, architecture, security and integrations, then give you a clear picture of the risks and the right next steps before any new commitments are made.
• Quality built into every release. Automated testing, code review and reliable deployment processes keep your system stable long after the takeover is complete.
• Broad hands-on experience. From corporate websites and e-commerce platforms to Odoo ERP solutions and custom business software, our engineers know the systems Hong Kong businesses rely on.
• Extra capacity when you need it. If recovery needs more hands, our offshore IT staffing model adds pre-vetted engineers who join your team, work in Hong Kong business hours and follow your processes.
• Transparent progress from week one. Regular updates and demos keep your stakeholders informed and confident at every stage.

Whatever state your project is in today, Arestós can help you stabilise it, rebuild trust in the plan and get delivery back on track.

Frequently Asked Questions

1. How long does a project takeover take?

It depends on the system’s size and condition. Break the answer down by phase (assessment, stabilisation, recovery) using Arestós’s typical ranges [to be confirmed].

2. Do we need the old vendor’s cooperation?

It helps, but it isn’t essential if you own the code and have full access (see Step 1). Without it, the assessment simply takes longer.

3. Should we rebuild or fix the existing system?

Fixing is usually faster and lower risk. A rebuild only makes sense when the architecture or tech stack can no longer support the business, and that decision should come from the assessment.

4. How much does it cost to take over a software project?

Cost depends on project size, code condition, documentation and urgency. An assessment gives the most accurate estimate.

5. Can we keep the old vendor during the transition?

Yes, a short overlap with knowledge-transfer sessions reduces risk ((see checklist item B3), though a clean break is sometimes better if the relationship has broken down.

Conclusion

A stalled software project can be recovered, but the speed of recovery depends on stability, not on rushing new features. Secure your access, assess what you’ve inherited, prioritise by business impact, build a testing baseline and stabilise the system. Only then put process in place and resume delivery with a plan your stakeholders can trust.

If you recognise your project in this article, the first step is an objective view of where it stands.

Book a free project health check with Arestós. Our team will review your codebase, identify the main risks and recommend a clear next step, with no obligation.