# Moving from Linear to GitHub Issues > **TL;DR** Map each Linear team to a repository and a GitHub Project, cycles to an iteration field, priority and estimate to project fields, and labels to repository labels. Export issues from Linear as CSV (Settings > Administration > Import Export, admins only), create the fields and labels in GitHub first, then import open issues with a short script around gh issue create. Comments and attachments do not come across in the CSV. Run both tools for a cycle or two, then stop creating issues in Linear. Moving from Linear to GitHub Issues takes four steps: map Linear's concepts to GitHub's, set up the repositories and project fields, export from Linear and import into GitHub, then run both until the team stops opening Linear. Most of the work is in the mapping. The import itself is a short script. If you are moving because you reached Linear's free-plan limit, check first whether archiving or paying suits you better: [Linear's free plan and its 250-issue limit](/guides/linear-free-plan-250-issue-limit) compares the three options. ## How do Linear's concepts map to GitHub? Most Linear concepts have a GitHub equivalent, but in GitHub they sit in two places: the issue, which lives in a repository, and the GitHub Project, a board that can hold issues from many repositories. Planning fields such as priority and cycle live on the project, not on the issue. | Linear | GitHub | Notes | | --- | --- | --- | | Workspace | Organization | One organization holds the repositories and projects | | Team | Repository, plus a Project for its board | An issue belongs to exactly one repository | | Workflow status | Status field on the Project | A single-select field; rename options to match your states | | Priority | Custom single-select field | Recreate Urgent, High, Medium, Low as options | | Estimate | Custom number field | | | Cycle | Iteration field | Any length, breaks allowed, no rollover | | Label | Repository label | Labels are per repository; create them in each | | Parent issue | Sub-issue | | | Due date | Custom date field | | | Linear project | A GitHub Project, or a milestone | Pick one and use it consistently | | Initiative | No equivalent | A Project that spans repositories comes closest | | Triage | No equivalent | A saved view of items with no Status comes closest | A GitHub Project holds up to 50 fields, built-in and custom together (GitHub docs, checked 2026-09-24). That is enough for this mapping with room left over. ## How should you split teams into repositories? Put each team's issues in the repository that holds its code. If a team works across several repositories, keep issues with the code they change and give the team one GitHub Project that pulls from all of them. A team with no code, such as design or support, can have a repository used only for issues. Linear's Free plan allows two teams (Linear pricing page, checked 2026-09-24), so most teams leaving Free have one or two teams and one or two repositories. The mapping stays small. ## How do you set up the GitHub side first? Create everything the import will point at before you import anything: 1. **Create the Project.** One per team, or one for the whole organization if the team is small. 2. **Add the fields.** Rename the Status options to your Linear states. Add Priority as a single-select field, Estimate as a number field, and an iteration field for cycles. When you create an iteration field, GitHub makes three iterations for you (GitHub docs, checked 2026-09-24). 3. **Create the labels** in each repository, with the same names as in Linear, using `gh label create`. An import that uses a label the repository does not have fails. 4. **Invite people.** Assignees must have access to the repository before issues can be assigned to them. ## How do you export issues from Linear? Use Linear's workspace CSV export: Settings > Administration > Import Export, then **Export data** at the bottom. Workspace admins can run it; on Enterprise plans only owners can. Linear emails a download link that expires after 12 hours (Linear docs, checked 2026-09-24). Each row carries the issue's ID, team, title, description, status, estimate, priority, project, creator, assignee, labels, cycle number and name, cycle dates, created, started, completed, canceled and archived dates, due date and parent issue. Comments are not in the list, and the docs state that attachment files are not included (Linear docs, checked 2026-09-24). If you need comment history, pull it from Linear's API, or keep the export as an archive and link to it. For a smaller move, any issue view can be exported as CSV from the command menu. Members can export up to 250 issues at a time and admins up to 2,000 (Linear docs, checked 2026-09-24). ## How do you import the issues into GitHub? GitHub has no CSV importer for issues, so import with a script that reads the CSV and calls `gh issue create` for each open issue. This one uses Python's `csv` module, because Linear descriptions contain commas and line breaks that shell tools split wrongly: ```python import csv import subprocess REPO = "your-org/your-repo" PROJECT = "Your project title" with open("linear-export.csv", newline="") as export: for row in csv.DictReader(export): if row["Completed"] or row["Canceled"]: continue body = f"{row['Description']}\n\nImported from Linear {row['ID']}." command = ["gh", "issue", "create", "--repo", REPO, "--title", row["Title"], "--body", body, "--project", PROJECT] for label in (part.strip() for part in row["Labels"].split(",")): if label: command += ["--label", label] subprocess.run(command, check=True) ``` Check how your export separates labels before running it; the script assumes commas. Adding to a project needs a token with the `project` scope (`gh auth refresh -s project`). Run it against a test repository first. The script sets title, body, labels and project. Priority, estimate, status and iteration are project fields, so set them afterwards: sort the Project's table view by the Linear ID in each body and bulk-edit, or script `gh project item-edit`. Import only open issues and leave closed history in the Linear export. That keeps the new board clean. ## What do you lose moving from Linear to GitHub? You lose Linear's planning layer and some of its speed. As of Gitsu's August 2026 comparison of the two: - **Cycle automation.** GitHub iterations are a field. Nothing rolls unfinished work into the next iteration or tracks velocity. - **A triage inbox.** There is no first-class queue for new, unassigned work. A saved view is the closest substitute. - **Initiatives.** Nothing sits above projects. - **Notifications in the tool.** GitHub's notifications work, but they live on github.com and in email, not in your board. GitHub gives some of this back in other ways. Built-in project workflows can set fields when items are added or changed, and a project can auto-add issues from a repository that match a filter (GitHub docs, checked 2026-09-24). Pull requests and issues live in one place, so `Closes #42` in a pull request closes the issue on merge with no integration to maintain. Linear is the better tool if your team plans in cycles and triages daily. GitHub Issues is the better fit if your team lives in pull requests and would rather have one system than two. ## How do you run Linear and GitHub side by side? Run both for a cycle or two, then stop creating issues in Linear. Linear's GitHub integration links pull requests to Linear issues, updates Linear statuses from pull request activity, and can sync issues between a GitHub repository and a Linear team one way or both ways (Linear docs, checked 2026-09-24). For open-source projects, SyncLinear is a community bridge built to sync tickets between the two (Gitsu research, 2026-08-22). A cutover that works: 1. **Week one.** Import open issues. New bugs go into GitHub; planned work still starts in Linear. 2. **Next cycle.** Plan the iteration in the GitHub Project. Linear becomes read-only by agreement. 3. **After that.** Export Linear once more for the record and stop paying for seats. Keeping two trackers in sync for long costs more than it saves. Duplicate state and broken syncs are the usual complaints (Gitsu research, 2026-08-22). ## Where does Gitsu help after the move? After the move, Gitsu is a faster client for the GitHub Projects board you just built. It maps your project's fields onto Status, Priority, Estimate and Cycle, filters on any field, and bulk-edits many items at once, which helps when setting priorities on a freshly imported board. It does not import from Linear, and it adds none of the planning features listed above. For a longer comparison of the two tools before you commit, read [Linear vs GitHub Issues](/compare/linear). If agents will work the new board, [the Claude Code workflow for GitHub issues](/guides/claude-code-github-issues-workflow) sets out the loop. ## Frequently asked questions ### Can I import a Linear CSV into GitHub Issues directly? No. GitHub has no CSV importer for issues. Use a short script that reads the CSV and calls gh issue create for each row, or GitHub's REST or GraphQL API. ### What replaces Linear cycles in GitHub? An iteration field on a GitHub Project. Iterations can be any length, can include breaks, and can be filtered with @current, @previous and @next. There is no automatic rollover of unfinished work. ### Do comments come across in a Linear export? Not in the CSV. Linear's issue CSV lists title, description, status, priority, labels, cycle, dates and parent issue, but no comments, and it excludes attachment files. Pull comments through Linear's API if you need them. ### Can Linear and GitHub Issues run side by side during a migration? Yes. Linear's GitHub integration links pull requests to Linear issues and can sync issues between a GitHub repository and a Linear team, one way or both ways. ### Does Gitsu import issues from Linear? No. Gitsu has no Linear importer. It works with GitHub Projects boards after the issues are in GitHub.