Selling Jira and Linear issue history for AI training

Yes: a company can license its Jira or Linear issue history to AI buyers, and both vendors' contracts say the content is the customer's. Atlassian's agreement says " Customer owns all intellectual property and other rights in Customer Data", and Linear's says the customer " will own all right, title and interest in and to the User Submissions". But a tracker on its own is not what buyers pay most for. Issue history is valued when each issue links to the code that closed it, because buyers turn an issue, the change that resolved it and the tests that prove it into a training task: Turing pays for modern code " $1,000 per PR, up to $10K per codebase" and accepts a pull request only if its linked issue is closed and runs 10 to 6,000 words. An export that drops the changelog or the links loses most of that value: a Jira CSV carries no changelog history, and a plain git clone keeps every branch, tag and commit but not issues or pull requests. What it fetches follows the code: buyers' published offers for a source code repository have a median of $1,478 per repository, the public range for source code is $934 to $24.2K per repository, and a company's whole operating record, with its tracker, code and chat, sells per company, with a median of $28.3K per company across the sales on record. The steps are: export the tracker with its full history yourself, keep the issue keys that join it to the code, clean out secrets, customer names and bot noise, and put one description of it before every buyer that fits at once.

This guide is for a founder, chief technology officer or trustee of a software company, operating or closed, whose engineering record lives in Jira or Linear. It covers what an issue tracker holds and which parts buyers value, why the link from an issue to its code is the value, what Atlassian's and Linear's terms say as we read them, how each tool exports and what each route keeps, how to rebuild the links between issues, commits and pull requests, cleaning, the rights questions, what issue history fetches with and without code, preparing and delivering, the case of a closed company, and how a sale through AIData.Broker works. Every quote comes from the page it names, read on the day shown in its record.

This guide is research from public sources, not legal advice.

Contents

1. What an issue tracker holds, and what buyers value in it
2. Why the link to code is the value: issues become training tasks
3. What Atlassian's and Linear's terms say
4. Exporting Jira, and what each route keeps
5. Exporting Linear
6. Linking issues to commits and pull requests
7. Cleaning issue history: secrets, customer names and bots
8. The rights questions buyers ask about a tracker
9. What issue history fetches, with and without code
10. Preparing and delivering a tracker export
11. A closed company's issue history
12. How a sale through AIData.Broker works
13. Questions people ask
14. What this means for you

1. What an issue tracker holds, and what buyers value in it

An issue tracker is the written record of what a software team decided to do and why. Each issue starts as a request: a bug report, a feature, a refactor, an incident. Around it, the tracker records who picked it up, how its status moved, what was said in the comments, which other issues it blocked or duplicated, which sprint it was planned into, and, where the team linked its tools, which branch, commit and pull request resolved it. Over years, a company's tracker becomes the plan of record for everything its engineers built, in the order they built it, with the arguments along the way.

For an AI buyer, that record answers a question public code cannot: what was this change for? Public repositories show code, and often show commits, but the reason for a change usually lived in a private tracker. A model learning to work as a software engineer has to start from a request written by a person, in the vague and incomplete way people write requests, and end with working code. Issue history is where those requests are.

Buyers name trackers in their own words. Scale AI's data partnership page lists Jira, Confluence, Asana, Notion and Linear, and asks for " Tickets, wikis, and project records carried over with their complete history and metadata". Turing, which buys whole company records through its Project Lazarus program, asks for " Source code, reviews, tickets, and the iteration history behind what shipped", and says on its main page that code is never bought on its own while communications, tickets, wikis and databases stand alone. Mercor asks for " GitHub Repositories, commits, PRs, and issues". Collinear takes " private repositories with pull requests and linked tickets". DataVendor, a code marketplace run by HUD, asks for " issue or ticket history (Linear, Jira, and so on) and pull-request context" with every codebase.

Five things in a tracker move its value most.

Issues that link to the change that closed them. An issue whose key appears in a commit message, a branch name or a pull request title can be joined to the code. That join turns a ticket into a training example with a question and an answer. Sunset, a wind-down firm that buys closing companies' records, told Forbes that a Jira ticket tied to a specific code commit is worth more than a standalone document. An issue with no link is still a record of work, but it is the weaker half of a pair.

