Migrate from GitHub Copilot to Cursor (2026)

Before you install anything, go to github.com/settings/billing/copilot/usage and pull the last 30 days of premium-request data. The Copilot usage dashboard breaks down inline completions (which were unlimited and won't tell you anything useful) and premium model requests (which translate directly to Cursor's fast-pool consumption).

**The decision rule:** Cursor Pro's fast pool is ~500 premium requests/month. Cursor Business is the same per-seat pool plus admin features. If your last-30-days premium-request count is under 400, you fit Cursor Pro with margin. 400-800: you're borderline and may hit slow-pool latency in week 4. Over 800: you need a strategy — either accept slow-pool throttling, run the $30 stack with Copilot Pro as overflow, or upgrade to Cursor Business and budget for occasional throttling on heavy weeks.

**What to capture from the dashboard:** total premium requests last 30 days, breakdown by model (Claude Opus, GPT-5, GPT-5-pro), daily distribution (steady vs spiky). Spiky users — most requests bursting on 2-3 days/week during refactor sprints — get hit harder by slow-pool throttling because their burst overshoots the daily-rate-fair allocation.

**Don't skip this even if you're moving for non-cost reasons.** Right-sizing is the difference between 'Cursor is fantastic' (under quota, fast pool, ~3-second response times) and 'Cursor is mid' (slow pool, 30-90 second response times, model downgrade on heavy days). Plan size determines actual user experience.

**Quick mental model:** if you were on Copilot Pro+ ($39/mo) at full credit utilization, you have ~580-1,750 premium requests/month. The high end of that range puts you over Cursor Pro's fast pool — either step up to Cursor Business or plan to feel the throttle. If you were on Copilot Pro ($10) and only sometimes hit overage, Cursor Pro is your match.

Want a sibling-tool sanity check on the cost side? See the Cursor vs Copilot price calculator for plan-by-plan dollar math.

Download from cursor.com — pick the right binary for your OS (Cursor ships native Apple Silicon, Intel macOS, Linux deb/rpm/AppImage, and Windows installers). Install and launch — first-run takes ~30 seconds.

**Sign-in choice:** email (creates a Cursor account directly) or GitHub OAuth (links to your existing GitHub identity). If you're on a team, prefer the GitHub OAuth — it makes the eventual upgrade to Cursor Business smoother (your seat invitations will link to the same identity). If you're solo, either works.

**The 'select a plan' prompt:** Cursor presents Pro ($20) and Business ($40) at signup with a 14-day Pro trial available. Take the trial. The audit you did in Phase 1 determined whether Pro is the right long-term plan; the trial gives you a no-commitment two weeks to verify.

**Initial config prompt:** Cursor will ask about telemetry, theme, and AI feature defaults. The defaults are reasonable. Theme will get overwritten in Phase 3 when you import VS Code settings. The 'AI features default' toggle controls whether Composer and tab-completion are on by default — leave them on.

**Optional but recommended: install the Cursor CLI.** Run `cmd-shift-p` → 'Shell Command: Install cursor command in PATH'. This lets you do `cursor .` from terminal to open a project, same as `code .` for VS Code. Most VS Code-to-Cursor migrants forget this and miss the terminal shortcut for weeks.

**Pre-flight sanity check:** open a small project (your own dotfiles, a sample repo) and verify autocomplete fires when you type. If it doesn't, check that the model picker (bottom-right of the editor) shows a model selected — sometimes the first-run flow leaves it empty. Pick `auto` for the default routing or `claude-sonnet-4-6` for predictable behavior.

Cursor has a first-class 'Import from VS Code' command. Open command palette (`cmd+shift+p`), run `Cursor Settings: Import from VS Code`. The import dialog asks which categories to bring over: Settings, Extensions, Keybindings, Snippets. Default: all. Take the default.

**What actually gets imported:** your settings.json (formatter rules, editor behavior, theme), your extensions list (Cursor will install each one — see conflict list below), your keybindings.json, your snippets directory. The import is one-way and one-time; future VS Code settings changes won't auto-sync. If you want ongoing sync, install the Settings Sync extension in both editors with the same GitHub account.

