GitHub Projects has no Export button. There's a CSV importer for bringing data in, but nothing in the UI to pull your board back out — the only ways to get your items into a file are the GitHub API, the gh CLI, or a third-party script. For a team that picked GitHub Projects specifically because it required zero setup, that's a strange wall to hit on the way out.
This isn't a pitch for switching. It's a walkthrough of what happens, mechanically, if you do: how a GitHub Projects board maps onto Spryn, how the import actually works without a native connector to lean on, and what changes once your team is planning against capacity instead of a date-range field.
Why this migration looks different from the others
Spryn imports from Jira, Asana, ClickUp, and Linear over OAuth — connect the account, pick a project, preview, done. GitHub Projects isn't on that list, and not because GitHub is obscure. It's because Projects was built as a thin layer over Issues, not as a standalone tracker with its own export API the way Jira's or Linear's is. Pulling items out means querying the GraphQL API for the project's fields and values, which is a developer task, not a one-click OAuth flow.
That's actually fine for the audience that ends up on this page. A team using GitHub Projects for sprint planning is, by definition, a team of developers. Running gh project item-list or a short script against the API to get a CSV is a smaller ask here than it would be for a Trello or Asana user — it's the same skill set the team already uses every day.
The core mapping
GitHub Projects is intentionally minimal — a project is really just a saved view over Issues with some extra fields layered on. Mapping it onto Spryn means giving each of those fields an explicit sprint meaning:
> An Iteration in GitHub Projects is a date range with a name — nothing more. It doesn't know how many people are on the team, how many hours they have, or how much is already assigned to the next one. Spryn's sprint is the same date range plus a capacity number it checks against before you lock it, which is the one thing a GitHub Projects iteration was never built to do.
The Status field — usually Todo / In Progress / Done, sometimes with a custom board layout — maps directly to Spryn's execution board states. Custom fields (priority, size, team) come across as their closest Spryn equivalent; single-select fields map cleanly, free-text fields need a quick review since nothing enforced consistent values on the GitHub side. Milestones, if your repo also used them alongside Projects, fold into Spryn's epics rather than staying a separate concept.
What the import actually does
1. Pull. Query the GitHub API (or run a community CSV-export script against the ProjectV2 API) for the project's items, fields, and values. This is the step without a GitHub-provided UI, so budget the most time here.
2. Clean up. Check the resulting CSV for the custom fields your team actually used consistently — this is the same manual review the mapping above calls out, done once before upload instead of issue-by-issue after.
3. Upload. Bring the CSV into Spryn's importer and map each column — issue title, status, iteration, custom fields — to its Spryn field.
4. Preview. Review exactly what will be created before confirming anything, the same preview-before-commit step every Spryn import uses.
5. Confirm. Approve the import. Nothing is deleted or changed on GitHub's side — your repo, issues, and the Projects board stay exactly as they were.
Because step one has no GitHub-provided export to lean on, this import takes more up-front effort than the OAuth sources. Most of that effort is a one-time script or CLI command, not a recurring task.
What you gain, and what you lose
Capacity planning replaces a date range that doesn't check anything. A GitHub Projects iteration can hold any number of issues of any size — nothing in the field itself flags that the team has taken on more than it can finish. Spryn checks committed work against team capacity while you're building the sprint, so an over-commitment is visible before the iteration starts.
Insights stop being a chart you configure yourself. GitHub Projects does have a built-in Burn-up chart and a custom chart builder for historical, time-series views — it's a real feature, not nothing. But it's self-serve: someone has to build and maintain the chart, pick the X-axis, and decide what it's grouped by. Spryn computes sprint velocity and health automatically from the sprint's own data and carries the number into the next planning session without anyone maintaining a chart.
Standup and retro prep get written, not reconstructed. GitHub Projects has no concept of a standup or a retro — a team doing either today is doing it in a meeting, a doc, or a separate tool entirely. Spryn's AI drafts the standup summary before the meeting and the retro narrative at sprint close, from the same sprint data the board already has.
What you lose is GitHub Projects' zero-setup simplicity for anything that isn't a committed sprint. If your repo's project board is really a loose backlog, a triage queue, or a roadmap view with no commitment step, that use case is still better served by staying exactly where it is — Spryn's capacity checks and sprint close only add value once a team is actually committing to a scope, not just tracking one.
Deciding if it's worth the move
- If your "sprint" today is an Iteration field with issues dropped into it and nobody checking whether that's too much work for the team, capacity-aware planning is the direct fix.
- If someone glances at the Burn-up chart each week and mentally does the velocity math themselves, that step goes away — Spryn computes it from the sprint data without anyone building a chart first.
- If your team's standups or retros currently happen from memory because the board doesn't carry that context, the AI-drafted summary and retro narrative are the more concrete win here than the import mechanics.
- If most of what's on the board is genuinely a backlog or a roadmap rather than a committed sprint, leave that part on GitHub Projects — migrate only the work that's actually running against a sprint cadence.
If the fit looks right, pull one project's items into a CSV and run the preview step before deciding anything else — it costs nothing to see exactly what would move, and your GitHub repo and its Projects board stay untouched regardless of what you decide afterward.
See spryn.io/switch-to-spryn for the full list of import sources, or spryn.io/sprint-planning-software for how capacity-aware planning works once the backlog is in. Spryn's self-hosted licence is a one-time $99 payment for unlimited seats if keeping everything — code and sprint data both — on your own infrastructure is part of the appeal.