History, not only the current state. The final description of an issue is one thing; the sequence of edits, status changes, reassignments and comments is another. The changelog shows how a vague request became a clear one, how long it sat, and who decided what. Scale's words, "complete history and metadata", are the standard to hold your export to. The changelog is also the first thing a careless export loses (section 4).

Issues written by people, in full sentences. A one-line ticket that says "fix login" teaches little. An issue that states the problem, the steps to reproduce it, the expected behaviour and the constraints is the prompt a coding agent is trained to answer. Turing screens linked issues by length: its process page asks for issues of 10 to 6,000 words, and its technical overview gives a different range for the same filter, a body of 20 to 2,000 words. Either way, a tracker full of empty tickets yields fewer tasks than one where engineers wrote down what they meant.

Years. A tracker used for five or ten years records a product growing: early prototypes, scaling problems, rewrites, migrations, security fixes. Longer history means more tasks, and more kinds of task. Troveo, a buyer of company records, says plainly in its code guide that " A snapshot of source code with no history is worth little to a lab, because there's already a lot of code in the world." The same logic applies to the tracker that explains the code.

Scarce technology. SimpleClosure, which handles wind-downs and has brokered code sales, reports that less common languages such as Ruby or C++ can fetch top dollar, better still with Jira, Linear or Figma context. An issue history explaining changes to a legacy system or a rare stack is scarcer than one explaining a common web application.

What lowers value is the opposite: a tracker kept apart from the code with no keys to join them, tickets with no description, issues opened and closed by bots, and exports that keep only the latest state of each issue. A plain count before you talk to anyone tells you most of what a buyer will ask first. Polyshares' system guide shows where Jira's count comes from: the work item count from a JQL search. Add the number of years, the number of projects, the share of issues that are closed, and, if you can, the share of commits whose messages name an issue key.

2. Why the link to code is the value: issues become training tasks

To see why buyers care so much about the link, it helps to know what they build from it. Labs train coding agents on a unit called a task: the repository frozen at the moment before a change, the issue that asked for the change as the prompt, the merged change as the reference answer, and the tests as the verifier that decides whether an agent's attempt worked. Our guide to RL environments explains how such tasks are used in training. Each merged pull request that resolves one linked, closed issue, and that comes with tests that fail before it and pass after it, is one task.

That is why Turing prices modern code per pull request rather than per line, and why its filter for a usable pull request reads like a recipe for a task. Its process page asks that linked issues be closed, run 10 to 6,000 words, and come with at least one test file per pull request, and that pull requests come from a human author, with no code written by a language model. For a codebase as a whole, it asks for at least 50,000 lines of code, English comments and issues, a Dockerfile that builds and runs in a container, a screenshot of the running application and the top three pull requests implementing new features. "English comments and issues" is in that list for a reason: the issue is the prompt, and a buyer has to be able to read it.

The market prices tasks directly. Builders and lab researchers interviewed by Epoch AI put a task with its grader at $200 to $2,000, and SemiAnalysis reported labs paying $5,000+ a task for coding work. Those are prices for finished tasks, built by a vendor, not prices paid to the company whose history the task came from. But they explain why a buyer will pay for the raw material: real issues, from a real private codebase, resolved by real engineers, are exactly what a vendor cannot write cheaply. Scale AI's SWE-Bench Pro benchmark drew on 18 startups' repositories, acquired, in the paper's words, " where we contacted the company and purchased their engineering repos".

So the tracker and the code are worth more together than apart, and the join between them is where the value sits. Three practical points follow.

Without the code, a tracker is company records, not tasks. A Jira site sold alone is still useful to a buyer of company records: it shows how a team planned and worked, and it pairs with Slack, email and documents. Turing offered $50 per artifact for tickets, specs, docs and support threads bundled with a codebase. But issues that cannot be joined to code cannot become coding tasks, and the per-pull-request price does not apply.

Without the tracker, code loses its prompts. A repository with commits but no issues can still yield tasks, because a buyer can write prompts from commit messages or the diff. But a written prompt is a guess at what the engineer was asked; the original issue is the real request. Buyers who name both, such as Collinear's " pull requests and linked tickets", are asking for the pair.