**Extension conflicts to expect.** Most VS Code extensions work in Cursor unchanged (it's the same extension API). The known conflicts:

- **GitHub Copilot extension itself** — Cursor disables it on install because Copilot's keybindings (Tab to accept) collide with Cursor's. Decision: leave it disabled (you're migrating away anyway), or if you're running the $30 stack, set Cursor's autocomplete to a different keybinding and re-enable Copilot. Most stack users actually disable Copilot in Cursor and only use Copilot in their secondary editor (VS Code or JetBrains).

- **Tabnine, Codeium, and other AI completion extensions** — same Tab-keybinding collision. Disable.

- **VSCode IntelliCode** — works but is redundant with Cursor's native AI. No harm leaving it on; no benefit either.

- **Settings Sync** — works, but the sync direction can be confusing. If both editors are signed into the same Settings Sync account, they'll fight over preferences. Pick one as the source of truth.

**Theme and font:** these import cleanly. If your theme uses VS Code-specific scopes that Cursor doesn't expose, you may see minor color drift on Composer/chat UI elements. Cosmetic only.

**Snippets and keybindings:** these import 1:1 with one caveat — Cursor adds its own keybindings for Composer (`cmd+I` for inline edit, `cmd+L` for chat, `cmd+shift+I` for Composer). If your custom keybindings collide with these, Cursor's defaults win on first run but you can re-bind from `cmd+k cmd+s` (the keybindings editor).

Cursor's AI surface is Composer + Agent + tab-completion. Each is configured independently. The defaults are decent; tuning takes ~20 minutes and pays off immediately.

**Composer setup** (`cmd+I` for inline, `cmd+shift+I` for full pane). The model picker sits at the bottom of the Composer pane. Default to `auto` (Cursor routes based on task complexity) or set a specific model — `claude-sonnet-4-6` for general work, `claude-opus-4-7` for hard refactors. The model choice ripples through your fast-pool quota — Opus consumes the same fast-pool slot as Sonnet but takes longer, so heavy Opus users hit the slow pool sooner.

**Agent mode setup** (toggle at top of Composer pane). Agent mode lets Cursor make multi-file edits, run terminal commands, and iterate autonomously. The default safety settings prompt for confirmation on shell commands; for trusted contexts you can disable the prompt in settings. Don't disable it on a shared machine.

**MCP server install.** Open `cmd+shift+p` → `MCP: Install Server`. Cursor ships an MCP marketplace inside the IDE. The high-leverage installs:

- **Filesystem MCP** — exposes file ops to the agent beyond the open workspace. Useful for cross-project work.

- **GitHub MCP** — lets Cursor read/write issues, PRs, comments. The killer feature is 'compose this PR description from the diff.'

- **Playwright MCP** — lets Cursor drive a browser for E2E test creation and debugging.

- **Web Fetch MCP** — lets Cursor read documentation URLs you reference (handy when working with unfamiliar libraries).

MCP install is per-project; configuration lives in `.cursor/mcp.json`. Commit it to share with your team.

**Project Rules setup** — the most important Phase-4 step. Cursor moved from the legacy `.cursorrules` (single file at repo root) to per-directory `.cursor/rules/*.mdc` files in 2025. Each `.mdc` is YAML frontmatter + markdown body, telling Cursor how to behave when working in that directory. A starter rule for a Next.js app might look like:

``` --- name: nextjs-app-router globs: - app/**/*.tsx - app/**/*.ts alwaysApply: true --- This is a Next.js 16 App Router project. Default to Server Components; mark Client Components with 'use client' explicitly. Use the new Cache Components patterns (use cache, cacheLife, cacheTag). Avoid pages/ — this codebase is fully on App Router. ```

For a comprehensive rules-setup guide, see our Cursor Rules for Next.js 2026 tutorial.

The strategic decision. By Phase 5 you've been on Cursor for at least an hour and probably a few days. Now: cancel Copilot, or keep it as part of the $30/mo Cursor Pro + Copilot Pro stack?

**Cancel if:** you only ever work in Cursor, you don't use JetBrains/Visual Studio/Neovim/other editors for any work, you're trying to minimize spend, your audit in Phase 1 showed you fit comfortably under Cursor Pro's fast pool (no need for overflow capacity).

**Keep Copilot ($10/mo) if:** you regularly work in a non-Cursor editor (JetBrains for Kotlin/Java backends, Visual Studio for .NET, Neovim for SSH sessions to servers, etc.), you're a heavy user who might hit Cursor's slow pool in week 4 and wants overflow capacity, you want inline AI in the GitHub web UI (Copilot in PRs/issues), you want PR-summary generation that Copilot does well.

**The stack is genuinely cheaper than Copilot Pro+.** Cursor Pro ($20) + Copilot Pro ($10) = $30 total. Copilot Pro+ alone = $39. For another $9/mo you get Cursor's IDE in addition to Copilot's. The TCO math (see TCO calculator) generally favors the stack for any developer who uses 2+ editors.

**Cancellation mechanics if you go that route:** github.com/settings/billing → Active subscriptions → GitHub Copilot → Cancel. Cancellation is end-of-billing-cycle; you keep access through the paid period. Settings, history, and any saved chat threads in Copilot are deleted ~30 days after cancellation per GitHub's data policy.

**The 'pilot for 2 weeks before canceling' rule:** don't cancel Copilot in week 1. Run both for 14 days, measure your actual Cursor experience under load, then make the cancel call. The 14-day Copilot cost ($5) is trivial insurance against discovering on day 18 that you actually preferred Copilot.

**Andy's 2026 trial-first guidance:** don't commit to either tool's annual plan before you've put 30 days of real work through it. Both vendors push annual discounts; both annual discounts evaporate against the cost of being locked into the wrong tool. Monthly billing for 30+ days, then commit.

Cursor's defaults are reasonable but not optimal. These seven changes pay off immediately.

**1. Set default model to `auto` or `claude-sonnet-4-6`** (Settings → Models). `auto` is good if you trust Cursor's routing; explicit is good if you want predictable cost/quality tradeoff. Avoid setting it to `claude-opus-4-7` as default — it eats your fast-pool quota faster.

**2. Enable Composer Agent mode** (Composer pane → Agent toggle). The default starts in non-agent mode; you have to flip the toggle every session if you don't enable it globally.

**3. Set tab-completion model to fast tier** (Settings → Tab Completion). Cursor offers a fast tier for tab completions (its own optimized model, not the premium models). This is what's already there by default, but verify — if it's set to a premium model, your tab completions are silently burning fast-pool quota.

**4. Add `.cursor/` to your global gitignore template** (`~/.gitignore_global`). Some `.cursor/` contents (chat history, local cache) shouldn't be committed. Project-level Rules (`.cursor/rules/`) SHOULD be committed — handle this with a project-level `.gitignore` that ignores `.cursor/` but un-ignores `.cursor/rules/`.

**5. Configure auto-save behavior** (Settings → Files: Auto Save → onFocusChange). Cursor's Composer modifies files; without auto-save you'll have unsaved-file conflicts. onFocusChange is the sweet spot.

**6. Bind a 'kill the current AI request' shortcut** (Settings → Keybindings → search 'cancel'). When Composer starts going off on a tangent, you want a one-key way to stop it before it burns fast-pool quota. Default is `escape` but it's not always bound globally.

**7. Enable 'Cursor Settings → Privacy → Privacy Mode'** if you work in regulated codebases. Privacy Mode disables training-data usage and indexing-on-Cursor-servers; your code stays local-and-API-only. Worth the latency tradeoff for HIPAA/SOC 2 code.

Cursor has three AI surfaces. Knowing which to invoke for which task halves your time-to-result.

**Inline Edit (`cmd+K`)** — for changes inside a single function or block. Select text, press `cmd+K`, describe the edit. Cursor produces a diff in-place; accept or reject. Fastest for small edits. Equivalent to Copilot Chat's inline mode but with better diff UX.

**Chat (`cmd+L`)** — for questions and explanations. Open chat pane, ask a question, get an answer. Chat can `@file` reference files and `@docs` reference documentation. No code changes happen; this is read-only AI. Equivalent to Copilot Chat's panel mode.

**Composer (`cmd+I`)** — for multi-file changes, refactors, and feature builds. Open Composer, describe the change, optionally toggle Agent mode for autonomous multi-step work. Composer can modify many files in one operation and create new files. Equivalent to Copilot's Agent mode but with substantially more fluid UX (in Cursor's design opinion).

**Rough rule of thumb:** Inline for <20 lines and 1 function. Chat for 'help me understand this'. Composer for everything else — especially anything spanning multiple files. Most Cursor power users live in Composer 70% of the time, Chat 20%, Inline 10%.

**Conversion from Copilot habits:** Copilot users tend to over-rely on chat for tasks that should be Composer. The conscious shift to 'is this a multi-file change → Composer' is the single biggest week-1 productivity unlock for migrants.

Most VS Code-to-Cursor migrants report 4-12 hours of degraded productivity in week 1. The specific friction points are predictable.

**Bump 1: Tab acceptance differences.** Copilot accepts the full suggestion on Tab. Cursor accepts the next-word on partial-tab in some configurations. The mental model differs and your fingers will fight you for ~3 days. Mitigation: set Cursor's tab behavior in settings to 'accept full suggestion' to match Copilot's behavior exactly until you get used to the new UX.

**Bump 2: `cmd+I` vs `cmd+L` confusion.** In Copilot, chat is `ctrl+I` or via the chat panel — slightly different keybindings. In Cursor, you have three AI invocations (Inline, Chat, Composer) on three different keybindings. Building the mental map of 'when to press which' takes a week.

**Bump 3: model picker friction.** Copilot abstracts the model; Cursor surfaces it. New Cursor users get distracted picking models when they should just be coding. Mitigation: pick `auto` or `claude-sonnet-4-6` and stop thinking about it for the first 2 weeks. Optimize model choice later when you've established a baseline.

**Bump 4: Composer's diff-review UX.** Composer shows a diff preview before accepting. The accept/reject controls live in different places than Copilot's chat-applies-edits flow. First few days you'll lose seconds hunting for the accept button. By week 2 it's faster than Copilot's flow because the diff is more reviewable.

**Bump 5: extension UI drift.** Some VS Code extensions render slightly differently in Cursor — sidebar panel widths, hover styles, theme colors. Cosmetic, not functional, but unsettling. Most stabilize after Cursor's next update cycle.

**Push-through tip:** schedule your migration during a low-stakes week. Don't migrate on the Monday of a sprint with a Friday deadline. Pick a week with some discretionary refactor or doc work where the productivity dip costs you the least.

Pilot phases should always include a rollback plan. If Cursor doesn't work for you, getting back to Copilot is a 30-minute job — but only if you didn't burn your bridges.

**The 'don't burn bridges' rules for the trial period:** (1) do not cancel Copilot until day 30+ at the earliest; (2) keep your VS Code install intact (do not uninstall just because you have Cursor); (3) don't delete your VS Code settings.json or extensions list; (4) don't commit `.cursorrules` or `.cursor/rules/` to the repo until you've decided to stay (they don't hurt VS Code but they signal commitment to the team).

**Rollback procedure if you decide Cursor isn't for you:** open VS Code, verify it still launches with your settings (it should, since the import was one-way to Cursor — VS Code's were untouched), re-enable Copilot in VS Code (Settings → Extensions → GitHub Copilot → Enable), verify autocomplete works, uninstall Cursor (drag to trash on Mac, uninstall via Settings on Windows), cancel Cursor (cursor.com → Settings → Billing → Cancel — same day cancellation, no proration).

**Common reasons developers roll back:** (1) the throttle bites worse than expected — fast-pool exhausts in week 2 instead of week 4; (2) team uses JetBrains for backend work and the dual-IDE friction wasn't worth it; (3) one specific extension doesn't work in Cursor and the workflow depends on it; (4) Composer UX feels slower than Copilot Chat for their specific workflow (rare but real for some).

**Reasons NOT to roll back:** (1) 'it's different' — give it 2 weeks; muscle memory adjusts; (2) 'tab completion is slightly weird' — it's settings-tunable; see week-1 bump 1; (3) 'I miss Copilot's chat panel' — Cursor's `cmd+L` is the equivalent; the UX is similar.

**The 30-day decision moment:** at day 30, look at your usage stats and your feeling. If both say Cursor is working, commit (annual plan saves 20%). If either says no, roll back or extend the trial by going month-to-month for another 30.

Solo migration is one thing; team migration multiplies the work by team size unless you share configuration. Cursor supports several mechanisms.

**Committed `.cursor/rules/`:** the per-directory rules files are the highest-leverage shared config. Commit them to the repo. New team members get the team's prompt conventions automatically.

**Committed `.cursor/mcp.json`:** MCP server config (which servers, with what configuration) commits to repo. New team members run `cursor` in the project and the MCP servers are pre-configured.

**Team-level model preferences:** Cursor Business accounts can set team defaults for model choice and feature toggles. Not available on Cursor Pro individual accounts.

**The 'recommended extensions' file** (`.vscode/extensions.json`): if you commit this, Cursor will prompt new team members to install the recommended extensions on first project open. Same as VS Code.

**Internal Notion/Confluence doc:** what nobody wants to write but every team eventually does — an internal page on 'how we use Cursor here' with screenshots, common prompts, the 5-10 patterns that work for your codebase. The doc that takes 2 hours to write saves 50 hours of repeated explanation over 6 months.

**Cursor Rules vs CLAUDE.md vs AGENTS.md:** if you're also using Claude Code or other agent tools, you'll end up with multiple config files (one per tool). Most teams converge on one canonical 'team conventions' doc (often `CONVENTIONS.md` or `AGENTS.md`) that all tools reference. Cursor Rules then becomes a thin wrapper that says 'always read AGENTS.md before starting.'