Migrating from GitHub to Cursor Origin

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.

A planning guide has one advantage over a runbook, which is that you can write it while the vendor is still building.

The parts of a host move that cost real time are set by your own setup rather than by the destination, mostly how many things point at the old host and who is allowed to change them. None of that shifts when Origin's docs eventually appear.

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.

The CI row looks softer than it is. Workflow files are text inside the repo, so they travel with everything else, and it is tempting to read that as most of the way there. What stays behind is the vocabulary that makes them run: the events the host fires and the secret store the steps read from. Rewrite is the honest word for that work, and the pipeline inventory is the place to start it.

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.

1. 1Make a full mirror clone of the old repo: git clone --mirror keeps every branch, tag and ref.
2. 2Add the new host as a remote once you have a repo URL there.
3. 3Push everything with git push --mirror to the new remote.
4. 4Repoint each developer's origin remote, and move CI, secrets and integrations over by hand.
5. 5Keep the old host read-only for a while as a fallback before you delete anything.

Steps four and five carry all the risk. Repointing developers is what turns a copy into a migration, so it should wait until something on the new host can run your checks, or you get a day where everyone can push and nobody can merge. Making the old host read-only is the mistake available in both directions. Too early and you cannot back out onto it; too late and pushes keep landing on a repo nobody is watching any more.

The failure to plan for is split brain. Someone's remote still points at GitHub, they push a week of work there, and two branches called main now hold real commits the other does not have. Reconciling that is manual by nature, because both sides are legitimate.

So if a push or a check goes wrong mid-cutover, run git remote -v on the machine that produced it before you look at anything else. The answer is usually there, and the alternative is an hour of debugging a pipeline that was reading the correct repo all along.

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.

Team size decides which of these actually binds you. A handful of people on two private repos can move in an afternoon and skip every hybrid phase in this guide, because the list of things pointing at the old host is short enough to hold in your head. A few hundred engineers have deploy keys, bots, status checks and dashboards wired up by people who have since left, and that list is the migration. Almost nobody has it written down, which is the argument for compiling it now instead of during a cutover.

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.

I would normally tell a team to sequence a host move around the importer: run it, see what arrived, then decide what to rebuild by hand. That advice has nothing to run here, because Origin publishes no import tooling. So the plan has to start from the assumption that the review record stays where it was made, which turns the question into which record you can afford to leave behind.

A trial also needs a stop condition, and that is the part I see skipped most often. With no date and no written question, a mirror quietly becomes production. The repo is on Origin, people got used to it, and nobody ever decided anything. Pick the date before you start, and pick the single thing you are measuring. For most teams the useful number is how long a change sits between approval and landing, because that is the gap a new host either closes or does not.