The link has to survive the export. Issue keys in commit messages survive any git export, because they are part of the commit. Links stored in the tracker (development panels, remote links, pull request references) live outside git and are lost unless the export keeps them. Pull requests themselves also live outside git: Polyshares' GitHub guide notes that a mirror clone keeps every branch, tag and commit but not issues or pull requests. Section 6 sets out how to keep the join.

3. What Atlassian's and Linear's terms say

Before you export anything, read what each vendor's contract says about the content and about getting it out. Both read cleanly for a holder, with points worth knowing.

Sources: the Atlassian terms record and the Linear terms record, each holding the vendor's own pages as read on the date shown.

Four points in that table matter for a sale.

The content is yours to license. Both contracts give the customer the rights in what it put in. Neither, as we read it, bars a customer from licensing its own exported issues to a third party for AI training. The competing-product clauses bar using Jira or Linear to build a rival tracker; a training licence is not that, though a buyer that itself builds project tools should be read against them.

The export route matters more than the contract. Our export route check asks how the data left each system: by the vendor's built-in export run by your own administrator, or by an app or script using the vendor's API. Several vendors now forbid using API-obtained data for AI training or bulk export, which is why Slack's terms, for one, require your own admin export (see the Slack guide). For Atlassian, the Developer Terms that govern Marketplace and API apps were not retrievable when we read them, so restrictions on apps are unverified. The safe course is the same either way: export with Atlassian's or Linear's own tools, run by your own administrator, and record the method per system. Do not let a buyer connect an app to your tracker.

Both vendors delete after the end. Atlassian deletes customer data after the subscription ends unless the law forbids it, and Linear's terms set no window to retrieve anything after termination. Linear's record notes: export before cancelling. A company winding down that cancels its tracker before exporting it may have lost the whole history.

Atlassian may already have learned from your content. Since 17 August 2026, Atlassian uses metadata and in-app data to improve its features. Its trust page says " If your Atlassian organization's highest active plan is Free, Standard, or Premium, metadata contribution is always on", and that every customer can opt out of contributing in-app data. The defaults recorded for in-app data are on for Free and Standard and off for Premium and Enterprise. Atlassian says the data is de-identified and aggregated before use. This does not stop a sale and is not an exclusive right Atlassian holds over your content, but a buyer paying for exclusivity will ask: our vendor training check treats promising "never seen by any AI" as a red flag when the site sat on a plan where vendor training defaulted on. Note each setting, and when you changed it, in your rights file.

4. Exporting Jira, and what each route keeps

Jira offers several ways to get issues out, and they keep very different amounts of what buyers pay for. The record we hold covers two of them, and a buyer's guide covers the third.

The site backup is the route to prefer. Polyshares' guide to each system names it plainly: for Jira, a full site backup from Backup manager, after a work item count from a JQL search. The backup holds issues, users and, if you tick the option, attachments. Atlassian's older documentation, as recorded, says one backup can exist at a time and it can be regenerated every 24 hours. Take the backup with attachments, download it, and keep it somewhere you control before anything else happens to the site. If attachments make it too large to handle, take one backup with and one without, so the issue history is safe even if the attachment download fails.

The CSV loses the history. DataVendor, which accepts a Jira upload, asks for " Jira's CSV - all fields issue search export", exported with Jira set to English and at most 512 MiB, and says on the same page that "CSVs do not include changelog history or attachment sizes". The CSV keeps each issue as it stands today: its title, description, status, assignee, labels, sprint and custom fields. It does not keep how the issue got there. For a buyer of tasks, the final description of a closed issue and its key may be enough to join it to a commit. For a buyer of company records, the sequence of status changes and comments is part of the value, and a CSV throws it away. DataVendor's own watch note, as we recorded it, is to prefer a full backup where history matters.

Comments are a separate question. Check what your chosen export does with comments before you rely on it. In a site backup they are part of the issue. In a CSV, multi-value fields such as comments may come out as repeated columns or be cut off, depending on the export settings. If the comments are where the decisions were argued, verify them in the export, by opening a dozen long-running issues and comparing them with the live site.

