How to Migrate From Kiro to Claude Code Without Losing Context (2026)

Your steering files, as CLAUDE.md plus path-scoped rules. Kiro loads .kiro/steering/ for the workspace and ~/.kiro/steering/ globally, prioritizing workspace on conflict. Claude Code's equivalents are ./CLAUDE.md for "Team-shared instructions for the project" and ~/.claude/CLAUDE.md for "Personal preferences for all projects" — but note the resolution differs: Claude Code concatenates in load order rather than overriding, and warns that "if two rules contradict each other, Claude may pick one arbitrarily."

Kiro's inclusion modes have a partial home. .claude/rules/ files accept a paths: frontmatter field of globs and "only apply when Claude is working with files matching the specified patterns," which is close to Kiro's fileMatch. Kiro's always becomes an ordinary always-loaded file. Kiro's manual and auto modes — invoked with #name or selected by the agent from a description — have no direct rule equivalent, so those files either become skills or become always-on text you should trim.

Your AGENTS.md, with a caveat. Kiro reads it and notes that "AGENTS.md files do not support inclusion modes and are always included." Claude Code "reads CLAUDE.md, not AGENTS.md." The documented bridge is a one-line @AGENTS.md import at the top of CLAUDE.md, after which the imported file loads at session start. Keep one file authoritative; imports resolve to "a maximum depth of four hops," and every imported file enters context at launch.

Your Skills, as a directory move. Both build on the same open standard. Kiro's skill directories become ~/.claude/skills/<name>/SKILL.md for personal skills and .claude/skills/<name>/SKILL.md for project skills. Watch the precedence, which inverts Kiro's steering behavior: Claude Code's rule is that enterprise overrides personal and personal overrides project, so a personal skill beats a project skill of the same name.

Your specs, as readable files. .kiro/specs/<name>/ holds requirements.md, design.md, and tasks.md — markdown in your repo, still readable after the move. The three-phase workflow around them does not come along.

Your learned memory, into a real but simpler container. This is the new part, and it deserves its own section.

Nothing else transfers cleanly, and four things behave differently.

Six layers collapse into four categories. Claude Code's auto memory records a type field of user ("your role, expertise, and working preferences"), feedback ("corrections you give Claude and approaches you confirm"), project ("ongoing work, deadlines, and decisions that Claude can't derive from the code or git history"), and reference ("where to find information outside the project"). Kiro's preferences.md maps onto user; its lessons map onto feedback; projects.md and history map roughly onto project. Its semantic and episodic stores — SQLite tables with vector search, per-entry importance, and top-8 retrieval per query — have no counterpart. Claude Code keeps a MEMORY.md index plus one topic file per memory, and "doesn't load topic files such as user_role.md... at startup."

Your lessons lose their guarantee. This is the loss to plan around. Kiro stores lessons as semantic entries at confidence 1.0, dedupes them by substring and topic overlap, caps them at 50, and injects them "as a distinct [Learned corrections] block" — a block whose own text reads "ALWAYS follow these. They override default behavior." Its conflict-resolution order puts lessons at position one, above everything else. Claude Code's feedback type is a note in a file, loaded with everything else, and its docs are explicit that instruction content is "context rather than enforced configuration." Same information, much weaker promise.

Decay is replaced by a cliff. Kiro fades gracefully: history drops to "First entry per day + count" at 14 days, to "Date + entry count only" at 61, stops loading at 181, and is "Deleted from disk" at 365; episodic entries decay on an explicit curve — "50% at ~23 days, 10% at ~77 days" — and the store prunes "lowest-importance, oldest" first at 10,000 entries. Claude Code has no decay. Its files "stay until you or Claude edits or deletes them," and are deliberately excluded from the session-transcript retention sweep. What it has instead is a read limit: "the first 200 lines of MEMORY.md, or the first 25KB, whichever comes first," and if the index goes over, "the write still succeeds" but "everything past the limit is dropped on the next load." Graceful fade out, hard truncation in.

