You Own Tech From a Past Acquisition You No Longer Use

Acquisitions often have a quiet second act. The buyer wanted the team, the customers or the market position, migrated the users to its own platform within a year, and switched the acquired product off. The code stayed: in a repository nobody opens, on the balance sheet as an intangible asset, and in the security team’s scan reports. If the product earns nothing today, Odys AI Labs, the research and development arm of Odys, can buy that code for cash for AI training and R&D.

What your code is likely still worth

Acquired code often scores well. It was usually a complete product with paying customers before the deal, built by a team good enough to be acquired, and the due diligence for the original acquisition probably produced an inventory of repositories, contributors and open-source licenses. Black Duck’s audits, for example, covered 947 commercial codebases and 197 M&A transactions in its latest report; scans like that are routine in software deals, and if one was done for yours, it is a useful starting point now.

Suppose a payments company bought a small invoicing startup in 2021, moved its customers onto the parent’s billing platform within a year and switched the startup’s product off in 2022. The startup’s five repositories, with four years of history, a Go API, a React app and a full test suite, still sit in the parent’s GitHub organization under an archived team. Nobody has committed to them since. As an illustration, that is exactly the kind of idle, complete codebase this page is about.

Its history is often its strongest feature: years of the original team’s commits and pull requests, followed by the integration period after the deal. Our guide to what companies can do with the code of retired products covers the internal decision in more detail.

We do not publish price figures, and the price your company paid in the acquisition does not set ours: the offer typically follows a review of the code itself. How we value a codebase is explained on the call.

What a buyer will check

• Chain of title. From the original developers to the acquired company, and from there to whoever owns it today.
• Deal terms. Any licenses, escrow arrangements or restrictions that came with the acquisition.
• Integration. Which parts were folded into current products and which are truly unused.
• Revenue. Confirmation that nothing tied to the code is still billed.
• Cleaning. Secrets, customer data from the acquired company’s users, and live infrastructure details.

Three risks specific to this situation

1. Gaps in the chain of title. You can only sell what you own, and with acquired code, ownership passed through at least two steps. First, did the acquired company own its code? Founders who wrote it before incorporation and contractors without written assignments are common gaps; in the US, a transfer of copyright needs a written, signed document. Second, where are the rights now: in a surviving subsidiary, merged into the parent, or left in an entity that was later dissolved? The due diligence file from the acquisition usually answers both. This is not legal advice; your counsel should confirm the chain before you sign anything.

2. Obligations that came with the deal. Acquisition agreements and the acquired company’s customer contracts can outlive the product: a license back to the founders, a source code escrow for a large customer, a partner’s right of first refusal, or confidentiality terms covering third-party code. Read the deal documents and any surviving customer agreements before offering the code. Our guide on what is in a source code purchase agreement explains what the new agreement will ask you to confirm, so you know what to look for.

3. Accounting and tax treatment. Acquired software and related intangibles usually go on the books and are written off over time. In the US, past write-offs on software can make part of the gain ordinary income when it is sold, and other countries have their own rules; our overview of taxes when you sell source code summarizes the main ones. Bring finance in early, because the carrying value and any write-down shape how the sale is recorded. This is not tax or accounting advice; your accountant should advise on your case.

What to do this month

1. Pull the acquisition’s due diligence file: repository list, contributor list, IP assignments and open-source scan.
2. Confirm which legal entity holds the rights today.
3. List deal terms and customer contracts that mention the code, escrow or licenses.
4. Map which parts were integrated into current products and which are unused.
5. Ask finance how the acquired technology is carried and whether it has been written down.
6. Run a full-history secrets scan on the original repositories and rotate anything found.

Your options

Leaving it archived is the usual default, and it carries a quiet cost: someone must keep owning access reviews, scan findings and audit questions for code nobody uses. Our comparison of selling versus leaving code archived sets out that trade-off. If the acquired startup’s founders wrote code before the company existed, our guide on who owns the code explains how that gap is usually closed.

If you decide to sell, the process is designed for corporate teams. We never ask anyone to install or run anything, the review is based on what you tell us, and no code changes hands before a signed written agreement. We never take databases, user records or customer data, so the acquired company’s customer data stays with you. Payment is cash, one agreed price, on transfer.

What to do next

• Retrieve the due diligence file and confirm which entity owns the code.
• Check deal terms, integration boundaries and the accounting treatment.
• Send us a few details for a free code valuation; the form needs no code and takes about a minute.