Jira Service Management is different material. A Jira site that also runs Jira Service Management holds customer requests: support tickets written by your customers, often with names, emails and account details. Atlassian's record makes the point: Jira and Confluence hold customer tickets, contractor and partner content and personal data, so content review is the gate, not Atlassian's terms. Service desk projects need the cleaning in section 7 at a stricter level, and some holders keep them out of a first sale altogether. Our guide to support tickets covers that material.

Confluence sits beside Jira. Many teams kept their design documents, decision records and runbooks in Confluence and linked them from Jira issues. Atlassian's record notes that space and site exports exist for Confluence. A link from an issue to a design document is worth keeping for the same reason as a link to a commit: it ties the request to the reasoning behind it. Export Confluence in the same pass.

Who can run it. Backup manager sits under Jira's administration settings, so the person who holds Jira's administrator role is the person who exports. Turing accepts an intake only from someone with admin authority, asks for a rough count per system, and accepts older trackers too: its intake names Bugzilla among the historical systems it takes. If the person who held the administrator role has left, transfer it while the site is live.

5. Exporting Linear

Linear's record is shorter, because Linear publishes less about export by plan, and we hold one reading of its terms. What we can say: Linear offers a CSV export of issues and a public GraphQL API, and its terms give the customer ownership of what it submitted. We have not verified what each plan's export holds, so check yours before you promise a buyer anything.

Three points apply whatever the plan.

Export before you cancel. Linear's terms provide for deletion of the customer's information, files and submissions within thirty days of termination for cause, on request after termination, or when the customer deletes its workspace, and we found no window to retrieve anything afterwards. The workspace is the record. Export it while it is paid and live, and keep the export somewhere you control.

A CSV is the current state. As with Jira, a CSV export of issues gives each issue as it stands. If you need the history of status changes and comments, check whether your export carries it; if it does not, the history sits in Linear and is reached only through its API, which raises the export route question in section 3. Linear's terms, as we read them, have no clause barring a customer's own use of the API on its own workspace, but the cleanest record for a buyer is still an export run by your own administrator, with the method written down. If you do use the API, run it yourself, on your own workspace, for your own export, and record that; never let a buyer's tool connect to it.

Linear's links to code are part of the value. Teams that use Linear often connect it to GitHub or GitLab so that branches and pull requests carry the issue identifier, and the issue shows the pull requests that closed it. Those identifiers in branch names and pull request titles survive in the code host's export; the links stored in Linear itself survive only if the export keeps them. Before you rely on Linear's side of the join, confirm that your export lists each issue's linked pull requests, or plan to rebuild the join from the code side (section 6).

Linear's record also notes that Linear owns aggregated and anonymised Service Data. That is Linear's own usage data about the service, not your issues, and it is not part of what you can license.

6. Linking issues to commits and pull requests

The join between tracker and code is the most valuable thing in this guide and the easiest to lose. It lives in three places, and a complete export keeps all three.

Clone every repository with its whole history. Polyshares' GitHub guide exports code with a mirror clone of each repository, which copies every branch, tag and commit. That keeps every issue key your engineers ever wrote in a commit message. It does not keep pull requests, which live outside git.

Export the pull requests separately. On GitHub, issues, pull requests, reviews and comments come out through an organisation migration archive, which the organisation's highest role starts and which must be downloaded within seven days before GitHub deletes it. Standard tools lose some of the join in other ways: as our code guide records, a GitLab project export leaves out issue links. Troveo's advice for code is to export the full repository with every branch, pull request, review and issue, plus design docs and ticket archives, before any subscription lapses, with a short note on what each system was used for and over which dates. DataVendor's checks for a codebase ask for a readable repository copy with its Git history and captured pull requests.

Measure the join before you sell. Count, from your own copy, how many commits name an issue key, how many pull requests name one, and how many issue keys in the tracker appear anywhere in the code. Those three counts tell a buyer how many tasks your history can yield, and they are counts you can share without showing any content. Our codebase valuation reads a saved git log on your own computer and counts commits that name a ticket, among other things, without the code leaving it.

