How to export data from Linear without losing issue history
A renewal, a pricing change or a data residency requirement is usually what forces a Linear workspace extract. Linear's CSV exports cover issues, projects and members, but they are subject to per-role row limits, and the workspace export link is time-limited, so a single download is unlikely to be a complete record. A complete extract usually means combining CSV files with the GraphQL API, which can page through issues, comments and project data programmatically. Before you schedule the work, confirm the current row limits, the link lifetime and the available GraphQL fields in Linear's own documentation and workspace settings, because these controls can change between releases.
What is typically missing is the material that does not fit a flat table. Attachment files are the most common gap, since a CSV usually carries references to files rather than the files themselves. Teams are the second risk: an export run from one account or role may omit private or archived teams, and the team-level cycles, labels and workflow states that belong to them. Related metadata such as comments, parent-child links, cycle membership and issue history can also be partial depending on how each export is produced. Ask who in your Linear organization holds the owner or admin role, and confirm with them which teams and attachments that role can reach.
Treat the work as an export, verification and inventory exercise before any decision about where the data goes. Count issues, projects and members per team in Linear's interface, then compare those counts with each CSV and API output. Open a sample of attachment links to confirm they resolve, and record which teams and fields each extract covers. Keep the inventory and the dated evidence together, so you can show later what was exported and what was not. Plane's Linear importer documentation describes what it maps, and it is worth reading once that inventory exists.
Which Linear data you can export and by which method
This table lists each Linear data type, the export route that covers it, the format it arrives in, and the limits to check before you plan batches. Row limits and link expiry must come from Linear's current help documentation, so confirm them there and in your own workspace before you start. The main takeaway is that CSV views are convenient but partial, so a complete extract usually combines the workspace archive with the GraphQL API.
| Data type | Export method and format | Documented limits | What to confirm |
|---|---|---|---|
| Issues | CSV export from the issues view, filtered by team or view | Per-role row limits apply to CSV exports | Row cap for your role, and which fields the CSV includes |
| Projects | CSV export from the projects view | Per-role row limits apply to CSV exports | Whether project updates, milestones and lead fields are included |
| Members | CSV export from workspace member settings | Per-role row limits apply to CSV exports | Whether guests, suspended users and team memberships appear |
| Workspace archive | Full export in one archive, delivered through a temporary download link | Download link expires after a short window | Current link lifetime, and whether attachment files and every team are included |
| Issues and comments (GraphQL API) | Paginated JSON queries using a personal or OAuth API key | Page size and rate limits set by the API | Current page size and rate limits, and how comment threads are returned |
| Projects, cycles and users (GraphQL API) | Paginated JSON queries for each object type | Page size and rate limits set by the API | Which cycle fields and project relations your queries return |
| Attachments | Linked files returned as URLs in issue data, downloaded separately | Not covered by the CSV views as a file set | Whether attachment files are in the archive, and how long linked URLs stay valid |
What does not come out of Linear and how to recover it
A CSV export carries issue and project rows, but several kinds of workspace data sit outside that file. Each gap below needs a named owner, a recovery method and a check against your own export before the Linear workspace is closed.
Attachment files stay behind
The CSV holds links to attachments, not the files themselves. Plan a separate pull for the binary files, either through the GraphQL API, which can return attachment URLs for each issue, or through the workspace data archive that Linear makes available to admins. Check whether the download links expire, because a link that works on export day may fail a week later. Store the files in a folder that mirrors issue identifiers so they can be re-linked after import. Confirm with Linear's current documentation which of these routes covers attachments in your plan.
Team structure needs manual records
A flat issue export does not describe which teams exist, which members belong to each team, or how team keys map to issue identifiers. Query the teams and memberships through the GraphQL API, or record them by hand from the workspace settings page, and save the result as a reference sheet. Note which team owns each cycle and project, because those ownership links determine where work lands in Plane. Confirm whether archived or retired teams appear in your export, since they often disappear from the default view.
Workflow and automation settings
Custom workflow states, triage rules, automation settings, custom views and label groups are configuration, not issue data, so most exports leave them out. Capture each state name, its category and its order, then compare the list with the state mapping that the Plane Linear importer produces. Screenshot the settings pages and save them alongside a written list of automations, such as auto-close or auto-assign rules, so the rebuilt Plane workflow can match intent. Treat any automation you cannot reproduce as a decision for the team that owns it.
Integration data lives in other tools
Links to GitHub pull requests, Slack threads, Figma files, Sentry errors and other connected tools are stored as references in Linear and as full records in those tools. Linear's export carries the link text, not the linked content, so the context behind a pull request or thread stays in its original system. Inventory every active integration from the workspace settings, decide which external system remains the source of record, and export from that system separately. Confirm which integration references Plane's importer carries over, because some may arrive only as plain text in descriptions.
Sequence to export data from Linear completely
This sequence moves Linear's data out in an order that keeps the export verifiable at each stage. The result is a dated archive of issues, projects, members, comments, cycles and attachment files, with a manifest that shows what was exported and what was checked.
Freeze scope and list every team
Before exporting anything, the workspace owner or an admin lists every team, including archived and private teams, and records the count of open issues per team as shown in the Linear interface. Agree a cutoff point with the teams so that no new issues change the numbers during the export. The output is a scope sheet with one row per team, its issue count and its owner. The step is done when every team on the sheet has a recorded count and someone other than the author has reviewed it.
Run CSV exports for issues, projects and members
Using an account with the role needed for each export, run the CSV exports for issues, projects and members. Check the per-role row limits before you start, because a role without enough access can produce a partial file that looks complete. Save each file with the export date and the role used. The check is that the row count in each CSV matches the count shown in the Linear interface for the same filter. Where the counts differ, rerun the export with a higher-permission role or split the filter by team.
Download the workspace export while the link is valid
Request the full workspace export from the settings, then download the archive from the link Linear sends. The link is valid for a limited time, so start this step after the CSV work and keep the download within the window. Store the archive unchanged and record its checksum. The check is that the archive opens, lists the teams from the scope sheet and contains the attachment or document content your teams expect. If the link expires, request a new export and repeat the check.
Script GraphQL queries for gaps in the CSV
Use Linear's GraphQL API with a personal or service API key to pull what the CSV files leave out, such as comments, cycles, parent and child links, and attachment metadata. Write one script per object type, paginate through every result and write raw JSON to disk. The output is a set of JSON files, one per object type and team. The check is that the number of records returned for each team matches the issue or cycle count recorded in step one, and that a sample of issues shows the same comments in the API response and in the interface.
Download attachment files and match them to issues
Take the attachment URLs collected from the API and download each file, keeping the original filename and recording the issue identifier it belongs to. Some attachments may be inaccessible, moved or removed, so log every failed download with its URL and issue. The output is a folder tree organized by team and issue identifier, plus a failure log. The check is to open a random sample of attachments and confirm each one against its source issue in Linear, including at least one from each team. Any file that cannot be verified goes on the open items list for the owner to resolve.
Store everything with a manifest and checksums
Place the CSV files, the workspace archive, the JSON extracts, the attachment tree and the failure log in one dated location with read-only permissions for most staff. Write a manifest that lists every file, its size, its checksum, the export date, the account and role used, and the row counts compared with the Linear interface. Keep one copy in a second location, such as a separate storage account or encrypted backup. The step is complete when someone who did not run the export can read the manifest, recompute a checksum and reach the same counts.
Verifying the extract before the contract ends
Treat the export as unproven until you have reconciled it against the live workspace. Before the subscription ends, compare record counts by team, by project and by issue state, using the same filters in Linear and in the extract. Where the numbers differ, do not assume the export is at fault. Linear's CSV exports are subject to per-role row limits, so a count taken with a restricted account can look short even when the data is complete. Run the reconciliation with an account holding the widest access you can get, such as an admin or owner, and record any gap that remains in a short reconciliation log.
Counts alone do not prove that comments, attachments and relationships came across. Pick a sample of issues that cover the hard cases: issues with long comment threads, issues with attachments, issues in projects and cycles, and issues linked to parent issues. Open each sample in the extract and check that the text, timestamps, authors and file references match what you see in Linear. Attachments need particular attention, because the CSV holds links rather than files, and the team and project fields may not include every team that holds work. Confirm the missing attachment files and teams against the GraphQL API for a complete extract, and note which items you pulled from the API.
For each export, record the export date, the account role used, the workspace and the people who ran it, and keep the exported files with their checksums in storage you control. This record is what an auditor or a successor team will ask for when a number changes later. Finally, keep the extract readable without Linear: store the files in open formats such as CSV and JSON, keep a data dictionary that explains each column and identifier, and test that someone without a Linear login can open and search the files. The extract is only useful if it can still be read after the subscription ends.
What to plan before the Linear contract renews or ends
Most of the risk in leaving Linear comes from timing, not from the export itself. The decisions below set the scope, the cutoff date and the people responsible before anyone runs a script, so the final extract is complete and checkable.
Confirm the export window and retention terms
Ask Linear's account team for the written terms on workspace data export, the time a generated export link stays valid, and how long workspace data is kept after cancellation. Do not rely on memory or on help-center summaries alone. Record the answers with the date and the name of the person who gave them, because the export window is the limit that sets your final extract date.
Decide which teams and history move
List every team, project and archived item in scope, and state whether closed cycles, old comments and archived issues must move or can stay in a read-only archive. Teams that were deleted or are not visible to your export account can be missed, so check the list against the admin view. Agree on the scope with team leads before the extract starts.
Set the date for the final extract
Pick one cutoff date after which no new issues are created in Linear, and freeze workflows that write to it. Plan a delta export for changes made between the first full run and the cutoff. Without a freeze, the migrated set will drift from the live workspace and reconciliation will fail.
Assign owners for attachments and API scripts
Attachments are the most likely gap in a CSV export, so name one owner to download the files, record their location and check counts per issue. Name a second owner for the GraphQL extraction scripts, including who reviews them and who keeps them after the project ends. An unowned script becomes the only record of your data.
Plan the target environment before scripting
Decide where the extract will be stored and how the target platform will run, including the database, object storage and the edition that supports the import path you choose. Check that the environment can hold the attachment volume and the retention rules your legal team requires. Target choices change the transform scripts, so settle them first.
Budget for the cost drivers
Expect costs in four places: script development, attachment volume and transfer, verification time by team leads, and the infrastructure that holds the extract and the target. Script and verification work is usually a one-time cost, while storage and hosting recur. Ask any implementation partner for a written scope that names each of these items, and ask Linear's account team for the written terms before signing a fixed scope.
Which export path fits your team's situation
A team with a handful of projects and a modest issue count can usually work from Linear's CSV exports and manual attachment downloads. Export issues, projects and members separately, then download attachment files from each issue. Before you rely on the export, confirm the per-role row limit that applies to your account, because it determines whether you must split the export.
- Export CSVs per scope: Export issues, projects and members as separate files and compare each row count with the number of records you expect.
- Download attachments by hand: CSV files do not contain attachment files, so save each one from its issue into a folder structured by team and project.
- Check for missing teams: Confirm that every team and archived project appears in the export, and log any gap in a tracking sheet.
- Capture comments deliberately: Confirm how comments appear in your export, and copy comments from high-value issues separately if they are missing.
- Confirm roles first: Check which workspace role your account needs for CSV and workspace exports in Linear's current documentation.
Reconcile row and attachment counts against Linear before you delete anything. Bring in DeployOpen or an internal engineer once you must split exports repeatedly or the manual attachment count becomes hard to verify.
When cycles, linked attachments and parent-child issue links span many teams, a CSV alone loses structure. A script that calls Linear's GraphQL API can page through every entity, keep the relationships and save the raw responses. Run the script against a read-only key, then keep the CSV files as a human-readable companion to the JSON.
- Create a scoped API key: Use a key tied to an account that can read every team in scope, and confirm the access rules in Linear's API documentation.
- Page through results: Request issues, cycles, projects and attachments with cursor-based pagination, and save each page as raw JSON so a failed run can resume.
- Handle linked attachments separately: Record attachment URLs in a first pass and download the files in a second pass, since linked content may need its own access.
- Preserve relationships: Keep parent, sub-issue, cycle and project identifiers so you can check the import against the source later.
- Validate totals per team: Compare the counts in your output with the Linear interface for each team before any cut-over.
An internal engineer can own the script if your team already runs API integrations. Bring in DeployOpen when pagination, rate limits or attachment access need a fixed-scope script with written verification.
Regulated organizations usually need the complete extract to land in storage they control, with a manifest that records what was exported, when, by whom and with what integrity checks. Agree the scope with your security, records and compliance owners before the first pull. Keep the extraction logic, the manifest and the run logs under the same change control as any other system of record.
- Define the complete extract: List every entity in scope, such as issues, comments, attachments, projects, cycles, members, teams and any available audit history, and document what the export cannot cover.
- Run from a controlled host: Use a service account with a documented role, run the script from a network segment your security team approves, and write output to encrypted storage you control.
- Build a signed manifest: Record file names, record counts, SHA-256 hashes and timestamps, then sign the manifest with a key managed under your key management process.
- Apply retention and access controls: Store the export, the script version and the run log under your retention schedule, with access limited to named roles.
- Test restoration: Load the extract into a staging Plane instance, since Plane's Linear importer runs on Plane Cloud or the Commercial Edition, and reconcile counts before you rely on the extract.
Confirm with your compliance and legal teams which retention and signing requirements apply. DeployOpen can prepare the script, manifest tooling and reconciliation evidence, but independent auditors issue any attestation.
Questions teams ask before they export data from Linear
Can our team export all of our Linear data without outside help?
Often yes for a small workspace, but a complete extract usually needs more than the built-in exports. Linear's CSV exports cover issues, projects and members, and each role has a row limit, so large workspaces will need several passes. The workspace export download link is also time-limited, so a lapsed link means running the export again. Attachment files, some teams and full history are where gaps usually appear. For a complete extract, your team needs someone comfortable using the GraphQL API, paging through results and handling rate limits. If that skill is not in-house, ask for a written scope before you start.
What makes a Linear data export take more effort?
The main drivers are issue volume, the number and size of attachments, the number of teams, and how much custom data each team stores. Projects, cycles, comments, labels, workflow states and parent-child links each add mapping work when the data moves into another tool. Workspaces with many teams often need one export pass per team, and attachment-heavy teams need a separate download plan. Integrations that write data into Linear, such as those for support or code review, can also create records that need checking. Ask the provider to list each of these counts in the scope so the effort can be estimated against real numbers.
How long does it take to export data from Linear?
No reliable duration can be given without knowing your workspace, so treat any generic timeline with caution. The time depends on issue counts, attachment volume, the number of teams, the row limits that apply to your roles, and whether you use the built-in exports or the API. The work also includes validation and handling any failed or partial downloads, which often takes longer than the extraction itself. Ask for a timeline that is tied to the counts in your workspace and to specific milestones, such as a test extract, a full extract and a reconciliation report.
What does our team need to provide for a Linear export?
You need four things: access, a named owner, storage and target system access if you are moving the data. Access means an admin or workspace owner who can run exports and create an API key with the permissions the extract requires. Storage must hold the CSV files and the downloaded attachments, and the space needed depends on your attachment volume. A named owner should approve the scope, review the reconciliation results and sign off on completeness. If the data is moving to a self-hosted Plane instance, confirm which Plane edition runs the importer before you plan the target environment.
Is the CSV export enough on its own?
For most teams, a CSV export alone is not enough. It captures flat fields for issues, projects and members, but it does not reliably carry every attachment file, every team or the full relationship structure. Read the field list against your own use of Linear before you rely on it. Plane's Linear importer, documented in the Plane Linear importer docs, maps more structure directly, but it is not a substitute for a completeness check on your source data. Confirm with Plane which edition the importer requires for your plan before you plan the move.
How do we check that a Linear export is complete?
Compare counts from the export against counts from Linear for every team, project and member. Then sample issues across each workflow state, check that comments and labels match, and confirm that every attachment link resolves to a downloaded file. Keep a manifest that lists file names, sizes and checksums so you can prove later what was exported. Record any missing teams, attachments or fields in a gap report, and have the named owner sign off on each gap before the source workspace is changed. Ask any provider to deliver this reconciliation report as a written deliverable.
What happens to our data after our Linear subscription ends?
Confirm the retention and deletion terms in Linear's current terms and your contract before the subscription end date, because the answer depends on those documents. Do not assume that data remains available after cancellation. Run a full export and store a copy in your own infrastructure while the subscription is active, then verify the copy. Keep the checksums and the reconciliation report alongside the data so you can show what was held and when. If you plan to rely on the copy for records or audits, ask your legal and compliance team to confirm the retention requirements that apply to it.
What does DeployOpen do during a Linear data export?
DeployOpen plans and runs the export under a written, fixed scope, then documents the output and the checks that confirm it. The scope should name the teams, projects, attachments, API extracts and reconciliation steps covered, along with the deliverables and dates. DeployOpen can also prepare the self-hosted target environment and the import, but it does not issue audit reports or certifications. DeployOpen does not publish a price list, so ask for a quote that follows from the written scope. Ask for the exact deliverables, the acceptance criteria and who on your side signs off.
How DeployOpen scopes and delivers a Linear data export
DeployOpen treats a Linear export as a fixed-scope engagement: the workspace, teams, attachments and API extract are agreed in writing before any work starts. The export is then built, checked against the source workspace and handed over with documentation that your team and your migration partner can reuse.
How we scope
- Inventory every team, project and workspace area that must be included in the extract.
- Agree in writing which CSV exports, attachment handling and GraphQL API pulls the export will use.
- Confirm where the export files will be stored and who in your organization may access them.
How we build
- Run the CSV exports for issues, projects and members, and record the row limits that apply to each role.
- Script GraphQL API extraction to cover teams and attachment files that the CSV exports leave out.
- Test the output against the source workspace, comparing record counts and spot-checking sample issues.
How we hand over
- Deliver the extracted files with a written map of which source fields and teams each file contains.
- Document known gaps, such as missing attachment files or excluded teams, with the steps to close them.
- Store the extract inside your own infrastructure and transfer ownership of the scripts and runbook to your team.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope delivery.
- Re-run the extract on request when your team needs a refreshed snapshot before a cutover.
- Confirm support terms, response expectations and retainer scope with your team in the written agreement.
