Skip to content

Software companies

On-premise software vendors: you may hold less data than you think

By SourceX Editorial · Updated

Short answer

On-premise software vendors usually hold less customer data than founders assume, because customers run the software and its databases on their own servers. What the vendor holds is the record of building and supporting the product: source code, issues, code reviews, support tickets and implementation files. Those records can be licensable; customer database copies on support shares usually are not.

Key takeaways

  • An on-premise vendor's customers hold their own production data; the vendor holds the records of building and supporting the product.
  • Customer database copies sent for troubleshooting are customer data held under support terms and are usually excluded.
  • Long maintenance histories across many customer environments are what make on-premise engineering and support records distinctive.
  • Vendors that added a hosted version should split their archive by deployment model before scoping.

What data does an on-premise software vendor actually hold?#

An on-premise software vendor holds the records of making and supporting its product, not its customers' operating data. When customers install the software on their own servers or private cloud, the transactions, documents and user records it processes stay with them.

Founders who expect a rich customer database are often disappointed at first. Then they find that the vendor side holds something different and often more distinctive: years of bug reports from varied customer environments, the fixes that resolved them, the release decisions behind each version and the implementation work that configured the product for each industry.

A record map for on-premise vendors#

A record map shows, system by system, what the vendor controls and what it merely stores on a customer's behalf. Use it to plan the inventory, not to decide rights; the answer for each row depends on your end-user license agreements, maintenance agreements and any custom terms with large customers.

A record map for on-premise vendors
RecordWho usually controls itUsually licensable?
Source code and commit historyVendorOften, after third-party code is excluded
Issue tracker and code reviewsVendorOften
Support tickets and call notesVendor, with customer details insideOften, after de-identification and a contract check
Knowledge base, release notes and manualsVendorOften, though some content is already public
Implementation project files and playbooksVendor, with customer configurations insideSometimes, after removing customer specifics
Diagnostic bundles and log uploadsCustomer data in vendor handsRarely, and only where terms allow
Customer database copies for troubleshootingCustomerAlmost never
License keys and activation recordsVendorRarely useful for AI
Telemetry or usage reportsDepends on the license agreementOnly where the agreement clearly permits it
  1. 01Your work records
  2. 02Personal details removed
  3. 03You approve the release
  4. 04Licensed to AI developers
How it works with SourceX: Your work records → Personal details removed → You approve the release → Licensed to AI developers.Illustrative

The trap on the support file share#

The support file share is where on-premise vendors most often find customer data they forgot they had. To reproduce bugs, support engineers ask customers for database backups, exported tables or full diagnostic bundles, and those files accumulate on FTP servers, shared drives and engineers' laptops for years.

Those copies are customer data held for a specific purpose under support terms. They generally cannot be licensed, and some maintenance agreements require their deletion once the issue closes. Find them during the inventory, exclude them from any package and decide with counsel whether old copies should be deleted.

The same applies to customer data pasted into tickets: query results, sample records and screenshots of customer screens. Those need the same de-identification and contract review as any support history, and often more.

Why vendor-side records can still be valuable#

Vendor-side records are valuable because they show how domain software is built, debugged and maintained over long periods. A vendor that has shipped maintenance releases for years to customers on different database versions, operating systems and configurations holds a record of real-world failure modes that no public repository captures.

Those histories suit coding assistant and agent developers who need examples of diagnosis across messy environments. In the SourceX Enterprise Data Value Framework, they score on domain expertise, uniqueness and human-generated signal, while preparation cost rises with the age of the systems that hold them.

  • Bug reports linked to the customer environment details that caused them.
  • Hotfixes and patches linked to the tickets that triggered them.
  • Upgrade and migration tickets across product versions.
  • Implementation decisions recorded in project plans and configuration notes.
  • Release planning discussions that explain what shipped and what was cut.

Where an older vendor's records actually sit#