Rebuild what was never linked, carefully. Some teams never wrote keys into commits. A buyer can sometimes rebuild the join by matching dates, authors and wording, but it is guesswork, and a buyer will price it as such. Do not invent links. If your team linked work only for some years or some repositories, say so in the description: a stated share of commits naming a key on the main product, from a stated year, is a statement a buyer can test; "fully linked" is one it will test and find wrong.

Keep the identifiers stable through cleaning. When you pseudonymise people and remove secrets (section 7), keep issue keys, commit hashes where you can, and pull request numbers consistent between the tracker export and the code export. A de-identification pass that renames keys in one export and not the other breaks the join you just preserved. Rewriting git history to remove secrets changes the hashes of every later commit, so if you rewrite history, rebuild the commit references in the tracker export from the rewritten copy, or deliver a mapping table from old to new hashes held by you, not the buyer.

What buyers screen out matters here too. Turing accepts pull requests from human authors only, and Collinear says it does not need AI-generated code, or a public framework with a thin layer on top. If your team used coding assistants in recent years, note which commits name an assistant as co-author; those pairs of issue and change may fall out of a buyer's count.

7. Cleaning issue history: secrets, customer names and bots

Issue trackers carry more sensitive material than people expect, because engineers paste whatever helps solve the problem in front of them. Three kinds of material need attention before anything leaves the company: secrets, people, and noise.

Secrets

Engineers paste credentials into tickets: an API key to reproduce a bug, a database connection string, a token in a log excerpt, a password for a staging server. The same is true of commit history, where a key committed years ago stays in the history after the current files are cleaned. A buyer that receives the history receives the secrets. DataVendor tells holders to remove secrets, credentials, customer information, and anything you do not have the right to share before upload, and its checks look for credentials in what is sent. Turing removes secrets itself in isolated processing, after you approve the scope.

Do both things a careful holder does. First, rotate every secret you find, in the tracker and in the code, so that none of them works any more. Then deliver a copy with the secrets removed. Scan issue descriptions, comments and attachments, not only the code: log files and screenshots attached to bug reports are where credentials hide. Our valuation treats code with credentials in it as worth nothing until they are out, because that is how a careful buyer treats it.

Customer names and personal data

A bug report often quotes the customer who hit the bug: their name, their company, their email, sometimes a screenshot of their account or a pasted record. Linear's record says it directly: the content is engineering tickets, including bug reports that may quote customers, and employee names. Jira Service Management projects hold customer requests by design. Assignees, reporters and commenters are your employees and contractors, named on every issue, and commit authors carry their names and email addresses.

All of this has to be removed or replaced before delivery. The usual standard is consistent pseudonyms: the same person gets the same placeholder everywhere, in the tracker and in the code history, so that a buyer can still see that one engineer reviewed another's work without learning who either was. Collinear describes this approach, removing personal data after export by replacing names with consistent pseudonyms and stripping identifiers. Polyshares says customer names, emails and account numbers are stripped by a specialist PII partner, and Scale anonymises inside your environment before anything is extracted. Buyers differ on who does the work and where; the de-identification standard sets out what a holder can require of whoever does it, and the guide to employee emails and chats covers the employee side.

Customer company names deserve a second look. A ticket titled with a customer's name ("Acme cannot export invoices") reveals who your customers were even after personal names are gone, and your customer contracts may treat that as confidential. Replace customer company names with consistent placeholders in titles, descriptions, labels and custom fields, and check components and project names, which teams often named after their largest customers.

Bots and automation

Many trackers are full of machine activity: issues opened by monitoring alerts, comments posted by CI pipelines, status changes made by automation rules, dependency update tickets opened and closed by bots. They are not worthless (an alert followed by the engineers who resolved it is a good example), but a project of auto-opened alerts that nobody touched adds bulk, not value, and a buyer that counts issues will discount it. Separate them before you count. Identify the bot accounts, report the human-written issues separately from the machine ones, and consider leaving out projects that are only automation.

What to keep out

Some material should stay out of a sale whatever cleaning you do: security vulnerability tickets that describe unpatched weaknesses, legal and HR projects, tickets that quote privileged legal advice, and anything a customer contract or a confidentiality agreement covers. Our privilege and trade secrets check covers material that has to be excluded or restricted by contract. List the projects you keep out, and why, in the description you give buyers. A buyer reads a clear list of exclusions as a sign of a careful holder.

