How to Migrate From Cody to Cursor
The developers who move from Cody to Cursor usually share a profile: they started with Cody because it was Sourcegraph's product and Sourcegraph was already in their stack for code search. Cody's context engine, built on Sourcegraph's code graph, is genuinely good for answering questions about large repositories. But Cody's editing capabilities, the actual "write code and apply it" side, have lagged behind what Cursor offers.
The switch becomes attractive when the pattern becomes familiar: you use Cody to understand code (good), then you manually write the change yourself (tedious). Cursor can do both. You lose some of Sourcegraph's deep code intelligence in the trade, and that's worth understanding before committing.
What's actually different
Cody and Cursor take different philosophical approaches to context. Cody is built on Sourcegraph's code graph, which means it understands symbol relationships, call hierarchies, and cross-repo dependencies deeply. Cursor uses semantic embedding on your local codebase, which is good but not the same thing.
| Feature | Sourcegraph Cody | Cursor |
|---|---|---|
| Inline autocomplete | Yes | Yes (Cursor Tab) |
| Chat | Cody Chat (strong on context) | Ask mode + Composer |
| Multi-file agentic edits | Limited | Composer (strong) |
| Code graph context | Yes (Sourcegraph) | No (embedding only) |
| Cross-repo context | Yes (with Sourcegraph) | No |
| Custom model choice | Yes (Claude, GPT-4o, Gemini) | Yes (Claude, GPT-4o) |
| IDE support | VS Code, JetBrains, Neovim | VS Code only (fork) |
| Self-hosted option | Yes (Sourcegraph instance) | No |
| Pricing | Free / Pro $9 / Enterprise | Free / Pro $20 |
The honest framing: Cody is better at knowing your codebase if you already run Sourcegraph. Cursor is better at modifying it. If you're moving because you want an agent that writes and applies changes, Cursor is the right direction. If you're moving because the chat wasn't smart enough about your specific repo, Cursor might not actually solve that problem.
Mapping your existing workflow
Cody Chat. Cody's chat maps to Cursor's Ask mode. Both let you select code, ask questions, get explanations and edits. The interface is similar enough that the adjustment is quick. The difference: Cody's answers benefited from Sourcegraph's code graph. Cursor's answers benefit from @Codebase embedding. For most questions, Cursor's answers are comparable. For deep cross-repo questions involving call chains across 10 repositories, Cody wins.
@-mentions in Cody. Cody lets you @-mention files, symbols, and repositories in chat. Cursor uses @ to reference files, folders, and @Codebase. The pattern is similar; the available targets differ (no cross-repo in Cursor).
Cody's "fixup" command. Cody's inline fixup (select code, ask Cody to change it) maps to Cursor's inline edit (Cmd+K / Ctrl+K). Same concept, similar UX.
Agentic tasks in Cody. Cody's agent capabilities are limited. Multi-file refactors with Cody often require manual oversight at each step. Cursor's Composer handles these end-to-end with a diff review. This is the biggest practical improvement.
Custom model selection. Both tools let you choose your model. If you were using Claude 3.5 Sonnet in Cody, you can use Claude 3.7 Sonnet in Cursor, which is a meaningful upgrade.
JetBrains users. Cody has a JetBrains plugin. Cursor is VS Code only. If your team uses JetBrains, this migration isn't available to everyone.
The actual migration steps
1. Install Cursor. Download from cursor.com. On first launch it imports your VS Code profile including extensions. Your Cody extension will also carry over, which means you can run both in parallel during the evaluation period (Cody via the plugin, Cursor via the standalone IDE).
2. Configure your model. Cursor Pro ($20/month) includes Claude 3.7 Sonnet and GPT-4o. In Settings, set your preferred model. If you were using a custom Anthropic key in Cody, you can also use your own API key in Cursor.
3. Index your codebase. Open your project and let Cursor index it. The @Codebase context is useful for single-repo questions but doesn't replicate Sourcegraph's cross-repo graph. Manage expectations here.
4. Create a .cursorrules file. Any conventions you had in Cody's "Custom Instructions" feature (available on Pro) should go into .cursorrules at the project root. This is how you preserve team coding standards.
5. Preserve Sourcegraph access separately. If your team uses Sourcegraph for code search, code intelligence, and batch changes, keep it. Cursor doesn't replace Sourcegraph as a code intelligence platform; it replaces Cody as an AI assistant. These are different things.
6. Practice Composer on real tasks. Cmd+I opens Composer. Pick a task that involves three or more files and try it. This is the capability you were missing in Cody, and getting comfortable with the diff review workflow takes a few sessions.
7. Evaluate JetBrains impact. If any team members are on JetBrains, they either keep Cody (which continues to work independently) or they switch editors. Plan for this explicitly.
First-day checklist:
- Cursor installed, codebase indexed
.cursorruleswith team conventions- Sourcegraph kept in place for code search
- One Composer multi-file task completed
Gotchas you'll hit
Cross-repo context disappears. If you work in a multi-repo architecture and Cody's Sourcegraph integration was giving you context across repos, Cursor doesn't have this. You'll answer cross-repo questions by manually pulling in files with @filename or looking them up in Sourcegraph separately.
@Codebase has limits. Cursor's semantic index is strong for typical codebases but gets fuzzy on very large repos (500k+ lines). Cody backed by Sourcegraph handles scale better.
Cursor is more expensive. Cody Pro is $9/month; Cursor Pro is $20/month. If you're evaluating for a large team, the cost difference is real.
No Sourcegraph batch changes from Cursor. Cody integrated with Sourcegraph's batch changes feature for large-scale refactors across many repos. Cursor has nothing equivalent at that scale.
Learning Composer takes effort. Cursor's Composer is powerful but requires learning how to prompt it well: scoping the task, referencing the right files, reviewing diffs carefully. The first week is slower than expected.
When NOT to switch
Stay with Sourcegraph Cody if:
- You have a Sourcegraph instance and rely on cross-repo code intelligence. This is Cody's biggest unique capability.
- Your team uses JetBrains IDEs and switching editors is out of scope.
- You need a self-hosted AI assistant option. Cody supports self-hosted Sourcegraph; Cursor is cloud-only.
- Cost is the primary driver and Cody Pro's $9/month already fits. The $20/month Cursor Pro is harder to justify if you don't use Composer heavily.
- You're primarily doing code review and understanding rather than active development. Cody's read-heavy context model shines there.
Cursor is the right move when you spend significant time making multi-file changes, writing new features, or refactoring code that spans several modules. The ability to describe a change and review a complete diff before applying is qualitatively different from Cody's approach.
The migration is clean if your work is mostly within a single repository and you want better editing capabilities. It's more complicated if Sourcegraph's cross-repo intelligence is load-bearing for your workflow. In that case, the right answer is usually Cursor for development alongside Sourcegraph for search, keeping both rather than treating this as a full replacement.