We Outgrew GitHub Issues at 500 Tickets. Linear Was the Obvious Next Step.
GitHub Issues was our issue tracker for two years. Not because we evaluated it and chose it, but because it was already there. Every repository comes with Issues enabled by default. When we were six engineers working on a single repo, opening an issue was the same as opening a tab in the browser we were already using. No new tool, no new login, no new cost. The friction was zero, and zero friction beats every feature comparison.
We started hitting limits around 300 issues. By 500, the limitations were affecting our daily workflow. The migration to Linear took a weekend. The relief was immediate.
But I want to be specific about what GitHub Issues does well, because for small teams with low issue volume, it's a legitimately good choice. And there's one area where it still beats Linear.
What GitHub Issues Does Well
The pull request integration is the single best thing about GitHub Issues. When an engineer opens a PR, they type "Fixes #142" in the description, and issue 142 automatically closes when the PR merges. The issue-to-code connection is native, automatic, and requires zero configuration. You can reference issues in commit messages, branch names, and code comments. The issue timeline shows every commit, PR, and code reference. For understanding "what code changed because of this issue," nothing else comes close.
GitHub Projects (the newer project board system, not the legacy one) added views, custom fields, and workflow automations. You can create board views, table views, and roadmap views. Custom fields support text, number, date, single select, and iteration types. The iteration field gives you basic sprint functionality. For a free tool, the feature set improved substantially in the last two years.
Labels are flexible and free-form. You can create as many as you want with any naming scheme. Color coding helps with visual scanning. Most teams start with "bug," "enhancement," "documentation," and "good first issue," then add more as needed.
Milestones group issues into releases or timeframes. They show a progress bar based on the ratio of open to closed issues. For teams that ship on a release schedule, milestones are a simple way to track what's in each release.
The cost is zero for public repos and included in every GitHub plan for private repos. For a bootstrapped startup using GitHub for code hosting, adding Issues costs nothing.
Where We Hit the Wall
The first problem was discoverability at scale. GitHub Issues has a filter bar that supports label, assignee, milestone, and text search. At 200 issues, filtering worked fine. At 500, Tomás started spending two to three minutes per search trying to find issues he remembered filing but couldn't locate. The filter syntax is powerful but text-based, and there's no saved filter system beyond pinning a filter URL. In practice, engineers would bookmark URLs like ?q=is%3Aopen+label%3Abug+assignee%3Atomás which broke if anyone renamed a label.
Priority was the gap that hurt most. GitHub Issues has no native priority field. We used labels: "P0-critical," "P1-high," "P2-medium," "P3-low." But label-based priority has problems. Labels don't sort. You can filter to show only P1 issues, but you can't sort a mixed list by priority. There's no priority view that shows all issues ordered by urgency. Every engineering meeting where Priya asked "what are the top five priority items right now?" required manually scanning the board and mentally sorting.
Workload visibility didn't exist. GitHub Issues shows issues per person, but there's no workload view with story points, capacity indicators, or overload warnings. Priya's capacity planning lived in a spreadsheet she maintained manually.
Sprint management was awkward. We used milestones for sprints, but milestones lack start dates, velocity tracking, burndown charts, and carry-over automation. When a sprint ended, someone had to manually move incomplete issues to the next milestone.
Cross-repository issues were painful. Our codebase grew from one repo to seven. GitHub Issues are scoped to a single repository. GitHub Projects can pull from multiple repos, but keeping the project board and issue lists in sync added overhead.
Automation was limited. GitHub Actions can respond to issue events, but building triage logic with YAML workflows designed for CI/CD pipelines felt like using a hammer to tighten a screw.
The Migration
We moved to Linear over a long weekend. Tomás wrote a migration script using Linear's API that pulled all open issues from our seven GitHub repos and created corresponding Linear issues. Labels mapped to Linear labels. Assignees mapped to team members. Milestones mapped to cycles. The script handled about 340 open issues in roughly fifteen minutes.
What the script couldn't migrate was the issue-to-PR linkage. All those "Fixes #142" references now pointed to closed GitHub Issues that no longer tracked active work. We accepted this as a one-time cost. Going forward, Linear's GitHub integration creates a two-way link between Linear issues and PRs, but it's not as seamless as GitHub's native reference system.
What Changed Immediately
The speed difference was the first thing everyone noticed. Linear's local sync engine means the interface responds instantly. Clicking on an issue loads it in under 100 milliseconds because the data is already cached on your machine. GitHub Issues requires a server round trip for every page load. The difference in absolute time is small (maybe one to two seconds per interaction), but at dozens of interactions per day, it changes the experience from "using a web app" to "using a desktop app."
Priority became a first-class concept. Linear's fixed five-level priority system (Urgent, High, Medium, Low, No Priority) replaced our label-based workaround. Every issue has a priority. The backlog can be sorted by priority. Priya's "top five items" question became a ten-second answer instead of a five-minute search.
Cycles gave us real sprint management. Start dates, end dates, scope tracking, carry-over automation. When a cycle ends, unfinished issues automatically move to the next cycle. The burnup chart shows progress over time. Velocity tracking shows story points completed per cycle. Priya stopped maintaining her sprint spreadsheet the first week.
Team views solved the cross-repository problem. Linear's team concept groups issues by team regardless of what code they touch. The Platform team's board shows their work across all seven repos. No more separate issue lists per repository.
Keyboard shortcuts made triage fast. Kenji could process thirty issues in about five minutes using keyboard shortcuts for priority, assignment, and cycle placement. In GitHub Issues, the same triage required opening each issue, clicking dropdown menus, and clicking save. Similar number of actions, but the speed difference per action was around 3x.
What We Miss
The PR integration. Linear's GitHub integration is good. When you create a branch from a Linear issue, the issue ID is in the branch name. PRs reference the issue. The issue timeline shows PR status. But it's not as tight as GitHub's native integration. "Fixes #142" in a commit message doesn't auto-close a Linear issue. You need to use Linear's branch naming convention or manually link the PR. For engineers who lived in the GitHub flow, this was the biggest adjustment.
The proximity to code. In GitHub Issues, you're already in the repo. You can reference a line of code, link to a file, and see the code context without switching tools. In Linear, you're in a separate application. The code lives in GitHub. The issues live in Linear. The two are connected by links and integrations, but they're not in the same place. For debugging sessions where you're jumping between code and issues, the context switch is real.
Free. GitHub Issues costs nothing. Linear is $8 per user per month. For a ten-person team, that's $960 per year. Not much, but GitHub Issues is literally free. For pre-revenue startups counting every dollar, the zero cost of GitHub Issues is meaningful.
The Agent Layer
Linear solved our organizational problems: priority, sprints, team views, workload visibility. But it didn't solve our process problems: daily standup preparation, sprint reporting, and keeping the team informed about what happened while they were sleeping.
We added a standup generator that posts daily activity summaries from Linear to Slack. It reads what each person worked on yesterday (issues moved to In Progress, issues completed, comments added) and posts a summary at 9 AM. Our standup meetings went from status recitation to blocker discussion. The time savings are about eight minutes per standup across the team, which adds up to roughly 30 hours per month.
The standup generator works because Linear's data model is clean. Every state change, comment, and assignment is tracked in the issue activity. The agent reads that activity stream and composes a readable summary. In GitHub Issues, the equivalent data exists in the timeline but it's mixed with CI events, PR reviews, and deployment notifications.
Priya also uses a sprint status reporter that generates Friday summaries with completion rates and velocity trends. She forwards it to leadership without editing it most weeks. Neither GitHub Issues nor Linear's native features can analyze sprint data and write a narrative about what it means. Agents handle that layer.
The Decision Framework
If you're a team of five or fewer working on a single repo, start with GitHub Issues. The PR integration alone is worth it, and the organizational limitations won't bite you yet. Save the $8 per user per month for something else.
If you're a team of ten or more, or you work across multiple repos, or you need sprint management with velocity tracking, or you need priority-based sorting, or your engineering manager is maintaining a spreadsheet to track workload, you've outgrown GitHub Issues. Linear is the natural next step because it solves exactly the problems that GitHub Issues doesn't handle.
The migration is a weekend's work. The adjustment period is about a week. The PR integration gap is the only lasting trade-off, and Linear's GitHub integration is good enough that most engineers stop noticing the difference within a month.
We waited too long. We should have moved at 300 issues instead of 500. If your GitHub Issues backlog is getting hard to search and your sprint process involves spreadsheets, you're probably past the point where the switch makes sense.
Try These Agents
- Linear Slack Standup Generator -- Daily activity digests from Linear posted to Slack without manual status collection
- Linear Sprint Status Reporter -- Friday sprint summaries with velocity trends and completion analysis
- Linear Issue Triage Agent -- Automatically categorize and route new issues to the right team