8. The rights questions buyers ask about a tracker

The contracts with Atlassian and Linear settle the vendor's side. The rights questions that remain are the company's own, and they are the same ones that decide a code sale.

Who wrote it. US copyright law gives the company what its employees write in the course of their jobs. Contractors are different: their work stays theirs unless a signed agreement assigns it, and a transfer of copyright is not valid unless it is in writing and signed. Issue descriptions written by contractors are usually short and functional, and the risk sits mostly in the code they wrote; but the same paperwork covers both. Collect missing assignments before the sale, and list any gaps with the work excluded until they are closed.

What came from outside. Issues often quote open-source code, error messages from third-party tools and snippets copied from documentation. In the code itself, open-source licences travel with the code, which is why buyers want only the company's own code warranted. The code guide's section on licences applies to every repository you deliver beside the tracker.

What was built for customers. A software agency or consultancy that ran a customer's project in its own Jira may hold tickets about work the customer owns. Read the customer contracts that touch a project before including it.

Who signs. Someone has to have authority to approve the licence: usually the board, and shareholders too where the records are all or substantially all of the company's assets. For a closed company, see section 11.

How it left. The export route: by the vendor's own tools, run by your administrator, with the method recorded per system, and no third-party connector involved.

Whether a vendor already used it. For Jira, the data contribution setting and its history (section 3), under our vendor training check.

Our readiness check lists what to prepare, and the guide to preparing data for sale explains the rights file, the written record of who owns what, that comes before any conversation about price.

9. What issue history fetches, with and without code

There is no public price for a Jira site on its own, and we will not invent one. What the records show is how buyers price the things a tracker belongs to: code, priced per repository or per pull request, and whole company records, priced per company.

Read that table with three things in mind.

The tracker raises the code's price; it rarely has a price of its own. Under Turing's per-pull-request pricing, a pull request counts only if its linked issue is closed and the right length, so the tracker is what makes a pull request countable. A codebase with ten qualifying pull requests reaches Turing's $10K cap; without linked issues, it may reach none. On the company-records side, buyers price the whole working record, and a tracker joined to code and chat is part of what moves a company up the range: the Sunset remark that a ticket tied to a commit is worth more than a loose document is a statement about exactly that.

Volume is counted net. SimpleClosure found that roughly 37% of raw code disappeared once third-party code, generated code and duplicates were removed. The tracker equivalent is bot-opened issues, empty tickets and duplicates. A buyer counts what is left, so count it yourself first.

Single buyers and ceilings differ. A marketplace licenses a repository to several buyers; a buyer of company records usually wants the whole record, sometimes exclusively. The Turing and Polyshares figures are ceilings and ranges each buyer published for itself, not what a given company will receive. Our offer check reads any offer you already have against the published terms of the buyers we track, and our page on selling direct or through us sets out when a single clean repository is better listed directly on a platform that grades repositories.

Example. Take a 30-person software company, seven years old, that ran Jira from its first month and linked its GitHub repositories to it. Its main product repository has most commits naming a Jira key, pull requests reviewed by a second engineer, and tests in CI. It also has a Jira Service Management project for customer support, Confluence with design documents, and Slack.

The site backup with attachments and the GitHub migration archive are taken the same week, before anyone touches the subscriptions. From the copies, the company counts its closed issues, the share of commits that name a key, and the pull requests whose linked issue is closed and long enough. It finds three projects that are only monitoring alerts and leaves them out of the count, keeps the service desk project out of the first sale, and rotates two old cloud keys found in tickets. The description it gives buyers states the counts, the years, the languages, what is excluded and why, and the export method per system.

Priced as code alone, the main repository falls somewhere in the source code range above. Priced by tasks, its qualifying pull requests are what count, and each one depends on its linked issue. Priced as a company record with its tracker, code, documents and chat together, it sits in the per-company range, which is where competing offers on one description make the most difference. The valuation gives a range for each route from your own answers.

10. Preparing and delivering a tracker export