Confidence gating disappears. Kiro requires "confidence ≥ 0.8" for LLM writes to semantic memory, with "User-explicit writes always win regardless of confidence." Claude Code decides differently: "Claude doesn't save something every session. It decides what's worth remembering based on whether the information would be useful in a future conversation." A judgment call rather than a threshold — neither better nor worse, but not a knob you can reason about.

Step 1: Read the layers that have no destination, before you stop using Kiro

Take a snapshot first: kirocrew snapshot bundles memory, workspace, crons, config, skills, and notifications into a tarball. Only Kiro reads it, so treat it as a backup rather than an import file — and Kiro's built-in daily job "keeps the last 7 snapshots," so do not assume last week's is still there. One caution from Kiro's own docs: "Snapshots contain sensitive data (security keys used for audit-log integrity)."

Then read four things, in this order.

Your lessons. Capped at 50, confidence 1.0, and the highest-priority layer in Kiro. These are the corrections you either stated outright or that Kiro extracted from a pattern of you correcting it. Nothing in your repository implies them, and they are about to become ordinary notes.

preferences.md and projects.md. Both are "Replaced wholesale by the consolidator every 30 messages — not append-only," which means what you are reading is Kiro's current model of you rather than a log. They are also capped at 4,250 and 6,400 characters, so this is a short read with an unusually high signal-to-noise ratio.

Your episodic entries. Short snippets, 10–2,000 characters each, up to 10,000 of them. You will not read all of them; query for the projects you are still on and skim, since retrieval returns top-8 per query.

Kiro Web's learned memory, if you used it. In Settings under Memory. Kiro's own table draws the line worth internalizing: memory is what "the agent learns it automatically as you work and give feedback," where the user controls "Deletions"; steering is what "You write it explicitly," where the user controls "All edits." Only the first half is at risk here.

Step 2: Land the written half, then set expectations for the written-for-you half

Instructions first. Convert .kiro/steering/ into CLAUDE.md plus .claude/rules/ files, using paths: globs wherever a steering file had a fileMatch pattern. Run /init if you want a generated starting point; it "suggests improvements rather than overwriting" an existing file.

Then trim. Claude Code's guidance is to "target under 200 lines per CLAUDE.md file" because "Longer files consume more context and reduce adherence." A steering directory that grew to a dozen always-on files will not survive that budget intact, and the honest move is to decide what drops rather than let the read limit decide for you.

Confirm what actually loaded with /context and check the list under Memory files. That is the authoritative answer, and it is the documented first debugging step.

Then auto memory, and give it a week. It is on by default. Its storage is ~/.claude/projects/<project>/memory/, where <project> "is derived from the git repository, so all worktrees and subdirectories within the same repo share one auto memory directory."

Two properties to internalize now rather than discover later. It is deliberately complementary to your instruction files — Claude "skips anything it can derive from the codebase" and "skips anything your CLAUDE.md files already say" — so the memory directory holds exactly what your converted steering does not. And it is not portable: "Auto memory is machine-local" and "Files are not shared across machines or cloud environments."

So the honest summary of this migration's portability story is that you moved from one home directory to another. Kiro Crew's memory lived under ~/.kiro/; Claude Code's lives under ~/.claude/. Neither travels — the general shape of that problem is in why Claude Code forgets project context.

Run /memory after a week and read what it wrote. Then re-enter your Kiro lessons as explicit content, because the feedback notes Claude writes for itself are not the same as rules you insisted on.

Look at what this migration actually consisted of. Steering files converted cleanly. Skills needed a directory move. Specs stayed readable. And the part that took real work — the part with no clean destination — was six layers of learned knowledge sitting under one user's home directory on one machine, which you had to read by hand and retype.

That is not a Kiro problem or a Claude Code problem. Both built learned-memory systems, both keep them local by design, and both are reasonable engineering choices. It just means the only copy of why you rejected an approach should not live in either one.

