Moving ChatGPT Context to Claude: A 14-Check Handoff That Preserves What Matters
If you are moving from ChatGPT to Claude, do not treat “migration” as one export button. Decide which layer you are moving: durable preferences, a project’s working state, source files, or the complete conversation archive. Claude has an official memory-import flow, but Anthropic calls it experimental and warns that it may not incorporate every memory. It is a context transfer, not a promise that every chat, attachment, project boundary, or behavior will be recreated. Anthropic’s current memory-import guide explains the feature and its limits.
For a practical comparison of the products, see Trust‑Vault’s ChatGPT and Claude guide. This article answers a narrower operational question: what should you carry over, how do you check that the new assistant understood it, and what should stay behind?
The recommended path is selective. Export or ask for only the context you need, review it locally, split standing preferences from project-specific facts, remove secrets and unnecessary personal details, then import a small handoff and test it with questions whose answers you already know. Keep the original export untouched until those tests pass. For work involving other people’s personal information, treat the transfer as a new disclosure. UK government guidance says organizations handling personal information must keep it secure, accurate and current, explain how it is used and shared, and respond to applicable requests. The page is UK-specific and does not settle every jurisdiction or role. GOV.UK data-protection overview.
The reader decision
Use Claude’s memory import when you want selected durable context such as response preferences, recurring work, tools, and corrections. Use a Claude Project when a set of files and instructions belongs to one continuing workstream. Keep a local archive when you need to preserve the original conversation record or need a recovery source. If you only need one answer from an old thread, a concise, reviewed brief is usually easier to check than moving the whole history.
Do not decide based on the word “import.” Decide based on the object you want at the destination. A memory item, project instruction, source document, chat transcript, and attachment are different objects with different recovery and privacy properties. A successful memory import does not prove that a particular answer, file, project permission, or prior conversation is available in a new chat.
What the official flow does
Anthropic describes a three-step flow: ask the existing assistant for a memory export, open Claude’s memory import, paste the result, then review what Claude learned. The suggested extraction prompt requests instructions, personal details, projects, goals, tools, languages, preferences, and corrections. Anthropic says users can customize that prompt to exclude sensitive information and says its memory is designed to focus on work-related topics. It also warns the import is experimental and may not incorporate every memory. Those qualifications matter more than a “switch in minutes” tutorial. Read Anthropic’s instructions.
Projects solve a different problem. Anthropic describes project knowledge as material uploaded for use across chats in that project, with project instructions applied to that project. It notes that context is not shared across chats unless it is added to the project knowledge base. Plan availability and product behavior can change, so check the current documentation and your account before building a workflow around a plan-specific feature. Claude Projects documentation.
The distinction is practical: memory is for selected information that should recur across work; project knowledge is for material belonging to one workspace; the archive is the record you retain independently. If you flatten all three into one large prompt, you lose the distinction between a durable preference, an obsolete task instruction, and an original source document.
Why portability is a real user problem
The unresolved question in public discussions is often not “where is the import button?” It is “does this bring my actual history, projects, or files, or only a summary?” In an Anthropic GitHub issue, a user asks for export of one conversation’s context and memory to continue work in another platform. The thread also raises questions about project-specific context and whether a memory summary reproduces history. These are individual reports, not a survey and not proof that every user sees the same failure. They are useful because they identify what a handoff checklist must test: can the destination retrieve the particular decision, source, and open task that matter? Conversation-specific export request.
A consulting perspective points to the same structural risk at a larger scale. Oliver Wyman’s September 2026 discussion of agentic-AI dependencies names operating model, context, data, memory, harness, and infrastructure as possible sources of vendor lock-in, and argues that organizations should plan reversibility and removal. That piece concerns enterprise agents, not a consumer’s ChatGPT-to-Claude import. Its useful inference here is narrower: the more valuable context exists only inside one provider’s managed memory, the harder it is to prove what will survive a switch. Oliver Wyman’s analysis.
Inventory four layers before export
Put each candidate item in one primary layer. Cross-reference if necessary, but do not silently duplicate the same information everywhere.
| Layer | Examples | Destination | Keep a source copy? | Main failure if mixed up |
|---|---|---|---|---|
| Standing memory | Tone, preferred units, recurring role, explicit corrections | Claude memory | Yes, in a reviewed local file | Temporary instructions become permanent |
| Project state | Goal, decisions, open questions, next step, owners | Project instructions or brief | Yes, with a version date | Stale status is treated as current |
| Reference material | Approved documents, code, datasets, policies | Project knowledge, if permitted | Yes, with source and access controls | A summary replaces the source |
| Conversation archive | Original prompts, replies, dates, attachments | Local approved archive | The archive is the source copy | A summary is mistaken for a complete record |
Write down why each item is moving. “It might be useful someday” is not enough to transfer contact information, a private chat, draft credentials, customer records, or old legal instructions. If an item has no clear next use, leave it out. If a source document is authoritative, transfer the document only when the destination and project access are approved; do not substitute a model-generated paraphrase.
The 14-check handoff protocol
This is a reusable acceptance protocol, not a measured product benchmark. The fourteen checks were designed on 15 November 2026 as synthetic review cases. No real conversations, customer data, Claude account, ChatGPT export, model output, or migration rate was tested. The sample is exactly fourteen designed scenarios; it excludes organization-specific retention rules, legal review, and feature behavior not visible in the official pages reviewed. Passing means the handoff file is internally complete and your own spot checks succeeded. It does not prove a provider imported everything.
| # | Check | Pass condition | Stop or repair when |
|---|---|---|---|
| 1 | Purpose | Each item supports a named future task | The reason is “just in case” |
| 2 | Layer | Memory, project state, source, or archive is labeled | One paragraph mixes all four |
| 3 | Provenance | A date and source conversation or file are recorded | A claim sounds certain but has no source |
| 4 | Status | Current, superseded, uncertain, or expired is explicit | Old work is presented as current |
| 5 | Preference scope | Standing preference is separate from one-task instruction | “For this answer” becomes “always” |
| 6 | Decision fidelity | Decision and reason are both preserved | Its condition is lost |
| 7 | Open loop | Question, owner, and next action are recorded | A completion state is invented |
| 8 | Source pointer | Factual claims point to an original | A summary is the only evidence |
| 9 | Minimization | Unneeded identifiers and personal details are removed | Unrelated people remain in the export |
| 10 | Secret scan | Tokens, passwords, recovery codes, and keys are absent | Any credential-like value remains |
| 11 | Project boundary | Each file is assigned to one destination project | A file from Project A enters Project B |
| 12 | Import receipt | Version, time, and destination are recorded | Nobody knows which version was imported |
| 13 | Retrieval test | Known facts return with the right scope | It answers from another project or stale note |
| 14 | Recovery | Original export and rollback path remain | The transformed memory is the only copy |
The checks concern the handoff, not the model’s confidence. A plausible answer can still be wrong if the source was omitted, a date disappeared, a decision was reversed, or an old fact is retrieved outside its original scope. For checks 3, 4, 6, 7, and 8, ask for the evidence pointer and compare it with your source copy. Do not accept “Claude seems to remember” as proof.
Build a minimal handoff packet
Create a small, versioned file before opening the import screen. A useful packet has a header, durable preferences, one project brief per active project, a source index, an exclusion note, and an import receipt. Keep each section short enough to review line by line. The packet’s value is not its size; it is that each sentence has a destination and a status.
A standing preference should read like a reusable rule: “Use metric units unless I request otherwise.” A project fact should be scoped: “For Project North, the approved staging deadline is 12 December 2026; source: release-plan.md, last confirmed 10 November.” A one-time instruction should not become a standing memory. A hypothesis should be labeled as a hypothesis. If the date is unknown, write “date unknown” rather than silently assigning today’s date.
A decision record should preserve the decision, options considered, reason, date, and what would reopen it. “We chose vendor B” is weaker than “On 10 November, we chose vendor B for the pilot because it supports a local test environment; revisit if export terms or data-processing terms change.” This prevents the next assistant from treating a conditional choice as an eternal preference.
An open-loop record should say what remains, who owns it, and the next safe action. Separate a task waiting on a person from a task the assistant may perform. Do not transfer old “send,” “delete,” “approve,” or “publish” commands as if they were still authorized. If an action was completed, record the evidence and date. If you cannot verify completion, mark it unresolved.
Keep original source files outside model memory where possible. In the brief, use a stable filename, repository path, document identifier, or approved link. Do not assume the new assistant can access the old provider’s attachments. Anthropic describes files added to Claude project knowledge as context for chats in that project; its documentation does not say files from another provider appear automatically. Upload only materials you are allowed to share.
Privacy and minimization
An export is not automatically safe to upload because it came from your own account. Conversations can contain customer names, health details, employment matters, unreleased plans, credentials pasted during debugging, or information about people who never chose to use either service. Review the material before transfer. Remove content that is not needed for the destination task, and retain the original separately under approved controls.
GOV.UK says organizations handling personal information must keep it secure, accurate, and current; explain how it is used and shared; and respond to applicable data requests. That page is a UK overview, not a decision on whether a particular transfer is lawful in every situation. Check jurisdiction, controller and processor roles, contract terms, workplace policies, and retention requirements before moving other people’s records. GOV.UK guidance.
Apply minimization to the handoff itself. Replace a person’s name with a role when identity is unnecessary. Replace a real account identifier with a fictional placeholder in examples. Keep any mapping outside the assistant if the actual identifier is needed later. Exclude passwords, API keys, access tokens, recovery codes, and authentication cookies entirely. A marker such as “[credential removed]” is more useful than copying a secret and hoping the receiving assistant ignores it.
There is a trade-off: over-redaction can remove a fact needed to continue correctly. If an instruction depends on a region, role, deadline, or permission boundary, preserve that attribute in the least identifying form that still supports the task. “A Swiss customer record” may be enough where a name and address are not. “Manager approval required” may be enough where an employee’s identity is irrelevant. This is a review recommendation, not a legal conclusion.
Import in two passes
First, import only standing preferences and verified durable facts. Review the resulting memory panel in the interface currently shown in your Claude account. Anthropic notes that some Team and Enterprise organizations may still use a legacy experience, so menu labels can differ. Its help page describes reviewing or editing memory and asking what Claude learned. Use those steps to confirm what was retained rather than relying on a success message.
Second, create or update a Project for each active workstream. Add instructions describing scope, source hierarchy, output format, and boundaries. Add source files only after confirming they are permitted and belong in that workspace. Put decisions and open questions in the project brief, not global memory. This keeps a client fact from one project from appearing as a general fact in an unrelated chat.
Do not paste a full transcript into global memory just because an extraction prompt asks for “all context.” Anthropic explicitly lets users customize its prompt to exclude sensitive content. Separate a useful preference from unrelated conversation history at that point. The feature is experimental; verify each valuable item and preserve the original export as the recovery record.
A small executable preflight
The following Node.js script checks a deliberately small JSON schema. It rejects missing provenance, unclear status, duplicate IDs, common credential patterns, and personal-data markers requiring human review. It does not identify every secret, prove a lawful basis, or verify what Claude imported. Treat it as a preflight aid, not an upload approval. Save the JSON as handoff.json, this code as check-handoff.mjs, and run node check-handoff.mjs handoff.json.
import fs from 'node:fs'; const file = process.argv[2] ?? 'handoff.json'; const data = JSON.parse(fs.readFileSync(file, 'utf8')); const errors = []; const layers = new Set(['memory', 'project', 'source', 'archive']); const statuses = new Set(['current', 'superseded', 'uncertain', 'expired']); const seen = new Set(); const secret = /(api[_-]?key|access[_-]?token|password|secret|recovery[_-]?code)\s*[:=]\s*\S+/i; const personal = /\b(?:ssn|passport|medical record|date of birth|home address)\b/i; if (!Array.isArray(data.items)) errors.push('items must be an array'); for (const [i, item] of (data.items ?? []).entries()) { const at = `items[${i}]`; if (!item.id || seen.has(item.id)) errors.push(`${at}: missing or duplicate id`); seen.add(item.id); if (!layers.has(item.layer)) errors.push(`${at}: invalid layer`); if (!statuses.has(item.status)) errors.push(`${at}: invalid status`); if (!item.purpose?.trim()) errors.push(`${at}: purpose required`); if (!item.source?.trim()) errors.push(`${at}: provenance required`); if (!item.reviewedAt || Number.isNaN(Date.parse(item.reviewedAt))) errors.push(`${at}: reviewedAt must be a date`); const text = JSON.stringify(item); if (secret.test(text)) errors.push(`${at}: possible credential; inspect manually`); if (personal.test(text)) errors.push(`${at}: possible personal data; verify necessity`); } if (errors.length) { console.error(errors.join('\n')); process.exitCode = 1; } else console.log(`Schema checks passed for ${data.items.length} items. Human review and retrieval tests are still required.`); This script checks structure, not truth. A source field can name a fabricated file; a date can be valid but wrong; a secret can use an unrecognized format; and sensitive information can appear without one of the listed words. Its output therefore never says “safe to upload.” It says only that basic schema checks found no listed problem. Keep a copy of the tool with a version number so a later reviewer knows which checks ran.
A sample item might look like this:
{ "id": "decision-2026-11-10-vendor-pilot", "layer": "project", "status": "current", "purpose": "Continue the vendor pilot without reopening the completed selection decision", "content": "Vendor B was selected for the pilot on 10 November because it supports a local test environment. Reopen if export or data-processing terms change.", "source": "release-plan.md, section 4; confirmed by project owner on 2026-11-10", "reviewedAt": "2026-11-15" } Do not put a whole project brief into every item. One record should have one purpose, layer, traceable source, and current status. If a fact changes, supersede the old item rather than editing the only copy. A small change history lets you understand why two assistants may answer differently after the switch.
Test retrieval with answers you already know
After import, use prompts that reveal specific failure modes. Do not test only with “What do you know about me?” That rewards a polished summary and can hide missing scope, dates, or uncertainty. Prepare an expected-answer sheet from the original packet before import. Use only facts you are permitted to place in the destination system.
Include one standing preference; one current project goal; one superseded decision; one open question and next step; one source citation; one excluded private fact; one item whose date is unknown; and one request to distinguish fact from inference. Ask a new, unrelated chat whether a project-only item applies globally. It should say the scope is limited or ask which project you mean.
Score four things separately: retrieval, scope, provenance, and uncertainty. Retrieval asks whether the expected item appeared. Scope asks whether it was applied only where intended. Provenance asks whether the assistant named a source or admitted it did not know. Uncertainty asks whether an unknown or superseded detail stayed that way. A correct-sounding answer without an evidence pointer is not a pass for a consequential fact.
Run a negative test. Ask for an excluded secret or detail intentionally not imported. Expected behavior is “I do not have that information,” not a guess. Ask a second question that conflicts with a stale project note and confirm the current note wins because its date and status are explicit. These checks test your packet and configuration, not an abstract model capability ranking.
Research evidence, disagreement, and limits
A paper record on Pith describes a controlled preprint comparing four ways of storing the same synthetic histories: raw long context, retrieval chunks, model-written notes, and a fixed-schema representation. It reports that performance varied by memory format and migration direction. The record’s own limitations are narrow: two open-weight models below ten billion parameters, synthetic histories, and one embedding pair. Pith labels its review T0 and says an AI wrote it; no human expert had reviewed the paper at the time shown. This is an engineering warning that representation can matter, not evidence that a ChatGPT-to-Claude import loses a particular percentage. The paper record and its stated scope.
The research and product documentation answer different questions. Anthropic documents a consumer memory-import flow and warns it may not incorporate every memory. The controlled study examines model and memory-format swaps, not Claude’s import screen, proprietary provider exports, or consumer project files. The study cannot predict what Claude will retain from your paste. Its limited practical lesson is to test the destination and keep a source copy rather than assuming one compact summary is a lossless backup.
Oliver Wyman’s discussion is enterprise consulting advice, not a neutral consumer product comparison or measurement of every assistant. The UK government page describes organization duties in its jurisdiction; it does not tell every user what an AI provider retains. Anthropic’s own help page is the strongest source for Claude’s feature. The research and consulting material frame the risks around it. Do not combine them into a claim that all assistants behave the same way.
A relevant tutorial surfaced in search: “Migrate from ChatGPT to Claude: How To Transfer & Import Memory, Chat History and Context”. Its transcript fetch was blocked by YouTube’s bot check, so I inspected the title and search description only and did not use the video to support a migration step. The official feature documentation is the source for the instructions above. If you watch a tutorial yourself, cross-check menu names and plan details against current official help; a title, thumbnail, or description does not prove a feature still works or that all data transfers.
Failure modes and repairs
Everything becomes “memory.” A prior task instruction is saved as a standing preference. Separate preference from project instruction, restore the original scope, then test an unrelated chat.
A summary drops a condition. “We chose vendor B” loses “for a pilot only.” Restore the date, reason, limit, and reopening trigger. Compare with the original source, not another generated summary.
A project boundary disappears. A client fact appears in another workstream. Separate project workspaces, clarify instructions, and test an out-of-project question. If the feature cannot enforce the needed boundary, do not upload the sensitive file there.
An old date appears current. The export has a fact but no status. Add a date and status: current, superseded, uncertain, or expired. Leave unknown dates unknown.
The import accepts text but drops a key item. A success message is not a retrieval audit. Import the missing item explicitly, verify it from a fresh conversation, and keep the export and import receipt.
A summary replaces the source. The destination repeats a statement but cannot show where it came from. Retain the original in an approved repository and point the project record to its filename or section. For a consequential claim, ask for the source before acting.
Sensitive content moves because it was in the archive. Remove unnecessary personal information and credentials before another import, check applicable work rules, and use the provider’s controls to manage imported memory. Follow the organization’s incident process if there was an unauthorized disclosure.
The test is biased toward success. All prompts ask for easy facts. Add a negative test, superseded item, unknown date, conflict, and scope challenge. Include a prompt whose correct answer is “I do not have that information.”
The old assistant continues to change the source. Two versions compete. Name the canonical source outside either assistant, record the import time, and repeat the transfer after material changes. A memory feature is not a synchronization protocol.
Worked example: one active project
Suppose a product team used one assistant for requirements, meeting notes, and release planning. Its archive contains approved decisions, brainstorming, draft feedback, pasted logs, and temporary instructions. Copying all of it into global memory makes scope and retention hard to inspect. A safer handoff keeps the archive in the approved record system, creates a project brief for the active release, and imports only durable preferences that apply across work.
The brief includes the release goal; current milestone and date; decisions that remain current; superseded decisions with dates; source documents and owners; open questions; and the next action that is safe without approval. Each item points to a source file or meeting record. If the assistant may draft but not publish, write that boundary in project instructions and test it with a request to publish.
Do not include raw customer transcripts by default. First decide whether the destination service and project are approved for that data. If a synthetic example validates the workflow, use it instead. If real customer material is essential, minimize it, record purpose and access, and preserve retention rules. This is a practical application of secure and purpose-limited handling, not a substitute for a privacy review.
After import, ask the new assistant to state the goal, quote the current milestone and source, identify a superseded decision, list open questions, and describe what requires human approval. Compare answers with the source files. If it invents a date, merges old decisions, or treats a draft as approved, stop and repair the packet before consequential work continues.
Decision table
| Situation | Route | Why | Required check |
|---|---|---|---|
| Stable response preferences | Memory import | Designed for selected memory | Review the result and test one preference |
| One continuing workstream | Claude Project | Instructions and files can be scoped | Confirm access, plan, and behavior |
| Need original conversation evidence | Separate archive | Summary is not a transcript | Inspect files and retain approved original |
| One fact from one old thread | Cited brief | Avoids unrelated context | Compare it with the original thread |
| Sensitive records | Pause for approval and minimization | Transfer creates a new destination and access path | Confirm policy and responsible review |
| Unknown or outdated memories | Exclude or label uncertain | Import can make stale facts seem current | Add date, status, and source |
The recommendation fails if the destination cannot meet confidentiality, access, retention, or retrieval requirements. It also fails if context should be global or if an organization has a governed knowledge system that must remain the source of truth. In those cases, map the actual system and permissions first; do not force the four-layer model.
Migration flow
flowchart TD A[Name the next task] --> B[Inventory memory, project, source, archive] B --> C[Remove unnecessary sensitive data and secrets] C --> D[Record dates, status, sources, and exclusions] D --> E{Is the destination approved?} E -- No --> F[Stop and ask the responsible owner] E -- Yes --> G[Import a small memory packet] G --> H[Create or update a scoped project] H --> I[Run positive, negative, scope, and provenance tests] I --> J{Known answers and boundaries pass?} J -- No --> K[Repair packet; keep source archive] K --> G J -- Yes --> L[Record receipt and retain rollback copy] Checklist before closing the old workflow
- I named the purpose and destination of each transferred item.
- I separated global preferences, project state, files, and archive.
- I removed credentials and unrelated personal information.
- I dated decisions and labeled current, superseded, uncertain, or expired.
- I retained the original export and recorded the imported version.
- I checked current official documentation for plan and interface differences.
- I tested known facts, scope boundaries, a conflict, and an intentionally absent fact.
- I verified consequential answers against their original sources.
- I know where future edits will be made and how another transfer would work.
Decision
Claude’s memory import can reduce the friction of moving selected context, but treat it as a reviewed import, not a lossless migration. Use memory for durable preferences, Projects for scoped work, and an independent archive for original conversations. Keep source pointers, minimize what you transfer, test retrieval and scope, and retain a rollback copy. Anthropic says its import is experimental; Oliver Wyman describes enterprise memory dependency; the controlled preprint record shows that format and direction can matter in a narrow synthetic study. Together they support an acceptance test, not a guarantee that any provider will preserve your history.
Research note and original asset method
Research checked 15 November 2026. In the GSC sample for 19 October–14 November, individual queries such as “askgpt vs claude,” “claudeai vs. chatgpt,” and “what is claude better at than chatgpt” appeared with one impression each in positions 9–24. These are weak intent clues, not proof of demand or a ranking forecast. The Trust‑Vault comparison page had 53 impressions and an average position of 16.8 in the earlier 23–30 October sample. Those date ranges and aggregations differ and must not be added as one dataset.
The original asset is the fourteen-check protocol, its synthetic matrix, and the JSON preflight script. Method: manual design from official feature boundaries, one observed feature request, a narrowly scoped controlled study, and an enterprise dependency discussion. Sample: fourteen designed cases. Date: 15 November 2026. Exclusions: no live account, export, product output, or migration accuracy was tested; the cases are not representative of all users. The number fourteen counts protocol cases only. It is not a statistic about real migrations.