Most of the work can be done before any buyer is involved, and done first, it keeps you in control of what is disclosed. The order below is the one a careful holder works in.

1. Count before you export. Issues per project, from a JQL search in Jira or a filtered view in Linear; years; share closed; human-written versus bot-opened. Buyers ask for counts per system, read from the admin console, and Polyshares says nothing leaves your systems until it has made an offer and you have accepted it. Counts are what you share first.
2. Export the tracker with its history. For Jira, the site backup from Backup manager with attachments; for Linear, the fullest export your plan allows, checked for comments and linked pull requests. Do not stop at a CSV if history matters: it carries no changelog history.
3. Export the code and its pull requests in the same week. A mirror clone of every repository, and the code host's archive of pull requests and reviews, downloaded within seven days on GitHub.
4. Export the documents the issues link to. Confluence spaces, design documents, runbooks.
5. Write down the method per system. Who ran each export, when, with which tool. This is the record our export route check asks for.
6. Record the vendor's AI settings. Atlassian's data contribution settings, and when you changed them.
7. Build the rights file. Assignments from employees and contractors, customer contracts that touch any project, the person or body that approves the licence.
8. Clean. Rotate secrets, then remove them from the delivered copy. Pseudonymise people consistently across tracker and code. Replace customer names. Separate bots. Keep out security, legal and HR projects.
9. Measure the join. Commits naming a key, pull requests naming a key, issues that appear in the code. Keep identifiers consistent through cleaning.
10. Describe it, without showing it. A short description with counts, years, languages, the join measured, the exclusions and the method. Do not share samples before terms: one law firm advises that " Do not share sample data before this review, since a sample itself could be a disclosure".
11. Deliver directly to the buyer you chose, under a signed licence. Turing says most holders go from first conversation to payment in under two weeks; others take longer, and the time is spent mostly on the steps above.

On delivery format, ask the buyer what it reads. The Atlassian site backup is a complete record but in Atlassian's format; some buyers prefer a structured export per issue with its comments, changelog and links. The code host's archive and the mirror clones go beside it. Package the exports with a short note on what each system was used for and over which dates, as Troveo asks for code: a buyer that understands your tools will value them more accurately.

11. A closed company's issue history

A closed company's tracker can still be sold, often, if the history still exists and the right person signs. Both conditions deserve attention early.

The history has to survive the wind-down. Atlassian deletes customer data after the subscription ends, and Linear's terms set no retrieval window after termination. A plain way for a closing company to lose its engineering record is cancelling the tools to save money before exporting them. Keep the plans paid until the exports are downloaded and verified, and keep the code host's account alive until its archive is downloaded: the GitHub archive itself must be downloaded within seven days.

Someone has to have authority. In Delaware a dissolved corporation continues for three years to wind up its affairs, including selling its assets, and its directors or officers act for it in that period. In bankruptcy the trustee acts. Our authority check for a closed company sets out who can sign in each case.

Buyers seek out closed companies' code. Turing's chief executive told The Information that it had bought five to ten failed-startup codebases, and SimpleClosure's record of one small closed startup shows its code base selling for about $25,000. A closed company's tracker, joined to its code, is part of that material: it explains what the company was building when it stopped.

The people have scattered, so write down what they knew. Before the last engineers leave, ask them to note what each project was, which repositories it mapped to, which years the team linked commits to keys, and where the bots are. That note is part of what a buyer pays for, and nobody can write it later. Our estates page covers selling a closed company's records, and the deletion clock counts the days other systems keep data after a plan ends.

12. How a sale through AIData.Broker works

AIData.Broker represents companies selling their data to AI buyers. We act only for the holder, as its agent in the sale, for holders based in the United States, the United Kingdom and Canada. For a holder of issue history and code, a sale through us runs like this.

The valuation comes first, with no upload. The valuation asks about your systems (tracker, code host, years, team size, how work was linked, what else the company ran) and returns a range from the public records in section 9. For code, the codebase valuation reads a saved git log on your own computer, and only counts leave it. The valuation binds no one.

You keep the data and deliver it yourself. We do not hold your exports, show any part of them to a buyer, or license them in our name. You, or a de-identification provider you choose, deliver directly to the buyer, and the buyer pays you directly. That keeps your exports inside the route the vendors' tools provide.

