Agent skill · software engineering · mem0ai
mem0-oss-to-platform
Plan and then execute a migration of a project from the mem0 open-source / self-hosted SDK (the local `Memory` class) to the mem0 Platform / hosted / managed SDK (the `MemoryClient` class). Use this whenever a developer wants to move, switch, or migrate their mem0 usage off OSS/self-hosted to the hosted API — e.g. "migrate my mem0 setup to the platform", "switch from self-hosted mem0 to MemoryClient", "use my mem0 API key instead of a local Qdrant", "move mem0 to the cloud/hosted/managed service", or "replace my local mem0 vector store + embedder config with the platform". Applies to Python (`from mem0 import Memory` → `from mem0 import MemoryClient`) and TypeScript/JavaScript (`import { Memory } from "mem0ai/oss"` → `import MemoryClient from "mem0ai"`). Trigger even when the user doesn't say the word "migrate" but clearly wants their existing mem0 integration to run against the hosted platform. It first produces a reviewable migration plan, then executes it after the developer approves. Strictly scoped to the mem0 integration — it does not refactor, restructure, or "improve" any unrelated code.
Why this skill is useful
Adds a detailed migration script and plan for transitioning from the mem0 OSS SDK to the hosted mem0 Platform SDK, which includes specific code changes and configuration adjustments not found in public documentation.
What it needs
Requires mem0 installed locally. Requires mem0 account access. About 5k tokens when loaded. Last updated 2026-08-06. 62,725 stars on the source repository.
What this skill does
Migrate mem0 OSS → mem0 Platform (hosted) This skill migrates a project's memory layer from the self-hosted mem0 OSS SDK to the hosted mem0 Platform SDK, working for any project shape — an agent, a RAG pipeline, an API service, a chatbot, a background worker. You discover where mem0 is actually used, write a plan the developer reviews, and then execute it on approval. The mental model (read this first — it's why the migration is shaped the way it is) OSS mem0 means the developer runs the whole memory stack themselves: a vector store (Qdrant/pgvector/Chroma/…), an embedder, an LLM for fact extraction, and a local history DB. All of that is wired up in a config object passed to Memory. The Platform means mem0 runs that stack for them. The developer just holds an API key. So the migration is mostly subtraction: the local infrastructure config collapses into a single MemoryClient(apikey=...). The method calls stay recognizable (add/search/getall/…), but a few parameter conventions tighten up and the return values are server responses. So the core of every migration is: 1. Memory / Memory.fromconfig({...}) → MemoryClient() (reads the API key from the env). 2. Delete the local vectorstore / llm / embedder / graphstore / historydbpath config. 3. Fix up each call site to the hosted call convention (entity IDs into filters, pagination, etc.). 4. Flag everything that isn't a clean 1:1 so the developer can decide (see references/gotchas.md). Scope discipline: touch only mem0-related code, config, dependencies, and env. Preserve the project's existing behavior, structure, and style. Do not rename things, "tidy" nearby code, or change the app's logic. The developer asked to swap a backend, not to refactor their project. Workflow Work through these phases in order. Phases 1–4 produce the plan; phase 5 runs only after approval. Phase 0 — Prerequisite check The hosted SDK needs a mem0 API key (MEM0APIKEY, obtainable at https://app.mem0.ai). Confirm the developer has one. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills mem0ai/mem0-oss-to-platform