What actually transfers
Your CLAUDE.md transfers as-is, conditionally. Covered above. Treat it as a grace period rather than a destination: it works until an AGENTS.md appears in the same directory.
The load model is close enough to be reassuring. Claude Code loads "CLAUDE.md and CLAUDE.local.md files in the directory hierarchy above the working directory... at launch," while "Files in subdirectories load on demand when Claude reads files in those directories." Amp is nearly identical: "AGENTS.md files in the current working directory (or editor workspace roots) and parent directories (up to $HOME) are always included," and "Subtree AGENTS.md files are included when the agent reads a file in the subtree."
Same shape, same laziness about subtrees. This half of your mental model survives.
Personal and system scopes exist on both sides, at different paths. Claude Code has four documented scopes in load order: managed policy, user (~/.claude/CLAUDE.md), project, and ./CLAUDE.local.md. Amp has repository files plus "$HOME/.config/amp/AGENTS.md" and "$HOME/.config/AGENTS.md" for "Personal preferences, device-specific commands, and guidance that you're testing locally before committing," plus system-wide files at /etc/ampcode/AGENTS.md, /Library/Application Support/ampcode/AGENTS.md, or %ProgramData%\ampcode\AGENTS.md for "System-wide or organization-managed guidance for all Amp sessions."
All of Amp's non-repository files are "always included if they exist." So your user-scope content maps cleanly; the path changes and the loading is unconditional on both sides.
Conditional rules transfer, and get better. This is the genuine upgrade. Claude Code scopes instructions with a paths field in .claude/rules/ frontmatter, where "Path-scoped rules trigger when Claude reads files matching the pattern." Amp does the same job through @-mentioned files carrying a globs list: "Mentioned files with globs will only be included if Amp has read a file matching any of the globs."
Two things to know when you convert. A bare mention is unconditional — "If no globs are specified, the file is always included when @-mentioned" — so the frontmatter is the whole point. And glob resolution has its own rule: "Globs are implicitly prefixed with **/ unless they start with ../ or ./, in which case they refer to paths relative to the mentioned file."
Import syntax changes meaning, not just spelling. Claude Code's @path/to/import pulls a file in at launch: "Imported files are expanded and loaded into context at launch alongside the CLAUDE.md that references them," with "a maximum depth of four hops." Amp's @-mentions look the same and can be conditional. Both skip code blocks — Claude Code's "Import parsing skips Markdown code spans and fenced code blocks," Amp's "@-mentions in code blocks are ignored, to avoid false positives" — so a path in backticks stays literal in either.
One difference to catch: "Relative paths are interpreted relative to the agent file containing the mention," not to your working directory. Claude Code resolves the same way, so a straight copy usually works, but a file you move up or down a level breaks its own mentions.
Auto memory does not transfer. There is nothing to transfer it into. Claude Code runs two systems, not one. Alongside the files you write, "Auto memory lets Claude accumulate knowledge across sessions without you writing anything," tagged by type: user for "your role, expertise, and working preferences," feedback for "corrections you give Claude and approaches you confirm," project for "ongoing work, deadlines, and decisions that Claude can't derive from the code or git history," and reference for external pointers.
It is on by default, it lives in local files under ~/.claude/projects/<project>/memory/ with a MEMORY.md index, its scope is "Per repository, shared across worktrees," and the loaded slice is bounded: "Every session (first 200 lines or 25KB)."
Amp's documented persistence is AGENTS.md files you write plus threads, and threads are conversations rather than a store — there is no documented counterpart to a self-writing memory directory. So the half of your Claude Code setup that accumulated by itself — the corrections you gave, the preferences it inferred — has no destination.
Threads are not a memory layer, and Amp does not claim they are. They are genuinely well designed for continuity of work: a thread has a URL, "The same thread opens in the web app, the CLI, the Amp apps for iOS and macOS," and "Where the agent runs is separate from where you look at it." The guidance is one thread per task, because "a thread that mixes unrelated work gives the agent a worse context to reason with," with a documented escape hatch when one grows — "ask the agent to 'Handoff and …' and it starts a fresh thread with the context that matters."
Useful. Also not a place to keep facts, since a handoff carries what the agent judged relevant rather than everything true about your project.
The manual migration
Step 1: Rename deliberately, then split by trigger
Do not rely on the fallback. Create real AGENTS.md files at the same paths your CLAUDE.md files occupy, so the behavior is explicit rather than conditional on nobody adding a file later.
Then split, because Amp asks you to: "In a large repository with multiple subprojects, we recommend keeping the top-level AGENTS.md general and creating more specific AGENTS.md files in subtrees for each subproject." Claude Code gave the same advice from the other direction — "target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence" — so if you were already under that ceiling, this is mostly a copy.
Convert your .claude/rules/ entries next. A rule with a paths field becomes a file referenced from AGENTS.md with a globs list in its frontmatter. A rule without one was loaded unconditionally, so it belongs in the general file rather than as a bare mention.
Move ~/.claude/CLAUDE.md content to $HOME/.config/amp/AGENTS.md. For anything that was in CLAUDE.local.md — "Personal project-specific preferences" you kept out of version control — Amp's $HOME/.config files are the closest home, with the difference that they apply everywhere rather than to one project.
Then verify, with the command built for it: "To see the agent files that Amp is using, select agents-md list from the command palette." Run it from a couple of directories and after the agent has read different file types. That is the equivalent of checking /context for Memory files in Claude Code, and it is how you catch a mention whose relative path broke in the move.
Step 2: Read your auto memory before you stop using Claude Code
This step has no tooling and it is the one people skip.
Open ~/.claude/projects/<project>/memory/. The files are plain markdown with a MEMORY.md index, and they are readable precisely because Claude wrote them for itself. Read them.
What you find will be the residue of months of corrections, and it is worth sorting as you go. Items that read like instructions — a formatting preference, a rule you kept restating — become content in your new AGENTS.md or a glob-scoped file. Items that read like facts about the project — a deadline, a decision and its reason, why a workaround exists — do not belong in an instruction file at all, and we will come back to them.
Note also what Claude Code deliberately did not record, because it changes what you should expect to find: "Claude skips anything it can derive from the codebase" and "also skips anything your CLAUDE.md files already say." So auto memory is the complement of your files, not a duplicate of them. Everything in there is something the code cannot tell you — which is the same reason it is the part most worth rescuing, and the pattern behind why Claude Code forgets project context when those files are lost.
The Better Way: Keep the Half That Accumulates Outside Both Tools
The rename is mechanical and the glob conversion is an upgrade. What makes this migration cost real time is the accumulated half — and you will pay it again on the next switch, because the thing that accumulated was stored inside a tool.
Claude Code's own framing points at why. It separates what you write from what the agent learns, and treats both as context rather than configuration: "Claude treats them as context, not enforced configuration." Amp keeps the first category and drops the second. Neither tool is wrong; the category just needs a home that is not a tool.
Put the accumulating half in a memory layer and the migration shrinks to a rename. MemoryLake sets up in three steps.
Step 1: Create an API key
Sign in and generate an API key from your dashboard. It is not an editor setting or an agent's local directory, so it does not have the property that started this migration — nothing about it is a fallback that another file can silently outrank.