An older vendor's records usually sit in more systems than anyone remembers, because tooling changed several times while the product stayed on sale. The inventory should start from the people who ran support and engineering in each era, not from the current IT asset list.

Expect gaps. A help desk retired without an export, or a version control server shut down after a migration, can leave a missing stretch of history. Record those gaps honestly in the inventory; a buyer can work with a known gap far more easily than with one discovered late.

  • Retired version control servers, such as Subversion, Perforce or older Git hosts, and the migration notes that moved history forward.
  • Help desks replaced over the years, plus email-based support inboxes that came before them.
  • Implementation consultants' shared drives with project plans, configuration exports and customer sign-off documents.
  • Build and release servers holding release notes, build logs and hotfix records.
  • Partner and reseller portals where escalated cases were logged.

Hybrid vendors: split the archive by deployment model#

Hybrid vendors that now offer a hosted version need to split their archive by deployment model, because the rights position changes. Hosted customers' data is processed by the vendor under a different contract, often with data processing terms that limit use to providing the service.

Tag tickets, issues and repositories with the deployment model they relate to where possible. That makes it practical to apply different rules to each part of the archive instead of excluding everything to be safe.

Hybrid vendors: split the archive by deployment model
Deployment modelWhere customer data livesWhat the vendor can usually consider
On-premiseCustomer serversEngineering, support and implementation records
Vendor-hosted single tenantVendor infrastructure under contractThe same records; hosted customer data needs contract review
Multi-tenant SaaSVendor infrastructure under data processing termsVendor's own records; customer data only where terms clearly allow

Illustrative: a print shop software vendor finds its real archive#

Illustrative: a fictional vendor of on-premise estimating and scheduling software for commercial print shops has sold perpetual licenses with annual maintenance for many years. The founder assumes the valuable data is in customers' job databases and asks whether those can be licensed.

The inventory shows they cannot: the vendor never had them, apart from customer backups on an old support FTP server, which counsel flags for exclusion and later deletion. What the vendor does hold is a Subversion history migrated to Git, an issue tracker with linked fixes, a long support ticket history and implementation playbooks for print workflows.

The scoped package covers code, issues, code reviews and de-identified tickets, with playbooks stripped of customer names. The founder approves it knowing that no customer's job data is involved.

How SourceX approaches on-premise vendors#

SourceX starts with a fit check that collects only metadata: which systems hold engineering and support history, how far back it goes and which deployment models the records cover. Nothing is shared during that assessment.

In the Rights step of the SourceX five-step transaction, end-user license and maintenance agreements are reviewed to confirm which records are the vendor's own. The SourceX Evidence Packet then records provenance and permitted use, which matters for vendors whose records span many product versions and contract forms.

Frequently asked questions

Does our license agreement give us rights to customer data?

Usually not. End-user license agreements for on-premise software typically govern the customer's use of your software, not your use of their data. Some agreements include telemetry or feedback clauses; read them closely with counsel, because a right to collect diagnostics for support is not a right to license them.

Can we license crash reports and telemetry?

Only where the agreement clearly permits it and the data is cleaned of customer content. Crash reports can include file paths, user names and fragments of customer records. Treat them as customer-adjacent data, scope them narrowly and expect more review than for your own engineering records.

Are records from retired product versions still useful?

Often. Old versions show how the product and its failure modes evolved, and long histories are part of what makes vendor records distinctive. The practical question is whether they can still be exported from the systems that hold them, such as older issue trackers or version control servers.

Do our customers need to be told?

It depends on your agreements and on how customer details appear in the records. Even where notice is not required, some vendors choose to explain the program to key customers. A short customer FAQ that states what is and is not included keeps those conversations factual.

What if a reseller or partner handled support for some customers?

Then part of the support history may sit in the partner's systems, and its use depends on the partner agreement. Inventory which customers you supported directly, and treat partner-held records as out of scope unless the agreement gives you both access and rights.

Related resources

See if your company qualifies

A short company assessment. No data uploads are needed.

See if your company qualifies