OpenClaw Migration: What Hermes Officially Imports

Migration is a bridge, not a magic wand

The official docs confirm that hermes claw migrate reads from ~/.openclaw/ by default and can also detect legacy Clawdbot or Moldbot directories. The important interpretation is this: Hermes gives OpenClaw users a serious migration path, but it still expects an operator to review the result afterward.

What gets migrated

• SOUL.md into ~/.hermes/SOUL.md
• MEMORY.md and USER.md into ~/.hermes/memories/
• Skills into ~/.hermes/skills/openclaw-imports/
• Provider and MCP settings, plus selected messaging configuration
• API keys when secrets migration is enabled

Should you migrate now

• Yes, if your OpenClaw setup is active, documented, and still valuable enough to preserve
• Yes, if you want continuity for identity, memory, and skills instead of redoing the same work
• No, if your old environment is already messy and you would not trust it even after import
• No, if you have not yet decided whether Hermes is the right long-term path for that workload

What deserves extra attention

• You can preview changes before applying them
• Workspace instructions require --workspace-target when you want Hermes to place AGENTS.md into a workspace
• Some OpenClaw concepts are archived for manual review instead of mapped directly
• WhatsApp still requires re-pairing after migration

Recommended migration flow

1. Run a preview first and inspect what Hermes thinks it can map
2. Decide whether you want to import secrets immediately or stage that separately
3. Set a workspace target only when you are confident about where project rules should land
4. After import, validate one provider and one messaging surface before doing anything broader

Operator takeaway

The migration story is good precisely because it is not pretending to be frictionless. The right mental model is: let Hermes import what can be mapped, then explicitly verify providers, workspace rules, and messaging. Treat migration as accelerated onboarding, not as a replacement for review.

A practical migration order

1. Preview the migration first
2. Run the actual import only after the mapping looks sensible
3. Verify provider auth with hermes status
4. Test one messaging surface at a time
5. Move into workspace-specific instruction cleanup only after the base environment is stable

What to verify immediately after migration

• Whether your imported SOUL.md still expresses the right instance identity
• Whether workspace rules belong in imported content or need to move into AGENTS.md
• Whether provider credentials were imported cleanly and are actually usable
• Whether imported skills still make sense in Hermes rather than just existing as historical baggage

Where migrations usually go wrong

The common mistake is psychological, not technical: users see imported files and assume the environment is production-ready. A migration result should be treated as a reviewable starting point, not as proof that the old setup was perfectly translated.