[Blog](https://supermemory.ai/blog) · [Learning](https://supermemory.ai/blog/tag/learning)

# Migrating from Mem0 to Supermemory: A Production Playbook

A production migration playbook for moving from Mem0 Platform to Supermemory: map identity boundaries, backfill memories, validate retrieval, cut over gradually, and keep rollback possible.

By Dhravya Shah July 11, 2026 · 10 min read 

![Move from Mem0 to Supermemory](https://supermemory.ai/_astro/cover.CPrmTM0H_CPoKs.webp)

Switching memory providers is not a package rename. The APIs may look similar, but the isolation model, memory lifecycle, retrieval scores, and ingestion behavior are different enough that a blind copy creates quiet data loss.

This guide covers **Mem0 Platform v3 to Supermemory**. If you self-host Mem0 Open Source, start by documenting the vector store, graph store, model providers, and persistence layers in your deployment. A managed-platform export cannot represent that whole system.

If you are still deciding whether to switch, read [why Scira moved from Mem0 to Supermemory](https://supermemory.ai/blog/why-scira-ai-switched) first. This article starts after that decision: how to move production data and traffic without making the migration irreversible.

## What changes in a Mem0 migration?

The central design change is identity. Mem0 can scope memories across `user_id`, `agent_id`, `app_id`, and `run_id`. Supermemory uses one `containerTag` as the isolation boundary, then metadata for additional filtering and provenance.

| Mem0 Platform                            | Supermemory                                                | Migration consequence                                              |
| ---------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------ |
| user\_id, agent\_id, app\_id, run\_id    | one containerTag plus metadata                             | define a deterministic namespace before importing                  |
| add messages or files to an entity scope | ingest raw content with containerTag and optional customId | preserve conversation identity and choose one update strategy      |
| extracted memory record                  | direct memory creation or raw document ingestion           | import existing facts directly; ingest new source content normally |
| query, entity filters, top\_k, and score | q, containerTag, search mode, limit, and similarity        | rewrite the adapter and retune thresholds                          |
| update or delete a memory                | versioned update or soft forget                            | decide how application lifecycle actions should translate          |

Do not start the backfill until that mapping is explicit. A migration script can move every record successfully and still break tenant isolation if the namespace is wrong.

## Is this guide right for your setup?

Proceed when every memory read and write can be mapped to a stable user, tenant, project, or agent boundary.

Pause for architecture work when:

* queries depend on several Mem0 entity dimensions at once
* the application expects to search across arbitrary tenants
* nested metadata drives authorization or retrieval behavior
* exact graph topology must be preserved
* deletes must be permanent at the moment the application requests them

Supermemory searches one `containerTag` at a time. That is useful isolation, but it means the tag must represent the boundary your authorization model already enforces. Graph edges and provider-specific ranking scores are not portable data formats.

## What should you inventory first?

Create a written inventory before touching production:

1. Record the Mem0 SDK and API versions in use.
2. Enumerate every user, agent, app, and run scope that owns memories.
3. Choose one canonical scope order for export and deduplicate globally by Mem0 memory ID before counting records.
4. Separate raw conversations and documents from already-extracted memory facts.
5. Inspect metadata for nested objects that will need flattening or serialization.
6. Capture a golden set of real queries, expected facts, current ranks, empty-result rate, error rate, and p50/p95 latency.

That last step gives the migration an acceptance test. Without a baseline, “the import completed” becomes a substitute for “the product still remembers correctly.”

Mem0's `get_all` endpoint requires at least one entity filter, returns paginated results, and accepts at most 200 records per page. Overlapping user, agent, app, and run queries can return the same memory more than once, so write each source ID to the snapshot once. Inspect the actual response fields from your deployed API version before mapping entity identifiers; do not assume a session field and a run field are interchangeable.

## How should Mem0 IDs map to container tags?

Choose a deterministic rule and use it everywhere. Common patterns include:

* `user:{user_id}` for a single-tenant consumer application
* `org:{org_id}:user:{user_id}` for user memory inside an enterprise tenant
* `agent:{agent_id}` for an agent-owned knowledge base
* `app:{app_id}:user:{user_id}` when the same person must remain isolated across products

Store dimensions that do not define access as flat metadata, such as `mem0_agent_id`, `mem0_app_id`, and `mem0_run_id`. Current v4 container tags allow up to 100 characters using letters, numbers, underscores, colons, and hyphens. If a source ID falls outside `^[a-zA-Z0-9_:-]+$`, encode or hash it without creating collisions, and persist the mapping. Never derive the tag differently in the importer and the live request path.

A `containerTag` scopes stored data and retrieval; it does not authenticate the caller. Derive it from the authenticated identity on the server, enforce access before each operation, and test cross-tenant requests before cutover.

## How do you export Mem0 without losing information?

For a canonical backfill, paginate Mem0's [memory-list endpoint](https://docs.mem0.ai/api-reference/memory/get-memories) using the scope order you chose, deduplicate globally by memory ID, and write the raw records to immutable JSONL. Expired memories are hidden by default; use `show_expired` when the migration needs those historical records. If Dream has merged memories, verify its `include_merged` option against the [Dream documentation](https://docs.mem0.ai/platform/features/dream) and reconcile counts before calling the snapshot complete. Preserve lifecycle state so importing a historical record does not accidentally reactivate it. Preserve:

* the memory text and source ID
* user, agent, app, and run identifiers
* categories and metadata
* creation, update, and expiration timestamps
* lifecycle state needed by the application

Mem0 also provides structured memory exports. Those exports are useful when you intentionally want to transform memories into a schema, such as a profile. They are not automatically a one-to-one database dump because the requested schema and export instructions can reshape the result.

If you use the export job, poll until it reports completion and download it promptly. Keep the raw source snapshot even after the new provider is live. It is the only reliable starting point for rollback or a corrected re-import.

## How should existing memories be imported?

Already-extracted facts should use Supermemory's [direct memory creation](https://supermemory.ai/docs/api-reference/content-management/create-memories-directly) endpoint. Raw conversations, files, and URLs should use the normal ingestion pipeline instead.

For every imported fact, send:

* the Mem0 `memory` value as content
* the mapped `containerTag`
* `source: mem0` in metadata
* the original Mem0 ID and entity IDs
* original timestamps and categories as flat or serialized metadata
* an expiration value only when the source policy requires it

Supermemory creates a new memory ID and timestamp. Maintain a migration ledger from `mem0_id` to the new ID, checkpoint each successful batch, and make retries skip completed source records. The direct-memory API does not promise that repeating the same request is idempotent.

The direct endpoint accepts batches of 1–100 memories, with each fact limited to 10,000 characters. Metadata values must use the documented scalar or string-array shapes, so flatten or serialize nested Mem0 metadata before sending it. Reject invalid records into a separate file rather than truncating them silently.

Importing extracted facts preserves their content for search. Evaluate graph relationships and profile behavior separately after import.

## How should the live write path change?

Use two write paths deliberately.

**For new conversations and source documents**, use Supermemory ingestion with a stable `customId`. Choose whether each update sends the complete conversation or only the delta, then keep that strategy consistent for the same ID.

**For exact application-owned facts**, use direct memory creation. That avoids sending a fact through document extraction when the application already knows what must be stored.

Document processing is asynchronous. A successful request means the work was accepted, not that every downstream memory is immediately available. With the default `dreaming: "dynamic"`, document status can be `done` while memory and profile formation is still batching. If the workflow requires memories as soon as processing completes, `dreaming: "instant"` provides that behavior for an additional operation; otherwise validate document search and memory search separately.

During migration, dual-write new production events to both providers. Keep one system authoritative for reads until the new path passes the full evaluation.

## How should the read path change?

The adapter needs more than renamed fields:

* Mem0 `query` becomes Supermemory `q`
* entity filters become `containerTag` plus metadata filters
* choose `memories`, `documents`, or `hybrid` search intentionally
* handle results that may represent a memory or a document chunk
* retune result limits and similarity thresholds

Do not compare Mem0 `score` directly with Supermemory `similarity`, and do not copy the same numeric cutoff. Each provider computes and calibrates relevance differently. Tune thresholds against the golden query set captured before migration.

For migration validation, score the retrieved context before the answer model sees it. A fluent model can hide a bad retrieval result by guessing convincingly.

## How do you validate before cutover?

Run both systems in parallel and grade the same production-shaped queries.

Measure:

* exact-fact recall and top-k relevance
* stale or contradictory memories
* empty results and unexpected extra results
* tenant isolation and metadata filters
* expiration behavior
* ingestion success and time-to-searchable
* application-observed latency and error rates
* duplicate source IDs after retries

Backfill a small group of containers first. Shadow reads without showing the new response to users. When acceptance criteria pass, move a low-risk cohort behind a feature flag and keep rollback to Mem0 available.

The [switching memory infrastructure](https://supermemory.ai/blog/switching-memory-infrastructure) guide covers the organizational side of this rollout. The technical rule is simpler: do not move all reads and writes on the same day.

## Which lifecycle differences need explicit handling?

| Operation     | Mem0                                            | Supermemory                                                                        | Decision required                                                            |
| ------------- | ----------------------------------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Update        | updates a memory record                         | creates a new memory version                                                       | decide whether history should be visible to the application                  |
| Remove memory | deletes the memory                              | soft-forgets the memory while retaining it for explicit forgotten-memory retrieval | do not treat forgetting as an erasure request                                |
| Delete source | source-specific removal                         | permanent document deletion                                                        | keep memory IDs and document IDs separate                                    |
| Expire        | remains visible through expiration\_date in UTC | forgets at the exact forgetAfter timestamp                                         | either map to next-day 00:00:00Z and test it, or refuse automatic conversion |

A Mem0 memory ID is not a Supermemory document ID. Keep resource types explicit in the migration ledger or deletion code will eventually target the wrong thing.

## What should the rollback plan contain?

A rollback plan needs four concrete assets:

1. the immutable source snapshot
2. the source-to-destination ID ledger
3. a reversible read and write feature flag
4. an append-only log of writes created after the snapshot

During dual-write, declare which provider is the source of truth. If you roll back, switch reads first, restore the original write path, then replay only the events recorded after the snapshot. Do not delete Mem0 data until the rollback window closes and the team has verified counts, retrieval quality, lifecycle behavior, and tenant isolation.

## What is the safest next step?

Migrate one representative tenant, not the easiest tenant and not the largest one. Import its facts, replay its real queries, test updates and forgetting, and measure the engineering work required to keep the system healthy.

Then make the decision from evidence. [Read the current Supermemory container-tag model](https://supermemory.ai/docs/concepts/container-tags), map your scopes, and keep the first cutover small enough to reverse.

## Frequently asked questions

### Can I migrate from Mem0 to Supermemory without downtime?

A dual-write and shadow-read rollout can avoid a planned outage, but no migration is automatically zero-downtime. Keep Mem0 serving reads while you backfill and validate Supermemory, then move a small cohort behind a reversible feature flag.

### How do Mem0 entity IDs map to Supermemory container tags?

Choose one deterministic container tag as the isolation boundary, such as `org:{org_id}:user:{user_id}`. Preserve other Mem0 dimensions such as `agent_id`, `app_id`, and `run_id` as flat metadata or encode them into the composite tag when they affect access.

### Will Supermemory preserve Mem0 memory IDs and timestamps?

Supermemory creates its own memory IDs and creation timestamps. Preserve the original Mem0 ID and timestamps as metadata and maintain a migration ledger that maps each source ID to its new Supermemory ID.

### Does this migration guide apply to Mem0 Open Source?

No. This guide covers the managed Mem0 Platform v3 APIs. Mem0 Open Source can use different vector stores, models, embedders, and persistence layers, so its export and migration plan must match the deployed stack.

## Other posts.

1. [We're open sourcing the company brain. Here's how we designed the multiplayer harness Company Brain is now open source. A walkthrough of the multiplayer harness behind its Slack experience, from proactivity and memory boundaries to approvals and recovery. NewsSep 25, 2026 ](https://supermemory.ai/blog/open-sourcing-company-brain)
2. [Jev changes a lot in memory & context engineering. Here's exactly how. We tested Jev across reranking, chunking, observation, and harness decisions. Here is where fast decision models help memory systems, where they cost more, and where they still fall short. EngineeringSep 24, 2026 ](https://supermemory.ai/blog/jev-memory-context-engineering)
3. [I reverse-engineered Instinct's memory. Here's exactly how it works Instinct keeps its memory as git-tracked markdown files, found with grep rather than vectors. Here is the whole system as far as black-box probing can reconstruct it, and how to rebuild it on supermemory in about 60 lines. EngineeringSep 20, 2026 ](https://supermemory.ai/blog/reverse-engineering-instinct-memory)
4. [An update to supermemory We've discontinued the supermemory company brain and Nova. Everyone who was charged has been refunded, our MCP and plugins continue to run, and we're going all in on the memory engine. NewsSep 10, 2026 ](https://supermemory.ai/blog/an-update-to-supermemory)
5. [Scaling Conversations: How Adapta Grew Usage Without Losing Context Adapta added Supermemory as a persistent memory layer so every conversation keeps its context — letting the team scale usage without losing the thread. Case StudyJun 12, 2026 ](https://supermemory.ai/blog/adapta-scaling-conversations)
6. [How Chatarmin Ditched RAG and Went Memory-Only with Supermemory Chatarmin replaced a heavy RAG pipeline with Supermemory's memory layer — cutting average AI response time from 40s to 12s and token usage by 40–50%. Case StudyJun 10, 2026 ](https://supermemory.ai/blog/chatarmin-memory-only)
7. [SMFS: making agentic retrieval 55% cheaper AND more accurate We launched SMFS.ai (Supermemory Filesystem) a few weeks ago, with a simple bet: We can redesign the filesystem specifically for agents, with special files, structures, and commands that it can use for it's tasks. Today, SMFS is used by hundreds of companies to power their agents. EngineeringMay 28, 2026 ](https://supermemory.ai/blog/smfs-making-agentic-retrieval-55-cheaper-and-more-accurate)
8. [Introducing Dynamic Dreaming: supermemory now connects the dots, for you. Dreaming is magical. TLDR: We're launching Dynamic Dreaming in supermemory today, which automatically works if you're using supermemory in any way - API, OpenClaw, Hermes agent, etc. EngineeringMay 25, 2026 ](https://supermemory.ai/blog/introducing-dynamic-dreaming-supermemory-now-connects-the-dots-for-you)
9. [Dear reader, we just made supermemory insanely cheap... the Context Cloud When I first started building supermemory, I had one goal: To build the best memory system for AI. I would talk to customers, and find out that memory was not the only thing they needed - They were all setting up 7-8 different vendors at the same time. EngineeringMay 18, 2026 ](https://supermemory.ai/blog/dear-reader-we-just-made-supermemory-insanely-cheap-the-context-cloud)
10. [Introducing @supermemory/tools v2.0.0 Today we're releasing v2.0.0\. This release unifies the API across all agents sdk integrations from AI SDK to Mastra, makes conversation identity a first-class concept, and ships with memory saving on by default. EngineeringApr 27, 2026 ](https://supermemory.ai/blog/introducing-supermemory-tools-v2-0-0)
11. [Solving the Precision-Recall Tradeoff: Search Result Aggregation When you're building memory for AI, search is your foundational layer. The way search generally works is straightforward: the user defines a query, and then sets a limit (top-K) on how many search results they want returned. Usually, this is set to 10 or 20. EngineeringApr 5, 2026 ](https://supermemory.ai/blog/solving-the-precision-recall-tradeoff-search-result-aggregation)
12. [OpenClaw Memory Problems: Why It Forgets and How to Fix It (2026) TLDR: Today, we are releasing a new version of our openclaw plugin - https://github.com/supermemoryai/openclaw-supermemory. This post is going to be a bit technical, so bear with me (or bookmark for later!) In this post, I will talk about what we do about OpenClaw memory, and how we fix it. EngineeringFeb 19, 2026 ](https://supermemory.ai/blog/why-everyone-is-complaining-about-openclaws-memory-it-sucks-and-why-supermemory-fixes-it)
13. [Stateful Coding Agents with Memory: Build Long-Running Agents (2026) We built a plugin for Claude Code and OpenCode that gives your coding agent persistent memory. It remembers your preferences, learns your codebase, and never loses context mid-conversation. The result is an agent you can run for months without starting over. EngineeringFeb 18, 2026 ](https://supermemory.ai/blog/infinitely-running-stateful-coding-agents)
14. [Clawd / Molt bot's memory SUCKS. We gave it supermemory. I'm the founder of supermemory. Clawd/Molt bot is blowing up right now, with many, many use cases. I set it up, too, and have been using it through telegram. TLDR: just go to https://supermemory.ai/docs/integrations/clawdbot to set up supermemory for your clawd bot. EngineeringJan 28, 2026 ](https://supermemory.ai/blog/clawd-molt-bots-memory-sucks-we-gave-it-supermemory)
15. [Catch up with our UNFORGETTABLE Launch Week Over the last year, one belief has guided almost everything we’ve built at Supermemory AI becomes meaningfully useful only when it remembers. Memory shouldn’t be something developers rebuild from scratch. It shouldn’t be fragile, expensive, or trapped inside a single tool. NewsJan 4, 2026 ](https://supermemory.ai/blog/catch-up-with-our-unforgettable-launch-week)
16. [Empowering the Next Generation of Founders: Supermemory Startup Program If there’s one thing we’ve learned while building Supermemory, it’s that most startups don’t fail because they didn't build features; they fail when infrastructure slows them down, or they built too slow. NewsDec 31, 2025 ](https://supermemory.ai/blog/empowering-the-next-generation-of-founders-supermemory-startup-program)
17. [Building code-chunk: AST Aware Code Chunking At Supermemory, we're building context engineering infrastructure for AI. A huge part of that is dealing with code: ingesting repos, understanding structure, and making it searchable. The problem is that most code chunking solutions are terrible. We built code-chunk to fix this. EngineeringDec 29, 2025 ](https://supermemory.ai/blog/building-code-chunk-ast-aware-code-chunking)
18. [Supermemory raises $3 million with the best memory engine for LLMs Today, I am excited to announce our first funding round to accelerate our mission of building an interoperable, scalable and reliable memory for LLMs and agents. Memory is one of the hardest challenges in AI right now. NewsOct 6, 2025 ](https://supermemory.ai/blog/supermemory-raises-3-million-and-building-the-best-memory-engine-for-llms)
19. [Mem0 vs Supermemory: Why Scira Switched Scira AI moved its production memory layer from Mem0 to Supermemory. This is what failed, what improved, and how the team evaluated the two systems. Case StudyOct 2, 2025 ](https://supermemory.ai/blog/why-scira-ai-switched)
20. [Never Record Again: How Montra Uses Supermemory to Rethink Video Creation Campbell Baron, the founder of Montra, has been making videos since he was twelve. By thirteen, he was already doing brand work. Today, he’s betting on a very different future for creators: a world where recording is the exception, and most videos are generated from scratch. Case StudyAug 21, 2025 ](https://supermemory.ai/blog/never-record-again-how-montra-uses-supermemory-to-rethink-video-creation)
21. [Unified Memory That Works Where You Work: Your Second Brain With Supermemory Hi everyone, I’m Dhravya, the founder of Supermemory. I want to start with a little story behind why this product means so much to me. You can also skip straight to what it is and how it works below. EngineeringJul 25, 2025 ](https://supermemory.ai/blog/unified-memory-that-works-where-you-work-your-second-brain-with-supermemory)
22. [Supermemory just got faster on PlanetScale What is Supermemory? Supermemory completes the missing part of the LLM puzzle: memory. Just as memory is crucial for human intelligence, it's essential for truly intelligent AI systems. EngineeringJul 18, 2025 ](https://supermemory.ai/blog/supermemory-just-got-faster-on-planetscale)
23. [Faster, smarter, reliable infinite chat: Supermemory IS context engineering. People are obsessed with prompts and prompt engineering. Sure, what you say is important, but what the model knows when you say it is the difference between a stateless text generator and an intelligent AI system. In short, context is the most crucial component. NewsJul 9, 2025 ](https://supermemory.ai/blog/faster-smarter-reliable-infinite-chat-supermemory-is-context-engineering)
24. [We solved AI API interoperability One API to rule them all, One spec to find them, One library to bring them all and in the TypeScript, bind them. When we were building the Infinite Chat API, initially, we only supported the OpenAI format. This was fine, until a lot of our customers started asking for more. EngineeringJul 7, 2025 ](https://supermemory.ai/blog/we-solved-ai-api-interoperability)
25. [The Wow Factor of Memory - How Flow Used Supermemory To Build Smarter, Stickier Products Overview: Flow is a note-taking app built around a bold vision: to create a more personal, context-aware writing experience powered by AI. At the heart of this mission is memory. Case StudyJun 14, 2025 ](https://supermemory.ai/blog/the-wow-factor-of-memory-how-flow-used-supermemory-to-build-smarter-stickier-products)
26. [The UX and technicalities of awesome MCPs Last month, we launched the Supermemory MCP, mostly to test our own infrastructure and get some initial traction. It blew up. To my absolute surprise, the initial launch itself got half a million impressions (!!!). Then, we launched and got #2 on ProductHunt too. EngineeringJun 8, 2025 ](https://supermemory.ai/blog/the-ux-and-technicalities-of-awesome-mcps)
27. [Architecting a memory engine inspired by the human brain Language is at the heart of intelligence, but what truly powers meaningful interaction is memory — the ability to accumulate, recall, and contextualize information over time. Large Language Models (LLMs) have mastered language, but memory remains their Achilles’ heel. EngineeringJun 5, 2025 ](https://supermemory.ai/blog/memory-engine)

## Start building with supermemory.

Memory and continual learning for any model, any harness. Available through our API, plugins, and MCP.

[Build with supermemory ](https://console.supermemory.ai/)