Every buyer that fits sees it at once. Every buyer whose published requirements fit your records receives a description that does not identify you; each that gives its confidentiality undertaking receives the same datasheet, with one deadline for offers. Offers come back on the same terms, so you can compare price, de-identification model, payment timing and exclusivity side by side. Our free offer check reads any offer you already have against the published terms of the buyers we track, and the source code page keeps the current prices and buyers for code.

The fee is due only out of money you receive. It is a success fee on what you are actually paid, band by band: 15% of the first $250,000, 10% from $250,000 to $1 million, and 6% above $1 million. On a $300,000 sale the fee is $42,500. Mandates are exclusive for 2 months, with a tail of 12 months for buyers we introduced, and we do not take mandates where the expected sale is below $50,000. Several buyers publish an introduction fee; in a sale we run we decline it and ask the buyer to add it to your price instead, so we earn the same whichever buyer you choose. How it works sets out every step and term.

A single repository with nothing else is usually best listed directly on a platform that grades repositories, and our valuation says so when that is the case. Issue history joined to code, years of it, a scarce stack, or a whole company's records behind it are where one description before several buyers makes a difference.

Questions people ask

Can I sell my company's Jira data for AI training? Yes. Atlassian's agreement says the customer " owns all intellectual property and other rights in Customer Data", and we found no clause barring a customer from licensing its own exported issues. Export it with Backup manager yourself, clean it, and sign as the company. Its value rises sharply when the issues link to the code that closed them.

Can I sell Linear issue history? Yes, on the same footing: Linear's terms say the customer will own all right, title and interest in and to the User Submissions. Export it before cancelling, because the terms set no retrieval window after termination.

Is a Jira CSV export enough? For some buyers, as a start. DataVendor accepts the all-fields CSV, but notes it carries no changelog history and has a size cap. Buyers that ask for complete history and metadata want more, so take the full site backup as well.

Why do buyers want issues linked to code? Because an issue, the pull request that resolved it and the tests that prove it make a training task. Turing prices code per pull request and counts a pull request only if its linked issue is closed and 10 to 6,000 words long.

How much is a Jira site worth? There is no public price for a tracker alone. It is priced with what it belongs to: code, where buyers' offers for a repository have a median of $1,478 per repository, or a company's whole record, where the median of sales is $28.3K per company. The valuation gives a range for yours.

Has Atlassian already trained on our tickets? Possibly some of it, in de-identified and aggregated form. Since 17 August 2026 metadata contribution is always on below the Enterprise plan, and in-app data contribution defaults on for Free and Standard, with an opt-out. Note your settings in your rights file; it does not stop a sale.

Should a buyer connect an app to our Jira or Linear? No. Export it yourself with the vendor's own tools. Our export route check treats data pulled through a connector as a red flag, and Atlassian's terms for apps were not retrievable when read.

What about customer names in our tickets? Replace them, and personal names, with consistent pseudonyms before delivery, and treat Jira Service Management projects as customer records. The de-identification standard explains what to require.

Our company has closed. Can we still sell its tracker? Often yes, if the history was exported before the subscriptions ended and the right person signs: in Delaware a dissolved corporation continues for three years to wind up. See the estates page.

What this means for you

Your issue tracker is the half of your engineering record that explains the other half. On its own it is a good record of how your company worked; joined to the code, it is the raw material of the training tasks buyers pay most for. Both halves are fragile in the same way: the vendors delete what you do not export, the common exports drop the changelog and the pull requests, and the join between them survives only if you keep the issue keys, the pull requests and the tracker's links together.

So do four things now, before any buyer conversation. Keep the tracker and the code host paid. Take the full Jira site backup or the fullest Linear export, and the code with its pull requests, in the same week. Count your issues, your linked commits and your qualifying pull requests from your own copies. And get a range for the whole record from the valuation, so that the first offer you see is measured against the market rather than against nothing. Then clean it to a standard you chose, and put it before every buyer that fits at once. The codebase guide covers the code in depth, and the rest of the What sells section shows the other records buyers pay for beside it.