Taking Over a Half-Finished Software Project: A 7-Step Assessment

Taking over a half-finished software project usually starts when the build is half done, thirty percent of the budget is spent, and the launch date is close. The most dangerous question at that moment is not how much rebuilding costs. It is that nobody can say whether what exists today actually works. Sometimes the client receives only a deployment package with the source held by the previous vendor. Sometimes the code is in hand but will not start, because database configuration and third-party keys are missing. Sometimes it runs, but every new feature breaks something, because the underlying structure was wrong from day one.

Over ten years Juhui Software has taken on a number of these half-finished projects, and has also handed over its own work complete. Below is an assessment method from the receiving side: examine first, then decide between continuing, refactoring or rebuilding — three options whose costs can differ by a factor of three.

1. Before anything else, inventory what you actually received

Do not start with the code. Start with assets. A complete software asset comprises seven items, and each missing one becomes a hidden cost later:

• Source code and version history: not only the final code but the git or svn log. Without history you cannot tell which code was a temporary patch.
• Database schema and data: DDL, field descriptions, index design, and whether real business data is included. Data without schema documentation is the worst case.
• Third-party accounts: cloud servers, domains, SMS, payment, maps, push, object storage. These are often registered under the previous vendor's account and are the most commonly missed item.
• API documentation: internal and external interfaces, including integration parameters for hardware, ERP and payment platforms.
• Deployment and operations documentation: environment requirements, deployment steps, scheduled jobs, log locations, backup policy.
• Design source files: the original Figma or Sketch files, not exported images. A redesign without source files means redrawing everything.
• Requirements and change log: the confirmed feature list and every change since. It is the only basis for judging what is still missing.

How many of these you obtain directly determines the difference in quotations. A project without source code is not a takeover; it is a rebuild, and should not be quoted as a continuation.

2. Four things to check in the code, without reading all of it

Nobody needs to read every line, and line count proves nothing. An experienced team usually spends half a day to two days on four checks:

Does it run. The most basic item and the one that most often fails. Pull the code to a local or test server, deploy per the documentation, and see whether it starts within a reasonable time. A failure to start usually reveals the real situation: missing dependencies, missing configuration, dependencies on discontinued runtime versions.

Is the architecture extensible. Look at three places: whether tables have clear business boundaries or dozens of fields piled into one table; whether business logic is concentrated in a few files or scattered inside page code; whether any layering exists. These decide whether a new feature takes two hours or two days.

Is there obvious technical debt. Hard-coded addresses and credentials, large commented-out blocks, database changes without version control, SQL embedded directly in pages. None of these is necessarily fatal, but each adds maintenance cost.

Test and documentation coverage. Automated tests, API docs, explanations of key flows. Low coverage does not require a rewrite, but it means every change is verified by hand.

3. Three options: continue, refactor, rebuild

Once the examination is done, the decision can be made by rule rather than by feel:

• Continue (lowest cost): sound architecture, acceptable code quality, missing only some features or some documentation. Best where the core path is already proven and what remains are peripheral modules. This is also where a new vendor's quote should be lowest.
• Refactor (medium cost): the product direction is right and the interface is usable, but the underlying structure blocks expansion — the typical signal is "every new feature requires changing five places." Refactoring keeps the business logic and data while rewriting the technical skeleton. It usually takes about half the original project's duration and must be staged; you cannot take the system offline for six months.
• Rebuild (highest cost): the code will not run, the architecture does not match the business, or no source code exists at all. In this case the old system is most valuable as a requirements document — its fields, flows and page structures are research already paid for, even if every line of code is discarded.

One indicator decides it: how long does a typical new feature take? A day means continue. A week touching many files means refactor. "It cannot be done, the structure will not support it" means rebuild.

4. How to structure the assessment engagement

The first contract when taking over a half-finished software project is not a development contract. It is a clearly scoped assessment. The reasonable form is a day-rate technical due diligence, typically three to ten person-days, delivering a report with the asset inventory, an architecture assessment, the risk list and a cost comparison across the three routes.

Skipping assessment and asking for "a number to carry on" is high risk: the quote can only rest on guesswork, and the outcome is either overrun or dispute. Spending a few thousand to twenty thousand RMB on an examination avoids a misjudgement worth hundreds of thousands.

5. Three legal and account checks before taking over

Beyond technology, three items must be confirmed before taking over a half-finished software project or the best engineering will not hold up legally:

IP ownership. Does the original contract state that source code and copyright belong to the client? If it grants a usage right rather than copyright, holding the code may not entitle you to have a third party modify it.

Third-party component licences. Does the system embed commercially licensed components — maps, reporting, push, OCR — billed annually? Do the licences transfer with the project, and who renews them?

Control of accounts and credentials. Is the domain in your name, can the server account be transferred, is the mini program or app registered to your company? These are administrative items, but they gate the launch and usually carry filing and review waiting periods.

6. Arranging the transition without downtime

If the old system is running in production, the worst approach to a transition is a single cutover. A workable sequence: the new team reads code and documentation first without touching production; then takes over the test environment and fixes several known defects to verify their understanding; then takes over one non-critical module in production; only then assumes full responsibility. The whole process typically takes four to eight weeks.

Require at least two weeks of transition support from the outgoing vendor, and write "who answers questions" into the handover agreement. Many failed handovers fail not on technical difficulty but because at the critical moment nobody could explain why an odd design existed.

7. A practical mindset

The easiest mistake when taking over a half-finished software project is the urge to dismiss the previous team's work. In reality, a system that has run in production for a year carrying real business data contains knowledge no document captures — which edge cases break, which customer has an unusual process, which interface times out — however ugly the code. Treating those as assets rather than liabilities raises the share of projects that can be continued rather than rebuilt, and brings the cost down with it.