DogearAI
BlogDocsPricingSign inGet started

How to switch AI coding tools without losing months of context

Claude Code, Cursor, Codex — switching is easy. Taking what your AI knows about you with you is not. A practical guide to making your AI context portable.

Nobody plans to switch AI coding tools. Then your vendor raises prices 35%. Or the model you rely on gets deprecated. Or a competitor ships something genuinely better and you want to try it this week, not after a migration project.

The switch itself takes ten minutes — install, sign in, done. What actually hurts is the part nobody prices in: everything your old tool knew about you stays behind. The project background you explained over months. The architecture decisions. The conventions ("we use pnpm", "never touch the DB directly", "API returns snake_case"). Your first week in the new tool is spent re-teaching a stranger things your last tool already knew.

This guide is about fixing that permanently: making your AI context portable, so switching tools becomes a config change instead of a memory wipe.

Step 1 — Know what's portable and what isn't

"Take everything with you" is not realistic, and anyone who promises it is selling something. Your setup has two very different layers:

LayerExamplesPortable?
Knowledge & contextProject background, decisions, conventions, preferences, "what we tried and why it failed"✅ Yes — it's just information. This is the layer this guide moves.
Tool configurationSkills, plugins, slash commands, MCP server configs, keybindings❌ Mostly no — these are written against one tool's API and have to be redone per tool.

The good news: the knowledge layer is the expensive one. Configs take an afternoon to rebuild; months of accumulated context can't be rebuilt at all — only lost.

Step 2 — Inventory where your context actually lives

Before moving anything, find it. For most developers it's scattered across:

  • CLAUDE.md / AGENTS.md files in each repo (Claude Code, Codex)
  • .cursor/rules or .cursorrules (Cursor)
  • ChatGPT's built-in memory and Projects (locked to your OpenAI account)
  • Claude.ai Projects and their knowledge files (locked to your Anthropic account)
  • Chat history in all of the above — the worst kind: real decisions buried in scroll

Notice the pattern: every single location is owned by one vendor or one tool. That's the actual lock-in — not the subscription, the memory.

Step 3 — Extract the high-value context

Don't try to export everything; most chat history is noise. Extract the distilled layer. A practical checklist per project:

  • Decisions: what you chose (stack, architecture, APIs) and why
  • Conventions: the rules you keep repeating to your AI
  • Failed paths: what you already tried — the most expensive knowledge to lose
  • Preferences: how you like code, commits, and explanations

Your existing CLAUDE.md and Cursor rules files are already this — copy them out. For chat-locked context, a fast trick: ask the old tool itself to write the summary. "Summarize everything you know about this project: decisions, conventions, things we ruled out. Plain markdown."

Step 4 — Put it somewhere every tool can read

Extracting once doesn't help if you paste it back into another tool-owned silo — you'll be doing this again at the next price hike. The fix is structural: keep your context in a tool-agnostic memory layer, and let every AI tool read from it over MCP — the open protocol that Claude, Cursor, Codex, and most serious AI tools now speak.

This is exactly what we built DogearAI for. You dump your extracted context in (paste it, or just tell your AI to remember things as you work); it organizes everything into memory spaces as plain markdown that you own and can export anytime. Then every client reads the same memory:

Claude Code — one command:

claude mcp add --transport http dogear \
  https://www.dogearai.com/mcp \
  --header "Authorization: Bearer dg_your_token"

Cursor~/.cursor/mcp.json:

{
  "mcpServers": {
    "dogear": {
      "url": "https://www.dogearai.com/mcp",
      "headers": {
        "Authorization": "Bearer dg_your_token"
      }
    }
  }
}

Same token, same memory, both tools. Setup details are in the docs — it's a few minutes per tool.

Why not a vector database or a RAG pipeline? For curated context like this, an LLM reading clean markdown beats chunked embeddings: simpler, portable, and you can open your memory and see exactly what your AI knows. No black box.

Step 5 — Verify the memory actually moved

Open the new tool and ask it something only the old tool used to know: "What package manager does this project use, and why did we rule out the REST approach?" If it answers from memory instead of asking you to explain, the migration is real.

The end state: switching stops being scary

Once your context lives in a layer you own, the calculus of every future tool decision changes. New model drops? Try it the same afternoon — it reads your memory over MCP and knows your projects from message one. Vendor raises prices? Leave without losing anything. You can even run three tools side by side and they stay in sync, because they share one memory instead of keeping three diverging ones.

Your tools should compete for you every month. They can't do that while one of them holds your memory hostage.

DogearAI is free during beta — no credit card. Set it up once, and the next time you switch tools, take everything with you.