Last updated: June 2026 · Covers migrating from GitHub Copilot (VS Code) to Cursor 0.47+
You have decided to switch from GitHub Copilot to Cursor. This guide covers the actual migration — not whether you should switch (see Cursor vs GitHub Copilot for that decision), but the practical steps to move your settings, extensions, configuration, and team over with minimal disruption.
Most developers complete this migration in under 30 minutes. The steps below cover the full process including the parts most guides skip: migrating Copilot instructions to Cursor rules, team rollout, and what will not transfer.
Because Cursor is a fork of VS Code, it imports most of your existing setup automatically during first launch:
settings.json, keybindings, color theme, font preferences.vscode/ folder configuration (tasks, launch configs, recommended extensions)What does not transfer automatically:
.github/copilot-instructions.md content (needs manual migration — covered below)Download Cursor from cursor.com for your OS (macOS, Windows, Linux). On first launch, Cursor offers to import your VS Code settings directly:
Import VS Code settings? [Yes] [No]
Select Yes. This triggers the automatic import described above. If you skipped this prompt, you can trigger it manually:
Cmd/Ctrl + Shift + P → Cursor: Import VS Code Settings
Verify the import worked by checking that your theme, keybindings, and extension list match your previous VS Code setup.
You have three options, and the right one depends on your situation.
Option A: Remove Copilot entirely. If you are fully switching to Cursor's AI, uninstall the GitHub Copilot extension from within Cursor (Extensions panel → GitHub Copilot → Uninstall). This avoids any conflict between the two AI systems and keeps your setup clean.
Option B: Keep Copilot installed alongside Cursor. Some developers run both — Cursor for its native tab completions and Composer, GitHub Copilot Chat for specific use cases (e.g., if your team standardizes on Copilot Chat for PR reviews via GitHub). This works but can create confusing overlapping suggestions if both are active simultaneously. If you keep it installed, disable Copilot's inline completions specifically (Copilot Status Bar icon → "Disable Completions") to avoid conflicts with Cursor's own completions.
Option C: Cancel your Copilot subscription, keep the extension dormant. If you are not fully committed yet, disable rather than uninstall. This preserves your Copilot settings in case you switch back during an evaluation period.
For most developers switching intentionally rather than trialing, Option A is recommended — one AI system per editor avoids ambiguity about which is generating which suggestion.
This is the step most migration guides skip, and it matters more than people expect. If your team uses .github/copilot-instructions.md to configure Copilot's behavior, that content needs to move to Cursor's rules format — it will not be read automatically.
Check your repository for:
.github/copilot-instructions.md
.github/instructions/*.instructions.md (path-specific instructions, newer format)
AGENTS.md (if using Copilot's agent mode)
Cursor uses .cursor/rules/*.mdc files (the current recommended format — see Cursor Rules guide for full details on why this format is preferred over the legacy .cursorrules).
Example Copilot instructions file:
<!-- .github/copilot-instructions.md -->
This project uses Next.js 14 with the App Router and TypeScript.
Use named exports for all components.
API routes should use Zod for validation.
Prefer functional components with hooks.
Write tests using Vitest.
Converted to Cursor's .mdc format:
---
description: Project stack and conventions
alwaysApply: true
---
Next.js 14, App Router, TypeScript strict.
Named exports for all components — no default exports except pages.
API routes: validate request bodies with Zod before processing.
Functional components with hooks only — no class components.
Testing: Vitest for unit tests.
The content translates almost directly — the main difference is Cursor's YAML frontmatter for controlling when the rule activates (alwaysApply, globs, description). If you had path-specific Copilot instructions (.github/instructions/frontend.instructions.md targeting specific paths), convert each to a separate .mdc file with a matching globs pattern:
---
description: Frontend component conventions
globs: "src/components/**/*.tsx"
alwaysApply: false
---
[content specific to frontend components]
your-project/
└── .cursor/
└── rules/
├── 01-general.mdc # from copilot-instructions.md
├── 02-frontend.mdc # from frontend.instructions.md
└── 03-backend.mdc # from backend.instructions.md
Commit this directory to your repository so the whole team gets the same configuration automatically when they clone the repo and open it in Cursor.
Beyond migrating existing instructions, Cursor supports configuration that Copilot does not have an equivalent for. Worth setting up during migration rather than discovering later:
Model selection. Cursor lets you choose your AI model. Go to Settings → Models and select your preference (Claude Sonnet 4.6 is the default for most tasks; switch to GPT-4o or Gemini if your team has a preference). Copilot did not offer this choice.
Privacy Mode. If your organization has data handling requirements, enable Privacy Mode (Settings → Privacy Mode) before your first real coding session. This prevents your code from being stored or used for training.
Background agents (if on Pro or above). Cursor's background agents can run on cloud VMs and be triggered via Slack or GitHub — a capability with no Copilot equivalent. Not essential for day one, but worth knowing exists as you get further into Cursor's feature set.
For a complete rules setup beyond the migrated content, see the Cursor Rules guide for ready-to-use templates by stack, and the Cursor FAQ for common configuration questions.
Before considering the migration complete, verify these four things:
1. Extensions loaded correctly. Open the Extensions panel and confirm your key extensions (linters, formatters, language-specific tooling) are present and enabled.
2. Rules are loading. Open a chat or Composer session and ask:
What rules are you currently following for this project?
Cursor should list the content from your migrated .mdc files. If it does not, revisit Step 3 — the most common issue is placing files outside .cursor/rules/ or forgetting the YAML frontmatter. If rules load in Chat but not in Agent mode specifically, see Cursor Rules Not Working — this is a known Cursor behavior, not a migration error.
3. Autocomplete matches your project's patterns. Type a new function in an existing file and confirm the tab completion reflects your project's conventions — this confirms the codebase index has built correctly. Large projects can take a few minutes to fully index on first open.
4. Keybindings work as expected. If you customized any Copilot-specific keybindings (accept suggestion, next suggestion, etc.), verify Cursor's equivalent bindings work. Cursor generally uses Tab for accept, matching Copilot's default.
If you are migrating a team rather than just yourself, a phased rollout avoids the most common friction points.
Have one or two developers migrate first using the steps above. Have them specifically validate:
.cursor/rules/ files produce the same quality output as the old Copilot instructions?Based on pilot feedback, finalize the .cursor/rules/ directory and commit it to the repository. This is the point where the whole team benefits from one migration effort rather than each developer converting instructions independently.
For teams on Cursor Business ($40/user/month), set up centralized billing and admin controls before the full team switches. Provide the pilot group's findings as a short internal guide — most teams find a 1-page "what's different from Copilot" doc reduces support questions significantly.
Once the team has migrated and validated Cursor for 2–4 weeks, decide whether to cancel GitHub Copilot licenses entirely or keep a reduced number active for developers who need JetBrains/Vim/Visual Studio (which Cursor does not support — see below).
Be aware of these trade-offs before completing the migration — they do not disqualify Cursor, but they are real:
IDE flexibility. Copilot works in JetBrains, Vim, Neovim, Visual Studio, and Xcode. Cursor only works as its own standalone IDE. If any team members use non-VS-Code editors, they cannot follow this migration — see Cursor vs JetBrains AI for that specific situation.
GitHub-native integrations. Copilot's deep GitHub.com integration (PR summaries, Copilot Workspace, issue-to-PR workflows) has no Cursor equivalent. If your team relies on these specifically, evaluate whether losing them offsets Cursor's IDE-level AI improvements.
Lower price point. Copilot Individual is $10/month; Cursor Pro is $20/month. For budget-conscious teams, this doubling matters. See AI Coding Tools Pricing 2026 for the full cost comparison including team tiers.
Enterprise compliance maturity. Copilot's IP indemnity and audit logging are more established than Cursor's equivalent features. Organizations with strict compliance requirements should evaluate Cursor Enterprise specifically before committing a regulated team.
This is usually an indexing issue, not a quality issue. Cursor needs to build a codebase index before its completions reflect your project's patterns accurately. On large repositories, this can take several minutes on first open. Check indexing status: Settings → Codebase Indexing.
This is a known Cursor behavior in 2026, not a migration mistake: the legacy .cursorrules format does not load in Agent mode, only the .cursor/rules/*.mdc format does. If you migrated to .mdc per Step 3, this should not affect you — but double-check you did not accidentally use the old .cursorrules filename. Full explanation: Cursor Rules Not Working.
Copilot's GitHub-native features (PR description generation, Workspace) do not have a Cursor equivalent. If your team depended on these, you will need an alternative — either keeping a limited number of Copilot licenses for that specific workflow, or adjusting your PR process to not rely on AI-generated summaries from within GitHub itself.
Rare, but occurs with extensions that have hard dependencies on specific VS Code marketplace APIs Cursor has not fully replicated. Check the extension's GitHub issues for "Cursor" mentions, or test the extension in a vanilla VS Code install to isolate whether the issue is Cursor-specific.
.github/copilot-instructions.md or .instructions.md files.cursor/rules/*.mdc format.cursor/rules/ to the repositoryFor an individual developer: 15–30 minutes for the technical migration (install, import settings, convert instructions). For a team, budget a 1-week pilot phase plus 2–4 weeks of parallel evaluation before fully committing, especially if migrating rules and workflows for a larger codebase.
No. .github/copilot-instructions.md is not read by Cursor. You need to manually convert the content into Cursor's .cursor/rules/*.mdc format, as covered in Step 3 above. The conversion is usually a direct content copy with added YAML frontmatter — not a rewrite.
Yes, technically — you can install the Copilot extension inside Cursor. However, running both AI systems simultaneously can create overlapping or conflicting inline suggestions. Most developers who keep both disable Copilot's inline completions specifically and use it only for Copilot Chat or GitHub-specific workflows.
No. It is recommended to run Cursor in parallel with an active Copilot subscription for 2–4 weeks before cancelling, particularly for team migrations. This gives you a fallback if the migration reveals issues, and lets you validate that Cursor's output quality meets your bar before committing.
It does not transfer. Copilot Chat history is stored in GitHub's infrastructure and is not portable to Cursor. If you need to reference past conversations, export or screenshot anything important before switching, though most developers find this is rarely needed in practice.
Yes — Cursor does not affect your CI/CD pipeline at all. It is a local development tool. Any Copilot-specific CI features (like Copilot for Pull Requests running automated reviews) will stop, but standard GitHub Actions, checks, and workflows are unaffected by switching your local editor.
No — this is the core limitation of switching to Cursor. Cursor is only available as a standalone VS Code-based IDE with no JetBrains support. Team members using IntelliJ, PyCharm, WebStorm, or other JetBrains IDEs cannot migrate to Cursor and should continue using GitHub Copilot (or evaluate JetBrains AI Assistant) instead. See Cursor vs JetBrains AI for the full breakdown of this trade-off.
.cursor/rules/*.mdc setup with templates