--- summary: "Move from Hermes to OpenClaw with a previewed, reversible import" read_when: - You are coming from Hermes and want to keep your model config, prompts, memory, and skills - You want to know what OpenClaw imports automatically and what stays archive-only - You need a clean, scripted migration path (CI, fresh laptop, automation) title: "Migrating from Hermes" --- OpenClaw imports Hermes state through a bundled migration provider. The provider previews everything before changing state, redacts secrets in plans and reports, and creates a verified backup before apply. Imports require a fresh OpenClaw setup. If you already have local OpenClaw state, reset config, credentials, sessions, and the workspace first, or use `openclaw migrate` directly with `--overwrite` after reviewing the plan. ## Two ways to import The fastest path. The wizard detects Hermes at `~/.hermes` and shows a preview before applying. ```bash openclaw onboard --flow import ``` Or point at a specific source: ```bash openclaw onboard --import-from hermes --import-source ~/.hermes ``` Use `openclaw migrate` for scripted or repeatable runs. See [`openclaw migrate`](/cli/migrate) for the full reference. ```bash openclaw migrate hermes --dry-run # preview only openclaw migrate apply hermes --yes # apply with confirmation skipped ``` Add `--from ` when Hermes lives outside `~/.hermes`. ## What gets imported - Default model selection from Hermes `config.yaml`. - Configured model providers and custom OpenAI-compatible endpoints from `providers` and `custom_providers`. MCP server definitions from `mcp_servers` or `mcp.servers`. - `SOUL.md` and `AGENTS.md` are copied into the OpenClaw agent workspace. - `memories/MEMORY.md` and `memories/USER.md` are **appended** to the matching OpenClaw memory files instead of overwriting them. Memory config defaults for OpenClaw file memory. External memory providers such as Honcho are recorded as archive or manual-review items so you can move them deliberately. Skills with a `SKILL.md` file under `skills//` are copied, along with per-skill config values from `skills.config`. Set `--include-secrets` to import supported `.env` keys: `OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, `OPENROUTER_API_KEY`, `GOOGLE_API_KEY`, `GEMINI_API_KEY`, `GROQ_API_KEY`, `XAI_API_KEY`, `MISTRAL_API_KEY`, `DEEPSEEK_API_KEY`. Without the flag, secrets are never copied. ## What stays archive-only The provider copies these into the migration report directory for manual review, but does **not** load them into live OpenClaw config or credentials: - `plugins/` - `sessions/` - `logs/` - `cron/` - `mcp-tokens/` - `auth.json` - `state.db` OpenClaw refuses to execute or trust this state automatically because the formats and trust assumptions can drift between systems. Move what you need by hand after reviewing the archive. ## Recommended flow ```bash openclaw migrate hermes --dry-run ``` The plan lists everything that will change, including conflicts, skipped items, and any sensitive items. Plan output redacts nested secret-looking keys. ```bash openclaw migrate apply hermes --yes ``` OpenClaw creates and verifies a backup before applying. If you need API keys imported, add `--include-secrets`. ```bash openclaw doctor ``` [Doctor](/gateway/doctor) reapplies any pending config migrations and checks for issues introduced during the import. ```bash openclaw gateway restart openclaw status ``` Confirm the gateway is healthy and your imported model, memory, and skills are loaded. ## Conflict handling Apply refuses to continue when the plan reports conflicts (a file or config value already exists at the target). Rerun with `--overwrite` only when replacing the existing target is intentional. Providers may still write item-level backups for overwritten files in the migration report directory. For a fresh OpenClaw install, conflicts are unusual. They typically appear when you re-run the import on a setup that already has user edits. If a conflict surfaces mid-apply (for example, an unexpected race on a config file), Hermes marks remaining dependent config items as `skipped` with reason `blocked by earlier apply conflict` instead of writing them partially. The migration report records each blocked item so you can resolve the original conflict and rerun the import. ## Secrets Secrets are never imported by default. - Run `openclaw migrate apply hermes --yes` first to import non-secret state. - If you also want supported `.env` keys copied across, rerun with `--include-secrets`. - For SecretRef-managed credentials, configure the SecretRef source after the import completes. ## JSON output for automation ```bash openclaw migrate hermes --dry-run --json openclaw migrate apply hermes --json --yes ``` With `--json` and no `--yes`, apply prints the plan and does not mutate state. This is the safest mode for CI and shared scripts. ## Troubleshooting Inspect the plan output. Each conflict identifies the source path and the existing target. Decide per item whether to skip, edit the target, or rerun with `--overwrite`. Pass `--from /actual/path` (CLI) or `--import-source /actual/path` (onboarding). Onboarding imports require a fresh setup. Either reset state and re-onboard, or use `openclaw migrate apply hermes` directly, which supports `--overwrite` and explicit backup control. `--include-secrets` is required, and only the keys listed above are recognized. Other variables in `.env` are ignored. ## Related - [`openclaw migrate`](/cli/migrate): full CLI reference, plugin contract, and JSON shapes. - [Onboarding](/cli/onboard): wizard flow and non-interactive flags. - [Migrating](/install/migrating): move an OpenClaw install between machines. - [Doctor](/gateway/doctor): post-migration health check. - [Agent workspace](/concepts/agent-workspace): where `SOUL.md`, `AGENTS.md`, and memory files live.