Step 2: Upload your first memories
This is where the second pile from Step 2 goes: decisions and their reasons, deadlines, domain vocabulary, why a workaround exists, the corrections you have already given more than once.

Leave behavior in AGENTS.md, scoped with globs where a pattern fits. The two layers do different jobs, and mixing them is how an instruction file grows past the point of being followed.
Step 3: Connect your AI & agents
Point Amp at the store. Your AGENTS.md files stay short and behavioral, a new thread starts from your project's facts instead of from a handoff summary, and the knowledge survives the next tool you evaluate — the case made in cross-agent memory.

What this changes in practice
The first change is that the fallback stops being load-bearing. Explicit AGENTS.md files plus an external store means no part of your setup depends on a file not existing.
The second is that losing auto memory costs less. It was a good feature and Amp not having it is a real gap — but only for knowledge with nowhere else to live.
The third is that glob-scoped guidance gets to stay small. Amp's conditional loading is genuinely better than an always-on file, and it works best when the things you are gating are instructions rather than a filing cabinet of project facts — the reasoning in reducing token usage with a memory layer.
Best practices for a Claude Code to Amp move
- Create real
AGENTS.mdfiles. TheCLAUDE.mdfallback applies only where noAGENTS.mdexists. - Split the root file. Amp recommends a general top-level file with specific subtree files.
- Convert
pathstoglobs. And remember a bare@-mention is unconditional. - Mind glob resolution. Implicit
**/prefix unless the pattern starts with./or../. - Check mention paths after moving files. They resolve relative to the file containing the mention.
- Read your auto memory directory first. Plain markdown, indexed by
MEMORY.md, and nothing exports it. - Verify with
agents-md list. From several directories, after touching different file types. - Do not treat threads as storage. One thread per task, and a handoff carries what the agent judged relevant.
Conclusion
Amp reading CLAUDE.md makes this look like the easiest migration in the category, and for the file half it nearly is — with a conditional-loading model that improves on what you had.
The half that hurts is the half that wrote itself. Claude Code accumulated your corrections into local markdown; Amp has no such layer, and no importer is coming for it. Read that directory before you leave it, sort instructions from facts, and put the facts somewhere the next tool switch cannot touch.