That is what MemoryLake holds: your project's durable knowledge in a layer your tools query, so the next switch is a preference rather than a transcription exercise. Setup is three steps.

Step 1: Create an API key

Sign in and create an API key. One credential across the tools you connect.

Step 2: Upload your first memories

Short entries, one claim each. Write these straight out of the Step 1 read, while it is fresh:

Your 50 lessons, one per entry. The highest-priority layer in Kiro and the least reconstructible thing you own.

What preferences.md and projects.md currently say. Wholesale-replaced files are short by construction. Split them into claims rather than pasting.

Decisions with the reason attached. "We queue writes because the replica lags under load." A rule states the policy; only the reason stops the alternative coming back.

Approaches already tried and rejected here. Absent from steering, absent from commit messages, re-proposed every session.

Step 3: Connect your AI & agents

MemoryLake is reachable over MCP and over an API, and both Kiro and Claude Code support MCP servers — so you can run them side by side during the transition without maintaining two copies of the same reasoning, and other assistants read the same memory through the API.

Three honest limits. MemoryLake cannot read a Crew snapshot, import Kiro Web's memory, or write your CLAUDE.md and auto memory files — those are each product's own surfaces, and the loader behavior above is theirs. It holds only what you or your agents put into it, so Step 2 is manual. And instructions are context rather than enforced configuration; for anything that must hold every time, Claude Code's own answer is a hook, not a file.

Steering conversion is mostly mechanical. fileMatch becomes a paths: glob; always-on stays always-on.

Skills need a directory move and a precedence check. Personal beats project.

Your corrections lose their override block. Re-state the important ones as explicit instructions, not notes.

Automatic pruning stops. No more tiered fade — but MEMORY.md truncates hard past 200 lines or 25KB.

Portability does not improve. One home directory to another — the general problem in what persistent memory actually means.

Snapshot first, and keep the tarball off shared drives. Kiro flags that it contains sensitive keys.

Read your lessons before anything else. Fifty entries, highest priority, no equivalent guarantee on the other side.

Re-state lessons as instructions, not as memory. A feedback note is context; a CLAUDE.md line you wrote is intent.

Convert fileMatch steering to paths: rules, and trim the rest. The 200-line target is guidance you should treat as a budget.

Verify with /context, not memory. The Memory files list is what actually loaded.

Watch MEMORY.md length. Past the read limit, "everything past the limit is dropped on the next load."

Don't paste the codebase into CLAUDE.md. Both vendors advise against restating what the repo already says — the cost side is in how to stop Claude Code re-reading your codebase.

Keep the reasoning outside both tools. Every layer here has a cap, and reasoning is the first thing cut — the general version in why a long context window isn't memory.

Kiro to Claude Code is the first migration in this family where the learned half has somewhere to go, and that makes it easier and more deceptive at the same time. Steering converts to CLAUDE.md plus paths:-scoped rules, AGENTS.md bridges through a one-line import, skills move folder-for-folder, and specs stay readable. Auto memory is on by default and starts recording your corrections within a week.

The losses are specific. Six layers become four note types, and Kiro's semantic and episodic stores — confidence-gated writes, vector retrieval, per-entry importance, explicit decay curves — have no counterpart. Your lessons lose the strongest guarantee either system offers: a distinct injected block at the top of the conflict-resolution order, telling the agent these override default behavior. Automatic decay is replaced by a hard read limit that silently drops whatever sits past 200 lines or 25KB. And portability does not improve, because both systems keep learned memory in a home directory on one machine.

So take the snapshot, read your fifty lessons and your two consolidated files, convert the steering with the glob mapping, and re-state the corrections that mattered as instructions rather than trusting them to be re-learned. Then put the decisions and the rejected approaches in a layer neither ~/.kiro/ nor ~/.claude/ owns, and the next switch costs you an afternoon instead of a quarter.