Cursor Origin
Migrating from GitHub to Cursor Origin
You can't migrate to Origin yet; it is waitlist-only as of mid-2026. When it opens, the git part, history, branches and tags, moves cleanly because git is portable. The hard part is everything outside git: pull requests, issues, CI, integrations and permissions. Plan for those, not the repo.
On this page
Can you move from GitHub to Origin yet?
No. Origin is waitlist-only, so there is nothing to migrate into today. That makes this a planning guide, not a runbook. The useful thing you can do now is understand what a git-host move actually costs, because the answer surprises people: the repository is the easy part.
As of June 2026, cursor.com/origin is a waitlist with no import tooling described. Any migration feature, GitHub importer, PR history transfer, will need to be confirmed on a Cursor source when Origin ships. Don't assume it exists.
What moves cleanly, and what doesn't?
Git is designed to be portable. Your commit history, branches and tags are the same bytes on any host, so they move without loss. The friction is in everything a host adds around git, the metadata and automation that isn't part of the repo at all.
- Thing
- Commit history, branches, tags
- Moves to a new host?
- Yes. Git is portable; a mirror push carries it all.
- Thing
- Code itself
- Moves to a new host?
- Yes. It's just the repo.
- Thing
- Pull requests + review threads
- Moves to a new host?
- Not automatically. Host-specific; needs an importer or it's lost.
- Thing
- Issues, labels, milestones
- Moves to a new host?
- Not automatically. Host data, exported via API at best.
- Thing
- CI pipelines (e.g. Actions)
- Moves to a new host?
- No. You rewrite them for the new host's runner.
- Thing
- Webhooks, secrets, integrations
- Moves to a new host?
- No. Reconnect and re-enter by hand.
- Thing
- Permissions + team structure
- Moves to a new host?
- No. Re-create from your identity provider.
| Thing | Moves to a new host? |
|---|---|
| Commit history, branches, tags | Yes. Git is portable; a mirror push carries it all. |
| Code itself | Yes. It's just the repo. |
| Pull requests + review threads | Not automatically. Host-specific; needs an importer or it's lost. |
| Issues, labels, milestones | Not automatically. Host data, exported via API at best. |
| CI pipelines (e.g. Actions) | No. You rewrite them for the new host's runner. |
| Webhooks, secrets, integrations | No. Reconnect and re-enter by hand. |
| Permissions + team structure | No. Re-create from your identity provider. |
The repo is portable. The workflow around it is what you actually migrate.
How does a git host migration actually work?
The repository move itself is a few commands and has been stable for years. This is the part that will look the same whatever host you move to, including Origin.
- 1Make a full mirror clone of the old repo: git clone --mirror keeps every branch, tag and ref.
- 2Add the new host as a remote once you have a repo URL there.
- 3Push everything with git push --mirror to the new remote.
- 4Repoint each developer's origin remote, and move CI, secrets and integrations over by hand.
- 5Keep the old host read-only for a while as a fallback before you delete anything.
The mirror push takes minutes. Rebuilding pipelines, reconnecting integrations and re-creating permissions takes the rest of the project. Scope the migration around that, not around the repo copy.
What should stay on GitHub, at least for now?
Some things are tied to GitHub in ways a host swap can't carry. Be honest about these before you plan a full cut-over, especially while Origin is unproven.
- Public or open-source projects, where GitHub is also your distribution and discovery, not just storage.
- Anything wired deeply into the GitHub Actions ecosystem or marketplace apps you can't easily replace.
- Third-party tools that integrate with GitHub and not yet with Origin.
A waitlisted product is not where you bet your only copy of the company's code. Treat Origin as something to trial on a non-critical repo first.
Is there a safer path than a full cut-over?
Yes: mirror to both for a while. Git lets one local repo push to more than one remote, so you can keep GitHub as the source of record and push the same history to Origin to evaluate it on real work. You get to test review and merge on Origin without moving issues, CI or your team's day-to-day off GitHub.
Pick one active but non-critical repo. Mirror it to Origin, run a week of real changes through Origin's review, and keep GitHub authoritative. Decide on what review and merge actually felt like, not on a feature list.
Frequently asked questions
Can I import my GitHub pull requests and issues into Origin?
There's no confirmed importer yet, because Origin is pre-launch. Pull requests and issues are host-specific data, not part of git, so they don't move with a normal repo push. Whether Origin offers an importer at launch is something to verify on cursor.com/origin when it ships.
Will my commit history survive moving to Origin?
Yes. Commit history, branches and tags are part of the git repository itself and move cleanly to any host with a mirror clone and push. The history is the part you don't have to worry about.
Should I move my whole company off GitHub for Origin?
Not while Origin is waitlisted and unproven. A safer path is to mirror one non-critical repo to both hosts, trial Origin's review and merge on real work, and keep GitHub authoritative until you've seen how it holds up.
Sources & last verified
Cursor ships frequently. Facts verified against primary sources on June 26, 2026.