Old codebases in COBOL, Delphi or VB6: do AI developers want them?

Why would AI developers want legacy code?#

AI developers may want legacy code because tools that read, explain, test or translate COBOL, Delphi and VB6 need real production examples, and most of that code was written inside companies and never published. Public repositories are dominated by modern languages, so business logic written in these older stacks is comparatively hard to find.

Scarcity alone does not create demand. A buyer looks for code that teaches something: how an inventory valuation, a pricing rule or a commission calculation was implemented, how it was maintained over the years, and how it was moved to a modern stack. A folder of undocumented source files with no history teaches far less.

The honest answer is that interest varies by buyer and shifts with their current projects. Nobody can promise demand for a particular codebase before a buyer engages, and anyone who does should be treated with caution.

Which factors raise or lower the value of an old codebase?#

The value of an old codebase rests on a handful of factors that a CTO can assess without exporting a single file. Most come down to whether a reviewer can tell what the code was supposed to do and whether it did it.

No codebase scores well on every row. A Delphi client with thin documentation but years of commit history and a test suite can still be a strong candidate, while a well-commented COBOL program copied from a server with no history may be a weaker one.

Score each factor from what the team already knows before anyone runs an export. A senior engineer can usually say in one conversation which modules still build, where the specifications live, whether tests exist and which parts were migrated, and that is enough to decide whether a fuller inventory is worth the effort.

Why does migration history matter most?#

Migration history matters most because it records the hard part of modernization: how a team worked out what the old code meant and how to express it in a new language. A COBOL batch job paired with its Java replacement, the tickets that explain each mismatch and the defects found after cutover form a worked example of the task many tools try to automate.

Partial migrations count too. A Delphi desktop client replaced module by module with a web app often leaves a trail of parallel implementations, feature parity checklists and bug reports where the new version behaved differently from the old one. Preserve those links, because they are easy to lose when the old repository is archived.

Version control history adds another layer. Older code often lived in tools such as Visual SourceSafe, or in dated folder copies, before moving to Git, and a careful import keeps that record instead of starting from the latest snapshot.

What blocks a legacy code license?#

Legacy code licenses are most often blocked by rights gaps rather than by code quality. Older codebases accumulated components and contributors at a time when IP paperwork was less consistent, and the people who could explain the gaps may have left long ago.

Most of these problems are solved by exclusion rather than repair. Removing a component folder or a customer module usually leaves the core business logic intact, and the excluded parts can be documented so a reviewer understands what is missing.

Embedded customer data needs particular care in older systems. Test databases were often straight copies of production, and Delphi or VB6 projects sometimes shipped sample data files built from a real customer's records, so scan resource folders and installers as well as source files.

• 1Third-party component libraries: Delphi component packs, VB6 ActiveX controls and COBOL utilities licensed for use but not for redistribution.
• 2Customer-owned customizations: modules written for one customer under a services agreement that assigned the work.
• 3Early contractor code: work by outside developers with no written IP assignment.
• 4Embedded data and credentials: hardcoded connection strings, passwords and real customer records in test files.
• 5Acquired code: modules that came with an acquisition whose schedules did not transfer them cleanly.

Illustrative: a distribution software vendor with two legacy layers#

Illustrative: a fictional distribution software vendor runs a Delphi desktop client for order entry and a COBOL batch core for nightly inventory and pricing runs. Over several years it rebuilt the client as a web app and rewrote part of the batch core in C#, tracking the work in Jira.

The CTO's inventory finds the full Delphi history imported from an older version control system, COBOL copybooks with a data dictionary, regression test files for the pricing rules, and Jira epics linking each rewritten module to its original. It also finds a commercial grid component and a reporting library that cannot be redistributed, plus two customer-specific pricing modules built under services contracts.

The vendor excludes the components and the customer modules and scopes a package of paired old and new code, tests and migration tickets. The rest of the legacy archive stays in storage until a buyer request makes it worth preparing.

How SourceX evaluates a legacy codebase#

SourceX evaluates legacy code with the SourceX Enterprise Data Value Framework. For old codebases, uniqueness, domain expertise, human-generated signal, rights and AI utility usually carry the case, while recency works against old code unless migration history ties it to current practice, and preparation cost rises when history is scattered. The first look uses metadata only: languages, approximate size by module, years of history, available documentation and known third-party components.

If a codebase proceeds, it follows the SourceX five-step transaction, with secrets, customer data and excluded components removed in Preparation and the SourceX Evidence Packet recording what was licensed and on what basis. The code stays in your own storage, and it is licensed, not sold, so the company keeps ownership.