# Context Migration Guide
#### **Your best thinking, carried forward** Long conversations with Claude are where real work happens. But as a conversation grows, the earliest context can start to fade. This guide gives you a simple process to capture what matters, move it into a fresh conversation, and pick up exactly where you left off.
About this guide #### **Long conversations with Claude are where real thinking happens. Definitions get sharpened, decisions get pressure-tested, ideas take shape over dozens of exchanges. That accumulated depth is valuable, and it can feel unsettling when a conversation starts to slow down.** This guide walks you through a straightforward process for carrying your best work into a fresh conversation. It takes a few minutes, and when you're done, you'll pick up right where you left off. Think of it less as an interruption and more as a clean page turn. Many users report that the process of summarizing actually sharpens their thinking and leaves them in a better position than before. \ **What is this guide**\ A step-by-step process for transferring the important context from a long Claude conversation into a fresh one, so you keep the depth you've built without the performance cost of an overloaded context window. \ **Why it matters**\ Claude holds a limited amount of conversation in active memory at any given time. As that space fills, responses can become less precise. This isn't a flaw in reasoning. It's a natural constraint of how context windows work. Migrating lets you carry forward what matters and leave behind what doesn't. \ **How it works**\ You'll create a structured summary of your conversation, validate it for accuracy, then use it to seed a new conversation. The guide gives you ready-to-use prompts and a checklist to confirm nothing was lost. \ **Who it's for**\ Anyone who works with Claude on projects that span long or multiple conversations. This includes research, writing, strategy, software development, creative projects, and anything that builds complexity over time. No technical background required. {% hint style="info" %} #### **Scope of This Guide** The guide works whether you're chatting with **Claude directly** or working inside a **Claude Project.** If you're using a Project, some of your context (instructions, knowledge files, reference documents) already persists across conversations automatically. The migration process described here focuses on capturing what lives only in the conversation itself: the decisions, definitions, reasoning, and progress that would otherwise be lost when you move to a fresh chat. {% endhint %}
Recognizing When to Migrate
You don't need to wait for something to go wrong. The best migrations happen before problems start. Here's what to watch for, ordered from the earliest signals to the most obvious. #### **Early signs** Claude gives answers that feel slightly more generic than before. You might notice it restating something you defined together using looser phrasing, or you find yourself re-explaining a concept that was well-established earlier in the conversation. #### **Clear signals** You've had roughly 30 or more substantive back-and-forth exchanges. Claude occasionally misses a nuance it previously handled well. If you ask Claude to recall a specific definition or decision from early in the conversation and the answer comes back vague or incomplete, it's time to act. #### **Late signals** Responses feel noticeably less grounded in your shared context. Claude may track your recent messages well but struggles with anything established early on. Don't push further. Migrate now.
{% hint style="info" %} #### **What's happening to my conversation?** Claude processes your conversation within a context window of fixed size. Think of it as a workspace with a limited surface area. As a conversation grows, the earliest exchanges may be dropped or deprioritized to make room for newer ones. Claude doesn't rewrite your earlier messages, but it may no longer access them with the same precision it had when they were recent. Migration is the deliberate, human-controlled version of managing this constraint: you decide what's important, you curate it into a summary, and you carry it forward with full fidelity into a fresh conversation with a clean context window. The same constraint applies to all large language models, not just Claude. {% endhint %} #### **Why earlier is better** There's a practical consequence to waiting too long. If you ask Claude to produce a summary after significant context degradation has already set in, the summary itself will have gaps, because Claude can't reliably summarize content it can no longer fully access. You'll catch some of these gaps during the review step, but others may slip through. The most reliable migration is one that starts before you notice problems. If you know a conversation will be long, plan the migration in advance. A summary produced while Claude still has full access to the conversation will always be more accurate than one produced after the early foundations have started to fade.
When migration isn't the right move
Not every long conversation needs a formal migration. Here are a
few cases where you can skip it. #### **The conversation was exploratory** If you were brainstorming, testing ideas, or thinking out loud without establishing definitions or making firm decisions, there may be nothing worth preserving in a structured summary. Start fresh and bring forward only the conclusions, in your own words and in your own time. #### **The context already lives in your Project** If you're using a Claude Project and your key definitions, constraints, and reference documents are already uploaded as project knowledge, a full migration summary may be redundant. The project knowledge persists across conversations automatically. You may only need a brief note on where you left off and what to work on next, not a full Master Summary. #### **You're changing direction** If the conversation helped you realize the project needs a fundamentally different approach, a detailed summary of the old approach can anchor you to decisions you've already moved past. In this case, capture any lessons learned worth keeping and start the new direction clean.
Before You Start
A full migration takes about 15 minutes. Here's what you'll produce along the way. | Artifact | Purpose | Size | | ----------------------------------- | ---------------------------------------------------- | --------------------- | | **Master Summary** | Single document capturing everything important | Under 3,000 words | | **Continuity Checklist** | 5 to 8 testable items to verify the new conversation | About half a page | | **Supporting artifacts** (optional) | 1 to 3 documents the next session needs right away | Only what's essential | Every step below is tagged so you know who acts: | Tag | Meaning | | --------------- | ------------------------------------------ | | 👤 **You** | Something only you can do | | 🤖 **Claude** | Something you ask Claude to do | | 🤝 **Together** | You review and refine what Claude produces |
#### **Migration Steps (9)** ## **1. Stop and shift gears** 👤 **You** When you recognize the signs above, pause whatever you're working on. Don't start any new topics. From this moment, every exchange is about capturing what you've built, not building more.
This can feel like you're interrupting productive work. You're not. You're protecting it. The few minutes you spend here will save you from the much larger cost of trying to reconstruct lost context later.
Real examples of what migration signals look like *The signals described can show up in different ways depending on what you're working on. Here are some concrete examples across common use cases to help you recognize them in your own conversations.* #### **You're developing a brand strategy** Early in the conversation, you and Claude established that your target audience is "independent professionals aged 30 to 45 who value transparency over polish." Forty messages later, you ask Claude to draft tagline options. The suggestions feel generic and aspirational, aimed at a broader audience. You point this out, and Claude apologizes and corrects, but the next draft still skews general. The specific audience definition has faded from active context. #### **You're writing a research paper** You spent the first part of the conversation defining your methodology and key terms carefully. Claude handled follow-up questions precisely for the next 20 exchanges. Now, when you ask it to help write the discussion section, it uses one of your defined terms in a slightly different sense than you established, or conflates two concepts you deliberately kept separate. You correct it, but two messages later it drifts again. #### **You're building a software application** You outlined an API structure with Claude, including specific naming conventions and a rule that all endpoints return a standard error format. Thirty messages and several features later, you ask Claude to write a new endpoint. It uses a different naming pattern and returns errors in a freeform structure. It hasn't forgotten the project, but the detailed conventions from the early conversation are no longer reliably accessible. #### **You're planning a major event** You and Claude worked through venue constraints, dietary requirements, a seating strategy, and a detailed timeline. Near the end of the conversation, you ask for a summary email to send your team. The email captures the broad strokes but drops two of the four dietary constraints and gets the setup time wrong by an hour. The details from the earliest messages have lost precision. #### **You're collaborating on a book or long-form writing project** You established a character's backstory, voice, and a specific narrative rule ("the narrator never reveals their own feelings directly; only through the reactions of other characters"). After extensive work on later chapters, you ask Claude to write a scene for this character. The voice is close but not quite right, and the narrator breaks the rule once in a way that's subtle enough to miss on a quick read. #### **The common thread across all of these** In each case, the most recent parts of the conversation still work well. It's the early foundations (definitions, rules, constraints, precise details) that start to soften. This is the pattern to watch for. When the foundations drift, it's time to migrate.
## **2. Generate your Master Summary** 🤖 **Claude** Ask Claude to produce a structured summary of everything important in your conversation. The prompt below is designed to work across different types of projects. You can paste it directly:
``` MASTER SUMMARY — GENERATION PROMPT Project: [Name] Version: [v1, v2, v3...] Date: [Today's date] Previous summary version pasted below: [Yes / No] --- YOUR TASK Produce a structured Master Summary of everything important we've established in this conversation. This summary will be pasted into a fresh conversation to restore full working context, so write it to be understood by a Claude instance with no knowledge of what we've discussed. If a previous summary version is pasted below, treat it as a foundation. Update, correct, and extend it with what we've added or changed in this conversation. Flag anything in the previous version that has been revised or superseded. If this conversation is inside a Claude Project, do not duplicate context that already lives in the Project's instructions or knowledge files. Focus on what this conversation produced: decisions, definitions, reasoning, progress, and open questions that would otherwise be lost. --- STRUCTURE Organize the summary into the following sections. Within each section, organize entries thematically, then chronologically within each theme. 1. PROJECT CONTEXT What we're working on, why it matters, and where we currently stand. State the core objective in one sentence. Then provide enough background that someone encountering this project for the first time could orient themselves and contribute. 2. KEY CONCEPTS AND DEFINITIONS Every term, concept, model, or framework we've defined or refined in this conversation. Use original wording where possible. Mark any entry where you're reconstructing from context rather than drawing from an explicit definition with [reconstructed]. 3. PRINCIPLES AND CONSTRAINTS Design rules, boundaries, non-negotiables, stylistic guidelines, or strategic commitments we've established. For each, note the reasoning that produced it, if discussed. 4. DECISIONS AND REASONING What we decided and why. Include alternatives we considered and the reasons we rejected them. If a decision was revised during the conversation, show both the original and the revision with sequence indicators. Current decisions should be clearly distinguishable from superseded ones. 5. ARTIFACTS AND DELIVERABLES Anything we produced: documents, templates, frameworks, prompts, code, files, published content. Include the current state of each (draft, final, shared, etc.) and where it lives if known. 6. OPEN QUESTIONS What remains unresolved, why it's unresolved, and any partial thinking or leading options we've discussed. 7. CURRENT STATE A clear snapshot: what's complete, what's in progress, and what hasn't started. Be specific enough that work could resume without re-reading this conversation. 8. NEXT STEPS The priority actions for when work resumes, in order of importance. For each, note any dependencies or blockers. 9. GAPS AND CONFIDENCE FLAGS Anything from this conversation where your recall is uncertain, where we seemed to shift position without fully resolving the earlier view, or where important context may have already left the context window. Name the gap specifically. Do not silently omit or gloss over uncertain areas. --- VERIFY After producing the summary, perform a self-check: a) Are there terms in Section 2 that appear elsewhere in the summary but aren't defined? b) Does Section 7 contain enough detail that work could genuinely resume from it alone? c) Are any decisions marked as current that were later revised during our conversation? d) If this is an update to a previous summary, have you noted what changed? Append a short verification note at the end stating what you checked and whether you found issues. --- RULES Keep the summary under 3,000 words. When space is tight, compress in this order: background context first (the reader can ask follow-up questions), then reasoning behind rejected alternatives, then historical sequence details. Protect definitions, current decisions, open questions, and next steps from compression — these are the highest-value content for the receiving conversation. Use exact original language for definitions and decisions wherever possible. Do not paraphrase what you can preserve. Flag uncertainty visibly rather than smoothing over it. ``` To see what a finished Master Summary looks like, see [this example](https://chocolate-sushi-147.notion.site/Master-Summary-Community-Events-Platform-332d4e3a5b0680dca86ad14c27bbbe0d).\ \ **Adapting the prompt for specific project types**\ The universal prompt works across project types. The section headings are flexible enough to accommodate most work. Here's how to read them for your domain.
What if my project doesn't fit these categories? The summary template is designed to be flexible. Most of the section headings apply across project types, and the adaptation guidance above shows how to read them for creative writing, software development, and research work. If a section has no relevant content, note that briefly ("Nothing established in this conversation") rather than removing it entirely. This helps the receiving conversation understand that the gap is intentional, not an oversight. If you need a section that isn't listed (like "Voice and Tone" for a writing project or "Known Issues" for a coding project), add it. The structure matters more than the specific headings. Just follow the same principles: use exact original language where possible, flag uncertainty, and organize thematically then chronologically.
Adapting the prompt for specific project types
The universal prompt works across project types. The section headings are flexible enough to accommodate most work. Here's how to read them for your domain. ### **For creative writing projects** * "Key Concepts and Definitions" becomes your character bible and world rules. * "Principles and Constraints" captures voice guidelines, narrative perspective, and stylistic commitments (for example, "the narrator never reveals their own feelings directly"). * "Decisions and Reasoning" covers plot choices, structural decisions, and directions you explored but deliberately rejected. If voice is central to your project, consider adding a **"Voice and Tone"** subsection under Principles and Constraints. If you're building a world with internal rules, a "World Logic" subsection under Key Concepts can help keep those rules precise across migrations. ### **For software development projects** * "Key Concepts and Definitions" captures your architecture, data models, API structure, and naming conventions. * "Principles and Constraints" covers technical requirements, performance targets, coding standards, and error handling patterns. * "Artifacts and Deliverables" should include file names, repository locations, and the state of each component. If your project has accumulated technical debt or known issues, add a "Known Issues" subsection under Open Questions. If you've established code conventions that go beyond what a linter enforces, make sure those appear in Principles and Constraints with enough specificity that the next conversation applies them correctly. ### **For research and analysis projects** * "Key Concepts and Definitions" holds your analytical frameworks and precisely defined terms, especially where you deliberately chose one definition over another. * "Decisions and Reasoning" captures methodological choices, scope decisions, and framing choices. * "Artifacts and Deliverables" tracks sources, datasets, and draft documents. If your research has a working thesis that has evolved during the conversation, consider adding a "Working Thesis" subsection under Project Context that shows its current state and how it shifted. ### **For any project type** If you need a section that doesn't exist in the template, add it. The structure matters more than the specific headings. Make sure any added section follows the same principles: use exact original language, flag uncertainty with \[reconstructed] where you're not drawing from an explicit definition, and organize thematically then chronologically.
## **3. Review and correct** 🤝 **Together** This is the most important step in the entire process. Read the summary carefully. Look for: **Definitions that have drifted**\ Claude may subtly rephrase things you defined precisely. Insist on exact wording where it matters. **Missing reasoning**\ It's common for the "why" behind a decision to get dropped. The decision alone isn't enough. Add the reasoning back. **False confidence**\ If Claude presents something uncertain as settled, or something nuanced as simple, flag it. Watch specifically for definitions or decisions that sound confident but were actually unresolved or debated during the conversation. The \[reconstructed] tags in the summary can help: any entry marked \[reconstructed] deserves a closer look, since Claude is signaling that it inferred the wording rather than pulling it from something you explicitly stated. **Gaps**\ Anything you would need in the first five minutes of the new conversation that isn't captured here. **Duplicated Project context**\ If you're working inside a Claude Project, check whether the summary repeats material that already lives in your Project's instructions or knowledge files. If it does, trim it. The summary's word budget is best spent on what this conversation produced, not on context the new conversation will already have access to. Ask Claude to revise until the summary reads the way you would write it yourself. Two rounds of revision is typical. Three rounds at most.
How do I know when the summary is good enough? **A good test:** read each section and ask yourself, "If I came back to this in a week with no other context, would I understand exactly what it means?" If the answer is yes, it's ready. If you find yourself thinking "well, I know what this means because I remember the conversation," that section needs to be more explicit. The summary should stand on its own
## **4. Create your Continuity Checklist** 🤖 **Claude** Ask Claude to extract 5 to 8 specific, testable items from the summary. These are the things most likely to drift or be misunderstood. ``` From the summary above, extract 5 to 8 items for a Continuity Checklist. Each item should be: - Specific enough to test with a direct question - Something that could easily drift if misunderstood - Stated as a clear, verifiable claim Good example: "We defined a Steward as [exact definition] with the constraint that they cannot [specific limitation]." Bad example: "The project involves governance." (Too vague to test.) ``` Review the checklist. Remove anything too obvious. Add anything too critical to risk losing. ## **5. Open a fresh conversation** 👤 **You** Start a new conversation. If you're using a [Claude Project](https://support.claude.com/en/articles/9517075-what-are-projects), open the new conversation within the same project so that any project-level instructions or knowledge files remain available. This is one of the advantages of working inside a Project: your foundational context (instructions, reference documents, style guides, definitions) carries over automatically. The Master Summary only needs to cover what was built during the conversation itself, which means a leaner summary and a cleaner start.
What are Projects? Projects in Claude let you set persistent instructions and upload reference documents that stay available across all conversations within that project. If you haven't used Projects before, you don't need to start now. Just open a new conversation normally. But if your work would benefit from persistent instructions (for example, a style guide or a set of definitions that should always be in scope), consider setting up a Project for future sessions. You can learn more in [Claude's help documentation.](https://platform.claude.com/docs/en/home)
## **6. Seed the new conversation** 👤 **You** Paste your Master Summary as the first message. Frame it simply: ``` I'm continuing a project from a previous conversation. Below is a curated summary of everything we've established. Please read it carefully. I'll validate your understanding in the next message. [Paste your Master Summary here] ``` Two important rules: **Paste the curated summary, not raw chat history**\ Raw logs are full of wrong turns, tangents, and casual exchanges that waste context space and introduce noise. Your reviewed summary is the signal. It's the most important thing you carry forward. **One message, one document**\ Don't paste the summary, checklist, and supporting files all at once. Give Claude the summary first and let it process the full context before adding anything else. **Don't re-paste what the Project already knows**\ If you're working inside a Claude Project, resist the urge to re-include Project instructions, knowledge files, or reference documents alongside the summary. The new conversation already has access to all of that. Your summary should contain only what this conversation produced. Duplicating Project-level context wastes space in the context window and can actually create conflicts if the pasted version differs slightly from what's in the Project files. ## **7. Validate** 🤝 **Together** In your next message, paste the Continuity Checklist: ``` Here is a continuity checklist from our previous conversation. Please restate each item in your own words so I can confirm your understanding is accurate. [Paste your Continuity Checklist here] ``` Compare Claude's restatements against your original checklist: **Match**\ Claude's version aligns with yours. Move on to the next item. **Close but imprecise**\ Correct the specific point that drifted and ask Claude to confirm the correction. **Wrong**\ This usually means the summary is missing context rather than Claude misreading it. Add the missing information to the conversation and re-validate that item. All items must pass before you move on.
What if validation keeps failing? If more than two items fail validation, the summary likely has structural gaps rather than small wording issues. Go back to your original conversation (if it's still open) and identify what's missing. Add the missing context directly to the new conversation as a targeted correction. Then re-run the failing checklist items. If the original conversation is no longer available, state the corrections from your own memory and knowledge. You are always the authoritative source; the summary is just your tool.
## **8. Add supporting materials** 👤 **You** If you have essential supporting artifacts (a diagram, a key document, a schema, a code file), add them one at a time. After each one, run a quick targeted check: ``` Using the [diagram/document/file] I just shared, walk me through [specific process, relationship, or detail] so I can confirm you're reading it correctly. ``` {% hint style="info" %} #### **Working inside a Claude Project?** If you're working inside a Claude Project, check whether the artifact you're about to add is already uploaded as a Project knowledge file. If it is, you don't need to add it again. The new conversation can already access it. Only add artifacts that were created or modified during the conversation and aren't yet part of the Project. {% endhint %} Only add artifacts the new conversation will actively use in its first few exchanges. Everything else can be introduced later when it becomes relevant. ## **9. Resume your work** 🤝 **Together** Start with the "Next Step" from your Master Summary. This serves as a natural integration test. If Claude handles it well, your migration was successful. Welcome back. You didn't lose a thing.
Keeping a migration log **After each migration**, take 30 seconds to note the date, which version of the summary you used (v1, v2, and so on), and anything you had to correct during validation. This small habit pays off over time. You'll notice patterns in what tends to get lost and can adjust your summaries to preempt those gaps in future migrations.
## ❤︎ **You're Ready** Migration might seem like overhead the first time you do it, but most people find it becomes second nature after just one or two rounds. The process is simple: summarize, validate, continue. And the payoff is immediate. Instead of watching a productive conversation slowly lose its edge, you step into a fresh space with everything that matters intact and clearly organized. Over time, many users discover that regular migration actually improves their workflow. The act of summarizing forces you to take stock of where you are, what you've decided, and what still needs attention. It's a built-in moment of reflection that often reveals blind spots or forgotten questions. Your investment in long, thoughtful conversations with Claude is real work, and it deserves to be preserved with care. This guide gives you the tools to do that confidently. If you have questions about this process or want to share how it's working for you, we'd love to hear from you. You can reach us at or directly in the chat widget. > #### *A fresh conversation isn't starting over. It's turning the page, and everything important comes with you.* ## **⛯** **Toolkit** The steps above cover everything you need for a successful migration. This section is your reference shelf: shortcut methods for when time is tight, practical tips drawn from how experienced users approach migration, and a quick-reference table you can glance at without re-reading the full guide.
When Time is Short
Sometimes you won't have 15 minutes. Maybe context degraded faster than expected, or you notice problems in the middle of a task and need to move quickly. Here are two streamlined alternatives. ### **Rapid Migration** (5 to 10 minutes) Use this when you notice clear degradation and want to migrate before it gets worse. **1.** 🤖 Ask Claude for a compressed summary: ``` Context is getting long. I need a rapid migration summary of this conversation. If this conversation is inside a Claude Project, focus on what we established here, not what already lives in the Project's instructions or knowledge files. Produce a summary in under 1,500 words: 1. What we're working on (2 to 3 sentences) 2. Every definition and decision (exact wording) 3. Anything we produced (documents, frameworks, files) 4. What's unresolved 5. Priority next steps Mark anything you're uncertain about with [uncertain]. Skip examples and backstory. Just the essential facts. ``` **2.** 🤝 Scan for errors in definitions and decisions only. Don't try to perfect it. **3.** 👤 Open a new conversation, paste the summary, and ask Claude to restate the three most critical items as a quick validation. **4.** 🤝 Correct any errors and continue your work. ### **Emergency Snapshot** (2 to 3 Minutes) Use this when Claude is visibly struggling with context and you need to capture what you can right now. **1.** 🤖 Ask Claude immediately: 
I need an emergency snapshot of this conversation right now.
If this conversation is inside a Claude Project, only capture what
we established here, not Project-level context.

In under 500 words, list:
- Every definition we've established (exact wording)
- Every decision made and why
- Anything we produced (documents, files, frameworks)
- What we were working on and what comes next

Flag anything you're not confident about.
**2.** 👤 Copy the response right away. Do not try to refine it in the degraded conversation. **3.** 👤 Open a new conversation and paste the snapshot. Treat it as a starting point, not a validated source. Expect to rebuild some context through working conversation in the new session.
Tips for Better Migrations
Migrations work best when they're intentional. These tips will help you carry your best thinking forward and leave the noise behind. #### **Curate, don't dump** A clean, reviewed summary will always outperform raw chat logs. Your summary is the distilled version of your best thinking. Raw history includes every wrong turn and tangent, which wastes space and introduces noise. #### **Keep summaries lean** A summary needs to leave room in the context window for actual work. Three thousand words is a ceiling, not a target. Shorter is better when shorter is complete. #### **Always validate** Claude will restate things confidently even when subtle nuance has shifted. The checklist exists for exactly this reason. Don't skip it, even when the initial read-back sounds right. #### **Version your summaries** Use a simple naming convention like `MASTER_SUMMARY_v1.md`, `MASTER_SUMMARY_v2.md`, and so on. This lets you compare versions and roll back if a migration doesn't go well. The Master Summary prompt includes a Version field in its header for exactly this purpose. #### **Migrate proactively** If you know a project will span many conversations, plan a migration before you notice degradation. A planned migration is always smoother and more reliable than a reactive one. #### **You are the source of truth** Claude's summary is a tool to help you capture your thinking, not a replacement for your own knowledge. If something in the summary doesn't match your understanding, your understanding wins. Always.
Quick Reference
ApproachWhen to useTime neededWhat you produce
Full migrationYou have time and want complete fidelityAbout 15 minMaster Summary + Checklist + Validation
Rapid migrationDegradation is clear, limited time5 to 10 minCompressed summary + Quick validation
Emergency snapshotContext is failing now2 to 3 minRaw snapshot as a starting point
ArtifactSizeRequired?
Master SummaryUnder 3,000 words (full) / 1,500 (rapid) / 500 (emergency)Always
Continuity Checklist5 to 8 itemsFull migration only
Supporting artifacts1 to 3 documentsOnly if needed immediately
Frequently Asked Questions ### **How often should I migrate?** There is no fixed schedule. It depends on how dense your exchanges are. A conversation with 50 short, casual messages will hold up longer than one with 30 messages that each contain detailed instructions or lengthy outputs. As a general guideline, consider migrating every 30 to 50 substantive exchanges. If you're working on something complex, lean toward the lower end. If your conversation is light and exploratory, you can push further before migrating. ### **Can I prevent the need for migration entirely?** Not entirely, but you can extend the useful life of a conversation. Be concise in your messages. Ask Claude to be concise in its responses when you don't need elaboration. Avoid pasting large blocks of text you won't reference again. Front-load your most important context early in the conversation. If you're working on a recurring project, using a Claude Project lets you store foundational context (definitions, style guides, reference documents) outside the conversation, which frees up space in the context window for active work. And if you're working on a project that will clearly span many sessions, consider migrating proactively every 30 to 50 substantive exchanges rather than waiting for degradation. Think of it like saving your work: you do it not because something has gone wrong, but because it's good practice. ### **What if I forgot to migrate and my conversation is already degraded?** Use the Emergency Snapshot method in the Toolkit section above. Ask Claude to capture definitions, decisions, and the current next step in under 500 words. Copy the response, open a new conversation, and paste it as a starting point. You will likely need to fill in some gaps from memory, but even a partial snapshot is far better than starting from scratch. ### **Do I lose my old conversation after migrating?** No. Your previous conversation stays in your chat history. You can go back and read it at any time. Migration doesn't delete anything. It creates a fresh conversation with a clean context window while your original conversation remains accessible for reference. ### **Can Claude do the migration for me automatically?** Claude can generate the summary and checklist for you, which is the most time-consuming part. But the human steps (reviewing the summary for accuracy, opening a new conversation, pasting the materials, and confirming validation) need to be done by you. You are the quality control. Claude is very good at organizing information, but only you know whether the result is accurate and complete. ### **What if my project is too complex for a 3,000-word summary?** Prioritize rather than expand. Ask yourself: "What do I need in the first hour of the new conversation?" That is your summary. Everything else can live in project files, uploaded documents, or your own notes and be pulled in later as needed. A focused 2,000-word summary that captures the essentials will always outperform a sprawling 5,000-word summary that crowds out space for actual work. If your project genuinely has more critical context than 3,000 words can hold, consider splitting it across a Master Summary (for active work) and a reference document (uploaded to a Project for background access). ### **What about files and images I shared in the old conversation?** Files and images shared in a previous conversation are not automatically carried into a new one. If you shared documents, diagrams, code files, or images that the new conversation needs, you will need to upload them again. Files and images shared in a previous conversation are not automatically carried into a new one. [Step 8](#id-8.-add-supporting-materials) of the migration process covers this. Only re-upload materials that the new session will actively reference in its first few exchanges. Everything else can be added later when it becomes relevant. ### **Can I use the same Master Summary across multiple migrations?** Yes, and this is actually a good practice for long-running projects. After each migration, update the summary to reflect new decisions, revised definitions, and resolved questions. Save it as a new version (v2, v3, and so on). Over time, your Master Summary becomes a living project document that evolves with your work. Each migration is an opportunity to refine it. ### **What if Claude's restatement during validation sounds right but uses different words?** It depends on whether the wording matters. For general project context ("we're building a mobile app"), different phrasing is fine as long as the meaning is the same. For precise definitions, technical constraints, or specific decisions, exact wording often carries meaning that paraphrasing can lose. When in doubt, correct it. A small correction during validation takes seconds. Discovering a subtle misunderstanding three exchanges later costs much more. ### **Does this process work for all types of projects?** The summary template in [Step 2](#id-2.-generate-your-master-summary) is intentionally flexible, and the adaptation guidance below the prompt shows how to read the sections for creative writing, software development, and research projects. If your project type isn't covered, use the universal prompt and adjust sections as needed. ### **I'm a new Claude user. Should I worry about migration right away?** No. Migration is relevant only when you have a long, context-rich conversation that you want to continue with full precision. If your conversations are short or self-contained, you may never need to migrate. This guide is here for when you need it. Bookmark it and come back when a conversation starts to feel like it's losing track of things you established earlier. ### **How do I know if the migration actually worked?** The validation step ([Step 7](#id-7-validate)) is your confirmation. If Claude restates all checklist items accurately and handles the first real task from your "Next Step" with full context awareness, the migration was successful. If something feels off during those first few exchanges in the new conversation, it's usually a sign that a specific piece of context didn't make it into the summary. Add it directly and move on.
> *A fresh conversation isn't starting over. It's turning the page, and everything important comes with you.* --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://www.lumeon.dev/commons/context-migration-guide.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.