Switching repo hosts costs whatever your CI pipelines, branch protections, issue history, and identity integrations cost to rebuild, and a git remote set-url pays almost none of it. Editor vendors are already shipping agents that live inside the incumbent host’s review flow, and the next move in that direction is the obvious one: an editor vendor becoming the host itself. For any team weighing that kind of move, the honest answer is that GitHub’s side of the bill is well documented and a challenger’s side is worth exactly what the challenger has shipped and put in writing.
What is actually on the record?
Start with what is checkable, because the checkable part already decides half the argument. Cursor’s own homepage describes its agent as one that “runs in your terminal, collaborates in Slack, and reviews PRs in GitHub.” GitHub, not a Cursor-hosted platform, is the pull-request surface in Cursor’s own current positioning. Until that changes, Cursor’s shipping product treats GitHub as the system of record for review, and a move into hosting would be a change of position, not a continuation of one.
This is not a pedantic caveat. It is the article. A platform’s day-one changelog is the weakest evidence a buyer ever gets: it describes intent, not behavior under load, and it says nothing about the migration tooling, audit logging, or compliance attestations that determine whether an enterprise can actually move.
So the challenger column of any honest comparison reads: unverified, undocumented, unpriced. That will change, probably within weeks. What will not change is the structure of the decision, because the structure is set by what GitHub actually is, and that part is on the record.
What does GitHub put on the bill?
GitHub is an eighteen-year-old integration surface, not a git server, and its own reference material says so. Started in 2008 as a SaaS product built on Linus Torvalds’ git, it was acquired by Microsoft for $7.5 billion2 in 2018, according to TechTarget’s GitHub reference. The same reference describes the layer that matters for a migration decision: a hosting service and web interface for Git repositories, plus management tools for collaboration built around forks, pull requests, and merges.
That list is the actual product. A git host holds objects and refs; everything else GitHub sells is the accreted layer of tooling that organizations have wired into their delivery process since 2008. Consider what the documented surface includes:
- Review and collaboration surface. GitHub’s own homepage bills the platform as keeping “your team’s conversation and context next to your code,” from planning and discussion to code review. The PR threads and the review flow are host-side state; git holds none of it.
- Automation surface. The same page sells “AI and automation tools” spanning “your first line of code to final deployment.” Whether a team runs Actions or an external CI against GitHub webhooks and status APIs, the pipelines are configured against GitHub’s event model, not against git.
- Enterprise surface. GitHub scales “from startups to enterprises,” “with teams of any size in any industry,” with a customer roster running from American Airlines to Spotify. Enterprises do not adopt a code host for its git implementation; they adopt the surrounding control plane, and any org with data-residency or air-gap requirements will ask a challenger for an on-prem or single-tenant story before feature comparison begins.
None of this moves when you change a remote URL. Each item is a system that was configured, often by people who have since left, against GitHub-specific APIs and assumptions. The TechTarget reference is a definitional explainer, not a migration guide, which makes it useful in a specific way: it enumerates what GitHub is without trying to sell the enumeration.
GitHub is also not standing still on the agent side. Its own homepage demonstrates Copilot chat switching from Ask mode to Agent mode via a dropdown, after which it analyzes a codebase, explains required edits across three files, and generates them. GitHub’s blog bills its flagship Universe event, scheduled for October 28-29 in San Francisco and online, as “uniting people, agents, and the world’s code.” Whatever a challenger ships, GitHub’s counter is already partially deployed: agent-mode code generation inside the incumbent host.
Where does Cursor’s agent live today?
Cursor’s verified product surface is an agent that operates inside other vendors’ systems of record, and the company’s own site is the source for that. The agent “runs in your terminal, collaborates in Slack, and reviews PRs in GitHub,” per cursor.com. Terminal, Slack, GitHub: three surfaces Cursor does not own, with the review step, the one closest to merge authority, explicitly delegated to GitHub.
The adoption claims on the same page are worth reading the way you would read any vendor’s testimonial page. NVIDIA’s Jensen Huang is quoted saying that every one of NVIDIA’s roughly 40,000 engineers1 is assisted by Cursor and that “our productivity has gone up incredibly.” Cursor also claims to be “trusted by over half of the Fortune 500”1. Both figures are vendor-curated, neither is independently audited, and both should be weighted accordingly. Andrej Karpathy’s framing on the same page is more informative than either number: he describes Cursor as an autonomy slider, from “Cmd+K for targeted edits” up to “the full autonomy agentic version.” That is a product philosophy statement, and it matches how teams actually deploy these tools, dialing autonomy up and down per task rather than handing over the repository.
The picture that emerges: Cursor is a generation and interaction layer with real traction, sitting on top of a hosting and review layer it does not control. Moving into hosting would vertically integrate that stack. Vertical integration is a coherent strategy, but the buyer’s question is never whether the strategy is coherent for the vendor. It is whether the integrated stack is worth the exit cost when you eventually want to leave one side of it.
What doesn’t a git remote carry?
A git remote carries commits, branches, tags, and nothing else, so everything that makes a repository operationally useful has to be rebuilt or replayed at the destination. This is the part of the decision that survives regardless of who the challenger turns out to be, because it applies to every host-to-host move: GitHub to GitLab, GitHub to a self-hosted forge, GitHub to anything.
The inventory that does not transfer:
CI configuration. Pipelines are defined against the host’s event model: push webhooks, pull-request status checks, required-check gating, secrets stores, runner pools, artifact retention. A team with fifty repositories and a decade of accumulated workflow files is not looking at a remote change; it is looking at a CI re-platforming. This is the incumbent’s home turf. A new host needs an equivalent story, documented, before a single repository moves.
Branch protections and merge policy. Required reviews, status-check gates, signed-commit requirements, and admin-override rules live in host configuration, not in git. Losing them in transit means your merge policy silently reverts to “whoever has push access,” which is the kind of thing you discover during an incident review.
Issue history and code-review archaeology. The discussion threads on merged PRs are the institutional memory of why the code looks the way it does. Git preserves what changed; the host preserves why. A migration that moves code and abandons review history trades a searchable record for an oral tradition.
Identity plumbing. SSO and SCIM wiring, team-to-repo permission mappings, and audit-log integrations are the least visible and most compliance-relevant layer. Identity providers plug into whatever integration surface the host exposes, and none of that wiring travels with the refs. Any org under SOC 2 or equivalent obligations has auditors who will ask about the new host’s access logs before engineering asks about its PR flow.
What changes when one vendor writes and hosts the code?
The generation layer and the review layer collapse into a single trust boundary, and the cost of leaving either one doubles. Today, a team using Cursor with GitHub has a structurally useful separation: the tool that proposes code and the platform that gates its merge are different vendors with different incentives. GitHub’s review surface, branch protections, and audit trail sit between Cursor’s output and production. If the agent generates something wrong, the review infrastructure that catches it does not report to the same company that sold the agent.
Fold hosting into the editor vendor and that separation becomes a policy choice instead of an architectural fact. The same company now optimizes the model that writes the code, the review flow that approves it, and the metrics that report both. Maybe the integration is excellent. The incentive problem exists regardless of execution quality: a vendor that earns revenue from generation volume has no structural reason to make its own review layer skeptical of that volume.
The second effect is on exit costs, and it is the one with a longer shadow. Editor switching costs are currently low and falling. If your editor and your host are the same vendor, leaving the editor later means touching the host relationship, and leaving the host means the full inventory from the previous section: CI, protections, history, identity. The cheap-to-leave layer gets welded to the expensive-to-leave layer. GitHub understands this dynamic from the inside; it is the incumbent beneficiary of exactly these switching costs, and its Copilot Agent mode is a bid to keep the generation layer attached to the host you already cannot cheaply leave. The Ask-to-Agent dropdown on github.com is GitHub making the same integration play from the opposite direction.
Neither direction is sinister. Both are the normal economics of platform adjacency. The buyer’s error is evaluating the editor side of the bundle (demo quality, model quality, latency) and ignoring that the host side is where the switching costs live.
What should you inventory before switching hosts?
The practical verdict: the correct posture toward any new repo host, whoever ships it, is to price the plumbing before the first repository moves and to treat launch coverage as intent rather than capability. Concretely:
- Require documentation before evaluation. On-prem or single-tenant deployment, SSO/SCIM support, CI integration or an equivalent native pipeline system, a CLI surface, and import tooling for issues and PR history. If a capability is not documented, treat it as absent. The incumbent’s collaboration, automation, and enterprise surface is documented on github.com; a challenger with none of it in writing has not shipped it.
- Inventory what your current host actually carries. Count Actions workflows or external CI integrations, branch protection rule sets, and identity-provider integrations before looking at any alternative. The number you produce is the real migration budget.
- Discount the agent differentiator. Both vendors ship agent-mode generation: Cursor’s autonomy-slider agent on one side, Copilot’s Ask-to-Agent modes on the other. “An editor with an agent” stopped being a differentiator; the question is which trust boundary you want the agent inside.
- Weight vendor testimonials at face value. The NVIDIA 40,000-engineer1 quote and the Fortune 5001 claim on cursor.com are marketing assets, not audited adoption data. Useful as a signal that enterprise procurement is happening; useless as a reliability measure.
One limitation bears stating plainly: a challenger host’s column is empty until its documentation exists, and none of the analysis above depends on any particular challenger’s launch coverage. When a new host publishes real documentation, the checklist above is how to read it. Until then, the durable answer to “what does switching repo hosts cost” is the same as it has always been: everything except the git data, plus whatever trust-boundary separation you gave up to get the bundle.
Frequently Asked Questions
How does GitHub Enterprise Server handle branch protection migration compared to a git remote?
GitHub Enterprise Server uses a dedicated migration API that maps existing protection rules to the new instance, whereas a git remote only transfers refs. Teams must also reconfigure SAML SSO and SCIM provisioning separately, as identity mappings do not persist across host changes.
What is the actual cost of migrating CI pipelines when switching hosts?
Migrating CI pipelines requires rewriting workflow files to match the new host’s event model, such as GitHub Actions versus GitLab CI. This often involves reconfiguring secrets stores and runner pools, which can take weeks for large fleets and is the primary driver of migration budgets.
Does Cursor’s agent support self-hosted GitHub instances?
Cursor’s agent operates within the IDE and connects to GitHub via API, supporting both SaaS and self-hosted Enterprise Server instances. However, it does not replace the host’s native review surface, meaning branch protections and audit logs remain managed by the GitHub instance regardless of the editor used.
What happens to PR discussion threads during a host migration?
PR discussion threads are stored in the host’s database, not in git objects, so they are lost during a standard remote switch. Teams must use third-party migration tools or manual export scripts to preserve review history, which is often incomplete and lacks the original formatting.
