Migrating from Mem0 to MemorySync, step by step (with a dry run first)

Mohammed, founder of MemorySync, published a step-by-step guide for migrating agent memory from Mem0 to MemorySync, built around a dry-run-first workflow using memorysync-cli 1.6.1. The key difference is scoping: Mem0 passes user_id per call, while MemorySync sets the user once via an X-End-User-ID header, and the guide warns that a missing header "does not raise — it writes into the wrong scope." The CLI's dry run refuses any record lacking user_id, exiting with code 2 rather than guessing, and the real import maps Mem0 fields to tags and metadata while preserving original timestamps as metadata.mem0_created_at.

Disclosure: I'm Mohammed, founder of MemorySync, so read this as a vendor's page. I drafted it with AI assistance and checked every claim against each company's own docs as of Oct 25, 2026. Code status: on Oct 25, 2026 I ran the CLI dry runs in steps 2 and 3 and a real import step 4 with memorysync-cli 1.6.1 on small test exports against the live MemorySync API, plus the MemorySync calls in step 5 add, query, PATCH , forget . The Mem0 calls are quoted from Mem0's docs and were not run. This is the "how", not the "whether". If you're still deciding, start with Mem0 alternative: how to compare hosted agent memory https://memorysync.hashnode.dev/mem0-alternative-hosted-agent-memory . If you've decided to move, here's the order that keeps it reversible. In Mem0 you pass the user on each call: user id on add , and filters={"user id": ...} on search Mem0 quickstart https://docs.mem0.ai/platform/quickstart . In MemorySync the user is a request header, X-End-User-ID , set once on the client as end user id Authentication https://docs.memorysync.io/api/authentication?utm source=devto&utm medium=organic page&utm campaign=v5 oct25&utm content=pseo mem0-to-memorysync-migration . MemorySync's guide warns that a missing X-End-User-ID "does not raise — it writes into the wrong scope" Migrating from Mem0 https://docs.memorysync.io/getting-started/migrate/from-mem0?utm source=devto&utm medium=organic page&utm campaign=v5 oct25&utm content=pseo mem0-to-memorysync-migration . Set the header on every call. Every step below is built around getting that mapping right. Use the Mem0 dashboard export or the export API. Per MemorySync's guide, the export holds records with id , content , metadata and created at . Make sure user id is included on every record see step 3 . Reports what would be written, per user. Writes nothing. npx memorysync-cli migrate mem0 --file mem0 export.json --dry-run When I ran this on a sample export where every record had a user id , it printed the record count, the number of end users, the number of requests at 50 records per request , and a "Would write" count per user. It wrote nothing. When I ran it on an export with one record missing user id , the dry run stopped with exit code 2, named the record, said "Nothing was written", and suggested a re-export that includes user id . That's documented behaviour: the CLI refuses any record whose user can't be determined, rather than guessing. Re-export from Mem0 with user id on every record, then run the dry run again. Once the dry run looks right, drop --dry-run and follow the migration guide https://docs.memorysync.io/getting-started/migrate/from-mem0?utm source=devto&utm medium=organic page&utm campaign=v5 oct25&utm content=pseo mem0-to-memorysync-migration . Per the guide, the CLI: user id and writes each group under that end-user scope; client ref , so re-running reports records that already landed instead of storing them again; categories to tags and keeps id , created at , agent id , app id and run id in metadata; The original timestamp is kept as metadata.mem0 created at . MemorySync assigns its own created at , so sort on the metadata field if original order matters. These rows appear in both vendors' current docs: | Mem0 Mem0 docs | MemorySync MemorySync docs | |---|---| | client.add messages, user id="alice" | POST /memory/add with text ; SDK client.add "..." on a client created with end user id="alice" | | client.search query, filters={"user id": "alice"}, top k=5 | POST /memory/query with query and k 1 to 50, default 5 ; scope from the header | | client.update memory id, ... PUT /v1/memories/{memory id}/ | PATCH /memory/{memory id} with tags , importance , metadata , source or event type | | client.delete memory id DELETE /v1/memories/{memory id}/ | DELETE /memory/forget with a memory ids list | Two differences to plan for. Mem0's update edits content, metadata, timestamp or expiration date. MemorySync's PATCH doesn't list the memory text as an editable field. And MemorySync memory ids are integers, so keep the Mem0 id in metadata the CLI does this rather than reusing it as an id. python From docs.memorysync.io run against the live API on Oct 25, 2026 import os from memorysync import MemorySyncClient client = MemorySyncClient api key=os.environ "MEMORYSYNC API KEY" , base url="https://api.memorysync.io", project id=os.environ.get "MEMORYSYNC PROJECT ID" or None, end user id="alice", client.add "User prefers dark mode" hits = client.query "user preferences", k=5 Run your own real queries against both and compare the results before you cut over. Keep the Mem0 export through a full usage cycle. MemorySync's guide calls it "the cheapest rollback available". Can I re-run the import if it stops halfway? Per MemorySync's guide, yes. Each Mem0 id is sent as client ref , and records that already landed are reported as already migrated. In my live test import, the second run printed "Migrated 0 of 2 record s " and "2 already migrated on an earlier run". The originals carried mem0 id and mem0 created at in metadata. Will Mem0's agent id and run id still be there? Per the guide, they're kept in metadata. They don't become MemorySync scopes. Scope is project plus end user. Do I have to change every call site? Yes. User scope moves from call arguments to the client, and top k becomes k . Want to see the write-then-recall loop before you migrate anything? The browser playground needs no signup: try MemorySync https://memorysync.io/try?utm source=devto&utm medium=organic page&utm campaign=v5 oct25&utm content=pseo mem0-to-memorysync-migration .