What Companies Can Do With the Code of Retired Products

Most companies with a retired product do nothing with its code. The repository gets archived, the team moves on and the code sits in a private organization account for years. That is a choice, and it is rarely the best one. A sunset product leaves behind a complete, working codebase with its history, tests and design decisions, and that body of work can usually be reused, released, sold or deliberately destroyed. Each route has real costs and benefits, and the right one depends on how far the code still touches live systems.

What kind of retired code do companies usually hold?

Retired code shows up in more places than most leadership teams expect. A typical mid-sized software company might find all of these in its source control:

• Sunset products. A product line that was shut down because it did not find enough customers, or because the company changed direction.
• Legacy repositories. An old version of the main platform, replaced by a rewrite, that nobody has opened since the migration.
• Acquired technology. The codebase of a startup the company bought for its team or customers, then folded into its own product or switched off.
• Internal tools. Admin dashboards, billing scripts, data pipelines and deployment tooling built for a business that has since changed.
• Prototypes and spin-offs. Complete products built for a market test that never launched.

Suppose a company retired a scheduling product three years ago. The repository holds six years of commits, a test suite, an API and a mobile client. Nobody has deployed it since. That is exactly the kind of codebase this guide is about.

What does keeping old code actually cost?

Archiving looks free, because the storage bill is small. The real costs are elsewhere.

Security exposure. Old repositories are full of things that were fine at the time: hardcoded credentials, sample data, outdated libraries. GitGuardian’s State of Secrets Sprawl 2026 found that 32.2% of internal repositories contain at least one hardcoded secret, against 5.6% of public ones. Black Duck’s 2026 OSSRA report found that 92% of audited codebases contained open source components four or more years out of date. A retired repo is not running, but anyone who copies it inherits those problems.

Lost knowledge. The people who understood the code leave. Every year the repository becomes harder to evaluate, reuse or sell, because nobody remembers which folders matter or who wrote what.

Decision debt. Someone eventually has to answer the question “what is this, and can we delete it?” during an audit, a security review or an acquisition of your own company. Answering it then, under time pressure, costs more than answering it now.

Opportunity cost. Code that sits unused earns nothing. The same code, with rights confirmed and sensitive data removed, can sometimes be sold for cash.

What are the options for a retired product’s code?

Archiving on GitHub makes a repository read-only and can be undone, which is why most companies archive first and decide later. Open sourcing is the opposite: once code is public, it cannot be sold exclusively. Our pillar guide on whether to sell, archive, open source or delete walks through each route in more depth, and the selling vs archiving comparison covers the most common choice in detail.

Who inside a company should decide?

Retired code tends to have no owner, which is why nothing happens to it. Assign the decision explicitly. In most companies four functions need a say:

1. The product or business owner proposes what to do and confirms the product no longer earns revenue.
2. Engineering lists what exists: repositories, branches, docs, tests, ticket exports, and where sensitive data lives.
3. Legal confirms the company owns the code and that nothing in a customer, partner or acquisition agreement restricts its transfer.
4. Finance records the outcome, whether that is a write-off or a sale.

In a startup one person may cover three of these roles. In a larger company, a short memo signed by each function is usually enough to move from “nobody owns this” to a decision.

Can a company sell code that is no longer core?

Usually, yes. A company that owns the intellectual property in a retired product can sell the rights to that code like any other asset. What matters is that the product makes no money today, that the code was written by the company’s own staff or properly contracted developers, and that someone with authority can sign for the company.

Ownership is usually straightforward for employee code. In the US, code an employee writes as part of the job is a work made for hire, and the company is treated as its author. In the UK and the EU, the employer similarly holds the rights (in the EU, the economic rights) to code staff write in the course of their job, unless a contract says otherwise. Contractor code is the usual gap, because it typically needs a signed IP assignment. Our guide on who owns the code explains how to check. This is general information, not legal advice; ask your own counsel to confirm for your situation.

Acquired technology needs one extra check. Read the acquisition agreement. It normally transfers the code and its rights to your company, but it may contain license-backs to the founders, restrictions on transfer or obligations to former customers. Also confirm that the acquired startup’s own contractors assigned their work. A qualified lawyer should review this before you sign anything.

Open-source libraries inside the code are normal and do not stop a sale. What you sell is the code your team wrote; third-party code stays under its own license.

What does a buyer of retired code look for?

The buyer at The Blue Ocean Code is Odys AI Labs, the research and development arm of Odys. Odys AI Labs uses the code it buys for AI training and R&D, so models learn to read, write and fix real software; we may also work on it with research partners, and the agreement sets out exactly what rights transfer. It looks for a complete product written by your own team: web apps, SaaS, platforms, backends and APIs, internal tools and games all qualify, along with git history, docs, tests, ticket exports and design files.

It passes on software still making money, client work you have no rights to, open-source forks and templates, and repos that are mostly copied libraries or generated code. It never takes databases, user records, customer data or chat logs, and it never uses your brand or name or relaunches the product as yours. The deal is confidential.

The terms are simple: cash only, one agreed price, paid on transfer, with an offer after review and no obligation. No code changes hands before a signed written agreement, and we never ask anyone to install or run anything. Secrets, keys and personal data are removed before transfer, and we help. Value typically depends on size, originality, languages, quality, history, docs and tests; how we value a codebase is explained on the call. Our methodology page lists what we check.

How should a company prepare retired code for any outcome?

The same preparation helps whether you keep, release or sell the code:

• Inventory. List every repository tied to the product, including forks, mobile clients and infrastructure scripts.
• Freeze access. Archive the repositories, remove former staff and contractors from the organization, and revoke old deploy keys and access tokens.
• Rotate secrets. Revoke any key or password ever committed, then scrub history. Our guide to removing secrets from old code explains why deleting a file is not enough.
• Separate live dependencies. Identify any module still used by a live product, and decide whether it stays out of any sale.
• Write a one-page overview. What the product did, when it ran, the main languages and what documentation exists.

What to do next

• Assign one person to own the decision for each retired product, with a date to decide by.
• Ask legal to confirm ownership, especially for contractor and acquired code.
• If selling non-core code makes sense, send us a few details for a free code valuation; the form takes a minute and asks for no code.