How to Export Linear Issues, Projects and Workflow Data

Choose the granularity you need

Linear tracks issues, projects, cycles and initiatives. Organizations export for reporting, migration or planning analysis. An issue snapshot can describe work at a moment in time; it cannot necessarily explain how a decision changed. Decide whether the candidate task needs current descriptions, comment exchanges or historical transitions before collecting.

Export a workspace or view

Linear’s export documentation describes Settings → Administration → Import/Export → Export data for workspace issue CSV. Check the private-team toggle deliberately. Issue views can also export CSV through the command menu or view dropdown. View exports have role-dependent limits, so reconcile exported counts.

Project and initiative exports are separate from issue exports. The CSV includes issue identity, descriptions, status, project information and selected dates; it does not include attachment files. Keep the source view and time with the output. Verify the currently documented limits rather than assuming a view export covers the whole workspace.

Use API collection for additional entities

Linear points to its API for issues, projects and other data. Review API access, authentication and pagination for the entities you actually need. Define a separate coverage test for comments and history; do not assume they appear in a CSV because a description does. This guide does not prescribe a universal query for all workspace data.

Check a known issue with comments, a parent and a project milestone before scaling a collector. Store the query/API version or schema evidence used, completed pages and missing records. Webhooks can support future updates but do not establish the completeness of a past archive.

Preserve the engineering relationships

Keep stable issue ID and display identifier separately, together with team, project and parent IDs. Preserve cycle definitions and workflow-state meanings. A source field called Completed is a timestamp, not proof that an issue’s proposed fix worked in production.

Synthetic example: parent issue parent-1 has tasks task-2 and task-3, one canceled and one completed. Flattening the tasks into the parent can turn a partial outcome into a successful project. Keep entity-level states and link edges, and distinguish planning dates from observed events.

Prepare text and evaluation splits

Normalize descriptions with Markdown structure retained. Code blocks, links to designs and reproduction steps can be essential. Inventory inaccessible links instead of replacing them with invented summaries. Deduplicate repeated source IDs across exports and separately inspect copied templates or duplicate bug reports.

Split by related issue family or incident when testing generalization. A duplicate issue or child task can reveal the solution to an evaluation example. Record whether temporal analysis is supported by actual collected history or only by selected current-state dates.

Review privacy and assess fit

Private engineering teams may contain unreleased product plans, customer-specific incidents or contractor contributions. Review those rights and confidentiality restrictions before considering licensing. Remove customer identifiers and credentials from descriptions, comments, links and asset names; team-level export access is not permission for downstream commercial reuse.

Why are exported counts smaller than the view? Check role limits, filters and selected scope. Use a permitted workspace method if appropriate rather than claiming a truncated export is complete.

Where are attachments and comments? Attachment files are not in CSV, and additional context requires a separately verified collection route.

Potential uses include engineering categorization and workflow evaluation. Describe unique issue coverage, domain context, outcome reliability and missing histories for an assessment. A large issue count alone does not demonstrate training quality or buyer interest.