Linear → GitHub Issues
Move Linear issues, comments, labels, cycles, and projects into GitHub Issues and Projects without treating a CSV download as a finished tracker.
Should you make this move?
Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.
Linear
- Fast, opinionated product-development workflows keep software teams focused
- Structured ownership, status, and workflow views improve operational visibility
- Non-software work and highly customized enterprise processes fit poorly
- Custom fields, automations, history, and reporting are difficult to reproduce exactly
GitHub Issues
- Lightweight planning stays directly connected to code, pull requests, and releases
- Structured ownership, status, and workflow views improve operational visibility
- Cross-team planning, reporting, and workflow controls are intentionally limited
- Custom fields, automations, history, and reporting are difficult to reproduce exactly
GitHub Issues: Lightweight planning stays directly connected to code, pull requests, and releases. This removes a major source-side concern: Non-software work and highly customized enterprise processes fit poorly.
What you lose: Fast, opinionated product-development workflows keep software teams focused. What you inherit: Cross-team planning, reporting, and workflow controls are intentionally limited.
Jump to a section
Know the shape of the move.
This timeline assumes
- Up to 20 Linear teams, 25,000 issues, and 150 users
- Repository, project, and identity owners agree which GitHub repos receive which Linear teams.
- Users exist on GitHub before assignment mapping.
- A representative team is imported and signed off before the full workspace.
- The migration team records evidence for every blocking verification check.
What survives the move.
“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.
| Item | Outcome | Impact | What happens | Mitigation |
|---|---|---|---|---|
| Workspace CSV issue fields | partial | critical | Linear admins can export workspace issues from Settings > Administration > Import Export. The file includes ID, team, title, description, status, estimate, priority, project, people, labels, cycle, dates, parent issue, initiatives, milestone, and SLA. The download link expires after 12 hours. | Download the export immediately, hash it, and treat missing columns as a mapping problem before you create GitHub issues. |
| Comments and customer requests | manual | critical | The CSV export does not include comments. Linear's markdown copy command can capture title, description, comments, and customer requests for selected issues. The API is the path for a full comment set. | Export comments through the API or markdown copy for decision-heavy issues. Prefix each GitHub comment with the original author and time. |
| Attachments | lost | high | Linear states that CSV exports do not include attachment files. Links may appear in descriptions. | Copy required binaries into GitHub issue attachments or a durable store. Test access without a Linear login. |
| View-sized CSV limits | partial | high | Members can export 250 issues from a view. Admins can export 2,000. Guests cannot export. A view export is not a workspace backup. | Use the admin workspace export for the full set. Do not stitch guest screenshots into the source of truth. |
| Teams, cycles, and initiatives | manual | critical | Linear has no CSV export for teams. Cycles and initiatives become GitHub milestones, project fields, or labels only after you design the mapping. GitHub Issues has no native cycle. | Map each Linear team to a repository or GitHub Project. Rebuild only the cycles people still plan against. |
| Parent issues and hierarchy | partial | high | The CSV includes a Parent issue column. GitHub can store a parent as a sub-issue, a blocked-by link, or a body reference. Those are not the same Linear tree. | Create parents first. Store Linear ID to GitHub number. Attach children in a second pass. |
| Assignees and former members | partial | critical | GitHub can assign only users who can access the repository. Linear members without a GitHub seat become unassigned. | Export the Linear member CSV. Map by email. Leave unmatched work unassigned and keep the Linear handle in the body. |
| Statuses, labels, and estimates | partial | high | GitHub issues are open or closed. Extra Linear states need labels or project status fields. Estimates and priority have no default GitHub issue field. | Create the label and project-field set before import. Map every Linear state to one GitHub state plus one field. |
| Automations, SLA, and Linear workflows | lost | critical | Linear automations, SLA status, and triage do not execute on GitHub. GitHub Projects can add built-in workflows later, attributed to github-project-automation. | Inventory every Linear rule. Recreate only approved GitHub Actions or Project workflows after intake moves. |
| Private teams and audit trail | partial | high | Workspace CSV can include private teams when the admin toggles that option. The export is recorded in Linear's audit log. GitHub repository visibility is a separate decision. | List private teams first. Create private repositories or restricted projects before those issues land. |
| Live Linear sync after cutover | lost | high | There is no official Linear-to-GitHub Issues importer. A one-time API load and a leftover Linear sync bot will create two issue sets. | Disable Linear sync tools such as synclinear.com before GitHub owns intake. |
Where each thing goes.
| Source | Destination | Method | Notes |
|---|---|---|---|
| Linear team | GitHub repository or Project | manual | Linear has no team CSV. Write the map by hand. |
| Issue ID and title | GitHub issue title plus Linear ID in the body | transform | Keep the Linear identifier for reconciliation. |
| Description | Issue body | transform | Convert Linear markdown and strip broken attachment links. |
| Status | Open or closed plus Project status or label | transform | Map business meaning, not only open versus closed. |
| Assignee | GitHub assignee | manual | Unmatched users stay unassigned. |
| Labels, priority, and estimate | Labels or Project fields | transform | Create fields before the load. |
| Parent issue | GitHub parent, sub-issue, or body reference | transform | Create parents first. |
| Cycle or project | Milestone or Project | manual | Rebuild only active cycles. |
| Comment | Issue comment | manual | CSV will not carry these. Use the API and prefix authorship. |
Make the move recoverable.
Create the source-of-truth backup
Preserve Linear issues, members, comments, and files before any GitHub write.
- Run the admin workspace CSV export, including private teams if they are in scope.
- Export the member list CSV from Settings > Administration > Members.
- Pull comments, customer requests, and attachment URLs through the API or markdown copy.
- Hash every file and record Linear ID counts by team and status.
Proof to capture: A signed manifest reconciles every scoped Linear ID, export file, count, and hash.
Team and state map
Place each Linear team and status on a GitHub repository, project, and field.
- Map every team to a repository or Project.
- Map every status to open or closed plus a field or label.
- Reject unmapped critical states.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
Issue and comment load
Create GitHub issues without losing Linear IDs or comment authors.
- Create parents first and store Linear ID to GitHub number.
- Add comments with original author and timestamp prefixes.
- Add issues to the destination Project after numbers exist.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
The things most likely to hurt.
These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.
CSV-only import drops comments and files
Issues appear in GitHub with titles and empty discussion.
- Consequence
- Decision history stays trapped in Linear.
- Mitigation
- Treat comments and attachments as a separate load. Sample decision-heavy issues before scaling.
Stop if: A required comment or file has no destination copy.
Private Linear work lands in a public repo
A private team export is loaded into a public repository or org Project.
- Consequence
- Internal design or security work becomes public.
- Mitigation
- Create and test private destinations before those issues move.
Stop if: An unauthorized account can open restricted work.
Linear sync keeps creating GitHub issues
synclinear.com or another bridge still writes after intake should have moved.
- Consequence
- Duplicates appear and status diverges.
- Mitigation
- Disable every Linear-to-GitHub writer before you announce the cutover.
Stop if: An unapproved Linear writer remains active.
Do the work in this order.
- Days 1–3 · inventory
Inventory and repo design
6–12 hours active2–3 days elapsedOwner review waiting- Inventory Linear teams, projects, cycles, users, and automations.
- Approve which GitHub repositories and Projects receive each team.
Depends on: Linear admin and GitHub repository admin access
Stop / go checkpointExport?
Go when: Every critical team has a destination and an owner.
Stop when: Private-team handling or identity mapping is unclear.
- Days 3–5 · backup
Backup and reconcile
5–10 hours active1–3 days elapsedExport email link waiting- Download the workspace CSV before the 12-hour link expires.
- Export members, comments, and attachment evidence.
Depends on: Approved inventory
Stop / go checkpointTransform?
Go when: Linear ID totals and export manifests agree.
Stop when: Any in-scope team or comment class is absent.
- Days 5–14 · pilot
Map and pilot
12–40 hours active4–9 days elapsedOwner review of the sample waiting- Load one team that includes a parent issue, a comment thread, and a file.
- Compare Linear IDs, states, and Project placement.
Depends on: Verified backup
Stop / go checkpointScale?
Go when: Pilot mappings, access, and evidence pass.
Stop when: Any critical check fails or a count is unexplained.
- Days 12–20 · cutover
Final delta and switch
5–18 hours active1–4 days elapsedFinal API load waiting- Freeze Linear writes and disable sync tools.
- Load the final delta, switch intake, and run blocking checks.
Depends on: Passed pilot and approved rollback
Stop / go checkpointOpen production?
Go when: Every in-scope Linear ID is accounted for and GitHub owns intake.
Stop when: A Linear writer remains active or a blocking check fails.
- Days 14–35 · observe
Observe and close
3–16 hours active4–10 days elapsedOne delivery cycle waiting- Watch one complete planning and pull-request cycle.
- Sign the verification report before you close rollback.
Depends on: Verified cutover
Stop / go checkpointClose rollback?
Go when: No trigger occurs during the agreed observation period.
Stop when: Work, access, or pull-request linking regresses.
Cut over with a way back.
Cutover
Make GitHub Issues the only intake system without losing the final Linear delta.
- Freeze Linear writes, automations, and sync bridges.
- Export and create the final changed issues.
- Switch community intake, internal boards, and agent tooling to GitHub.
- Run every blocking check and keep Linear readable.
- Keep the source intact through the rollback window.
Proof to capture: GitHub owns intake, every in-scope Linear ID is accounted for, and every blocking check has evidence.
Rollback
Return intake to Linear without losing GitHub-era changes.
- Stop new GitHub issue creation from migrated workflows.
- Restore Linear access, automations, and intake links.
- Export GitHub issues created after cutover.
- Review and apply safe destination-era changes to Linear.
- Run the same blocking checks against Linear.
Proof to capture: Linear again owns intake with current work and no duplicate GitHub action.
- Unexplained missing Linear IDs
- Missing comments or files
- Duplicate production action
- Failed access or assignment check
- A critical Linear workflow has no safe GitHub replacement
Prove the migration worked.
Every blocking check must pass. Capture the evidence before cleanup begins.
| Pass | ID | Check | Method | Expected result | Evidence |
|---|---|---|---|---|---|
V-01Blocking | Issue reconciliation | Compare every in-scope Linear ID to a GitHub issue, archive, or exclusion. | 100% of scoped IDs are accounted for. | ID ledger. | |
V-02Blocking | Parents and children | Inspect representative Linear parent trees in GitHub. | Approved links exist. | Hierarchy report. | |
V-03Blocking | Status and Project fields | Move sample issues through every approved state. | Open or closed plus field values match the signed map. | State log. | |
V-04Blocking | Assignees and former members | Test matched, unmatched, and departed users. | Assignments follow the sheet. Unmatched handles remain in the body. | User matrix. | |
V-05Blocking | Comments and files | Open decision-heavy issues and their attachments as ordinary users. | Required history and files work without a Linear login. | Context log. | |
V-06Blocking | Private teams | Open a private-team sample from an unauthorized account. | Restricted work stays hidden. | Access test. | |
V-07Blocking | Single writer | Create and update a test issue after freeze. | Only GitHub acts. Linear sync stays still. | Automation log. | |
V-08Blocking | Pull-request linking | Open a pull request that closes a migrated issue. | The issue closes through the GitHub link. | PR close log. |
Remove the scaffolding safely.
Safe after: One complete delivery cycle, at least seven stable days, and owner sign-off on every blocking check.
- Archive Linear CSVs, API exports, and verification evidence.
- Revoke migration tokens and Linear sync apps.
- Remove obsolete Linear automations and public intake links.
- Keep Linear readable through the approved retention window.
- Cancel paid Linear plans only after billing, legal, and recovery review.
- Schedule the next GitHub Issues backup, access, and playbook review.
When the plan met reality.
First-hand accounts are preferred. Vendor case studies are labeled, and every note below is an editorial paraphrase—follow the link for the full context.
Documenso left Linear on 10 January 2024 and put backlog, design, and community work on GitHub. They had used synclinear.com to show selected Linear issues to the community. After the move they split work across the main repo, a public backlog, an internal backlog with a GitHub Project, an internal design backlog, and a public design repo. They also stopped publishing feature timelines on the live roadmap and now show only current work and what is next. The post explains the new structure. It does not describe a bulk issue importer or comment fidelity.
- Decide which Linear issues belong in a public repo before you copy titles, because community visibility changes what you should migrate.
- If you used a Linear-to-GitHub sync bridge, turn it off before GitHub owns intake so the two trackers do not keep writing.
- The team moved to GitHub to spend time where contributors already were, not because a Linear export failed.
- They used extra repositories to keep long-term and internal work out of the main issue list.
Xiaofei Du wrote that a ten-person team had left ClickUp for Linear in 2023, then later stopped opening Linear and asked an agent through Linear MCP instead. After that product ended, Xiaofei and Pinglin built Pingbo as two people. They tried a custom Cloudflare board, then chose GitHub issues because the code already lived there and issues link to pull requests. They still generate a taste board from the GitHub API. The post is about why they stopped paying for Linear. It does not document a historical issue import or comment migration.
- If the goal is one less subscription next to GitHub, start with issues and Projects, and keep Linear readable until those queries replace the old board.
- Do not treat a two-person agent workflow as proof that a fifty-person org can drop Linear. The author says that case is untested.
- They left Linear after they stopped using the UI, not after a failed data export.
- GitHub issue timestamps and close state mattered more to them than a custom markdown board.
Verify against the primary material.
Platform behavior changes. Check these sources and the review dates above before executing a production migration.
- Linear: exporting dataAccessed 2026-10-25
- GitHub REST API: issuesAccessed 2026-10-25
- GitHub: add items to a projectAccessed 2026-10-25