When a financial or compliance platform starts failing under a development vendor, the decision in front of leadership is rarely a technical one alone. Money has already been spent, clients and regulators depend on the system, and each release seems to introduce a new problem. A software project rescue is the structured way out: establishing what actually works, restoring stability, and choosing a realistic path forward without putting operations or compliance at risk.
This guide explains how to recognize a failing project, how to assess what you have inherited, and how to decide whether to stabilize, modernize, or rebuild. It also covers how to take over a project from another vendor, and how to keep audit trails and uptime intact while the work happens. The examples come from two recoveries VOLO has led for US companies in regulated sectors.
What is a software project rescue?
A software project rescue is the process of taking over a failing or stalled system, usually from a previous vendor or internal team, establishing what actually works, restoring stability, and setting a realistic plan to finish or improve it. Its first goal is business continuity, not new features.
A rescue differs fromlegacy system modernization, which improves a system that is still working as intended, and from a new build, which starts without inherited code, data, or obligations. In a rescue, the system is often already in production, customers rely on it every day, and the team taking over did not write it. That combination is what makes the work different, and it is why the order of decisions matters more than the speed of coding.
Warning signs of a failed software project
The clearest warning signs are releases that create new problems instead of fixing old ones, recurring outages, milestones that keep moving, and a codebase nobody can fully explain. When several appear together, the cause is usually structural, and adding developers to the same approach rarely changes the outcome.
Perr & Knight, a US firm that helps insurance carriers with regulatory filings, licensing, and actuarial analysis, showed nearly all of these signs across three core platforms after a previous offshore vendor:
- Every release carries risk. Routine updates introduce regressions, so the team ships less often and with more caution each time.
- The system fails in predictable ways. Crashes recur under normal load or in the same workflows.
- Growth exposes performance limits. Onboarding new clients slows down because of bottlenecks nobody has addressed.
- Users work around the software. Internal tools are hard enough to use that staff rely on manual steps instead.
- Technical debt has no owner. There is no credible roadmap, and nobody can say which problems matter most.
- Knowledge sits with the vendor. Documentation is missing or outdated, and only a few people outside your company understand the architecture.
The pattern is not unusual. Research byMcKinsey and the University of Oxford covering more than 5,400 IT projects found that large projects, those with initial budgets above $15 million, ran 45% over budget and 7% over time on average while delivering 56% less value than predicted (2012).
Why regulated platforms fail differently
Financial, insurance, and public sector platforms carry obligations that remove the easiest exit, which is to pause and start again. Filings have deadlines, audit trails must stay intact, and contracts often tie delivery to fixed dates. When Kofile, which runs records platforms for US county governments, found its flagship platform unstable and incomplete in 2014 after 18 months with another partner, a contract-bound launch was about three months away, so the recovery had to happen while delivery continued.
Start with an application modernization assessment
Before anyone estimates timelines or writes code, assess the system. A rescue that starts building before it understands what it inherited tends to repeat the original failure, only faster. The assessment should produce a baseline, a ranked list of risks, and a phased plan that leadership can approve.
Both recoveries in this article started this way. At Perr & Knight, a rapid technical assessment and architecture review revealed system-wide fragility and a lack of governance; at Kofile, business analysts, solution architects, and database specialists mapped risks and dependencies into a phased roadmap. The McKinsey and Oxford researchers recommend the same for large programs in general: a diagnostic of project health before deciding what to do next.
What a code audit and architecture review should cover
A code audit looks at the system as it is, while anarchitecture review looks at how its parts fit together and where they will break under growth. Together they should cover:
- Code quality and test coverage: how much of the system is tested, and how safely it can be changed.
- Architecture and dependencies: which components are tightly coupled, and which external systems the platform relies on.
- Infrastructure and deployment: how releases actually happen, and whether environments can be rebuilt reliably.
- Data model and integrity: whether the data can be trusted, migrated, and reconciled.
- Security and access control: who can reach what, and whether actions are logged.
- Documentation and knowledge: what is written down, and what exists only in people's heads.
Technical debt assessment: separate what blocks stability from what can wait
Not all technical debt deserves attention in the first months. The useful distinction is between debt that causes outages, data errors, or compliance gaps today, and debt that only slows future work. The first category belongs in the stabilization plan; the second belongs in the modernization roadmap.
Stabilize, modernize, or rebuild: how to decide
The constraint should decide, not preference. Stabilize first when operations are failing. Modernize in increments when the core business logic is sound. Rebuild an individual component only when it cannot be repaired economically, and avoid a full rewrite while clients, deadlines, and regulators depend on the system.
Kofile shows why the rewrite question matters. With the launch three months away, a "big bang" rewrite would have staked the contracts on an untested system, so core domains were separated behind clear APIs and services containerized step by step, without interrupting releases.
Once the immediate risks are under control, the remaining work stops being a rescue and becomes plannedlegacy application modernization. For banks working through the same choices on core systems, our guide tomodernizing legacy banking systems covers that planned path in more detail.
How to take over a software project from another vendor
Secure access and knowledge before the relationship ends. The most expensive transitions are those where the client discovers, after termination, that credentials, infrastructure accounts, or deployment knowledge remained with the outgoing vendor. Where the contract allows it, a short overlap period between the two teams reduces the risk further.
Before notice is given, make sure your company holds:
- Source code with its full repository history, not only the latest snapshot.
- Administrator credentials for every environment, owned by your company rather than by vendor staff.
- Cloud, domain and third-party service accounts registered in your company's name.
- Build and deployment pipelines, scripts and environment configuration.
- Database access, recent backups and evidence that a restore actually works.
- Architecture diagrams and existing documentation, however incomplete.
- Open defects, the backlog and a list of known workarounds.
- Third-party licenses and their renewal dates.
Intellectual property, transition assistance and termination terms vary from contract to contract, so have counsel review them before the conversation with the outgoing vendor. Regulated companies may also have obligations around how a vendor relationship ends, which the next section covers.
Protecting compliance, data and uptime during the rescue
Compliance controls have to keep working throughout the rescue, not be restored at the end. Audit trails, access control, logging, data retention and monitoring should be treated as fixed requirements in every phase, because a gap during the transition is still a gap when an auditor or regulator asks about it.
During Kofile's recovery, VOLO built secure audit trails, compliance-aligned access control, logging and retention, and centralized observability into the platform, and rehearsed data migration and rollback procedures before they were needed. At Perr & Knight, real-time telemetry on the filing platform let the team catch problems before users reported them.
For banks, and for the FinTech companies that serve them, a vendor exit is also a supervisory matter. The current USinteragency guidance on third-party relationships, issued by the Federal Reserve, FDIC and OCC in 2023, treats termination as one stage of the vendor life cycle. The agencies proposed a replacement in September 2026, and the 2023 guidance remains in effect until a final version is adopted. For how controls like these work day to day, see our article onsecurity governance inside an engineering organization.
A phased recovery approach in practice
Most successful rescues follow four phases: assess the system, stabilize what is failing, modernize or rebuild in increments, then operate and evolve the platform. The phases overlap in time, but their order should not change, because each one depends on the certainty created by the one before it.
- Assess. Establish a baseline, rank the risks, and agree on a phased plan with leadership.
- Stabilize. Fix what threatens operations, clients, and compliance, and add monitoring so problems surface early. For Perr & Knight's three platforms (StateFilings for compliance filings, License Reporter for state license tracking, and Exactuary for actuarial data processing), this meant refactoring unstable code, resolving critical bugs, and stabilizing key APIs, which ended the frequent outages.
- Modernize or rebuild in increments. Restructure or replace components one at a time while releases continue. At Kofile, small cross-functional feature teams worked in parallel, supported by QA automation and CI/CD (delivery and quality assurance), and the platform launched on schedule with its contracts preserved.
- Operate and evolve. Move from recovery to normal delivery, withongoing application support and a roadmap the business owns.
Both rescues became long-term partnerships. A team of more than 40 VOLO professionals now works as an extension of Perr & Knight, whose usage capacity has grown fivefold and whose StateFilings and License Reporter platforms are now SaaS-ready. Kofile's platform serves more than 700 jurisdictions and processes over 83 million transactions a year. The full stories are in thePerr & Knight andKofile case studies.
What to look for in a software rescue partner
Choose a partner that insists on an assessment before committing to estimates, has worked inside regulated systems, and can staff more than developers. A rescue tends to fail a second time when the new team repeats the habits of the old one: promising dates before understanding the code, and treating compliance as someone else's responsibility.
The qualities that matter most:
- Assessment before commitment. Estimates should follow evidence, not precede it.
- Experience in regulated environments. Audit trails, access control, and data integrity should be familiar territory, not new requirements.
- A cross-functional team. Business analysis, QA, and DevOps belong alongside engineering from the first week.
- Incremental delivery. Releases should keep moving while the platform is restructured.
- Transparency about risk, including what cannot be fixed quickly.
- Capacity to stay. A partner that leaves after stabilization takes the newly rebuilt knowledge with it.
For a broader checklist, see our guides tored flags in software development proposals andchoosing a FinTech development partner. VOLO's engineering teams are based in Yerevan; if you are weighing a partner outside the US, our overview ofsoftware development in Armenia covers time zones, talent, and collaboration.
Where to start
Every software project rescue begins with the same step: an honest assessment of what the system is, what it does reliably, and what threatens it. That assessment should end in a decision your leadership can act on, not in a sales proposal, and it should tell you whether to stabilize, modernize, or rebuild before anyone commits to dates.
If your platform is showing the warning signs described above,talk to our engineers about where it stands and what to fix first.
