Selling a legacy product to a legacy-software specialist acquirer

Who buys legacy software products?#

Legacy software products are bought mainly by specialist acquirers that run mature products for long periods. They include buy-and-hold vertical market software groups, private equity backed roll-ups of niche software, legacy modernization firms that migrate old platforms while keeping customers running, and maintenance-focused operators that support products their original vendors have moved away from.

Strategic buyers are the other route. A competitor or adjacent vendor may want the installed base so it can migrate customers to its own platform. That can be a sound outcome, but customers often experience it as a forced migration, which reflects on the seller.

What specialist acquirers pay for#

Specialist acquirers pay for durability: maintenance and subscription revenue that renews year after year, customers who depend on the product for daily work, and a codebase their team can keep running. Predictability matters more to them than growth.

Diligence tests each item with records. Jira issue history shows how much maintenance the product needs, support tickets show what customers struggle with, and release notes show how often the product changes. Sellers with clean, exportable history answer questions faster and with fewer caveats.

• 1Renewal history of maintenance and support contracts, customer by customer.
• 2Customer concentration and the reasons customers have left.
• 3Contract terms: assignability, price increase rights, termination for convenience.
• 4Codebase condition: build reproducibility, test coverage, runtime and third-party component support.
• 5Support load: recurring issues, escalation paths and known defects.
• 6People: engineers and support staff who know the product, and whether they will move with it.

Deal structure: assets, contracts and consents#

Legacy product sales are usually structured as asset purchases or carve-outs, so each customer contract has to move from seller to buyer. Contracts that require customer consent to assign can slow closing, and the buyer may ask for a transition services agreement while it takes over hosting, billing and support.

Third-party components need attention too. Runtime libraries, report writers and database engines embedded in an older product are often licensed to the seller under agreements that do not transfer automatically, and the buyer will want an assignment, a new license or a plan to replace them. List every embedded component and its license early, because a missing redistribution right can hold up closing.

Purchase accounting is another reason buyers care about records. Under ASC 805, an intangible asset acquired in a business combination is recognized separately from goodwill if it arises from contractual or legal rights or is separable, and the Codification's examples list databases among technology-based intangibles and customer lists among customer-related intangibles. Well-documented records make those assets easier to identify.

Which records to hand over and which to keep#

Records to hand over are the ones the buyer needs to run the product and serve its customers; records to keep are the ones about your company, your other products and your continuing obligations. Shared systems cause most disputes, because one Jira site, Zendesk instance or Slack workspace often holds several products.

Split shared systems before the data room opens, not after closing. Filtering by project key, ticket brand or channel is far easier while the team that built those systems is still in place.

Keep your options on historical records#

Historical engineering and support records often keep value after the product is sold. If the seller may later want to use them for internal training, analytics or licensing to AI developers, the purchase agreement has to say so, because a standard asset transfer conveys the product's records along with the product.

A license-back gives the seller a defined right to keep and use copies of specific records after closing. Buyers may accept one for historical records if it excludes customer content they now control and bars competitive use. Negotiate it before signing; raising it after closing means asking the new owner for a favor.

Write the scope precisely: which record families, which date range, which permitted uses, and whether licensing to third parties is included.

Illustrative: divesting an on-premise accounting module#

Illustrative: a fictional software company serving property managers decides to divest an older on-premise accounting module so it can focus on its cloud platform. The module has a loyal installed base on maintenance contracts and its own Jira project, but shares a Zendesk instance and a Slack workspace with the cloud product.

The company runs a process with several specialist acquirers and selects a maintenance-focused operator. Before signing, it splits the Zendesk export by product brand, filters Slack channels and negotiates a license-back covering historical Jira issues and code reviews written by its own engineers, excluding customer content.

The buyer receives everything it needs to support customers, and the seller keeps a documented right to historical engineering records that it may review for data licensing later.

How SourceX fits before a divestiture#

SourceX helps software companies understand their historical records before a divestiture changes who controls them. A metadata-only fit check, the first part of the SourceX five-step transaction, looks at systems, years of history and record families, and nothing is shared during that initial assessment.

Where a seller keeps rights through a license-back, the Rights step reviews that clause alongside customer contracts, and the SourceX Evidence Packet records licensing rights and release authorization for anything later licensed.