Configuration state
Model and provider decisions should land in Hermes with only minimal cleanup required.
Migrate
Use this OpenClaw to Hermes migration guide with a backup-first mindset.
The migration command can do a lot of work quickly. The guide here is about everything around the command: what to back up, what to verify, and what to distrust until you test it live.
Built around Hermes v0.9Updated: 2026-04-18Community guide
Pre-flight
Core commands
cp -r ~/.openclaw ~/.openclaw.backup
hermes claw migrate
hermes backup --output ~/hermes-migrated.zip
Channels and bots
Expect to revalidate webhooks and tokens even when the migration imports the settings cleanly.
Operational habits
Backups, debug views, and newer Hermes workflows become part of the post-migration baseline.
The practical sequence
- 1. Back up OpenClaw before you experiment.
- 2. Confirm Hermes itself already works in this shell.
- 3. Run the migration command once and let it finish cleanly.
- 4. Inspect the imported configuration instead of assuming success.
- 5. Send a real message through the migrated workflow.
- 6. Create a fresh Hermes backup once you trust the result.
Why the live test matters
A completed migration command is not the same thing as a working system. The only dependable finish line is a real provider call or channel reply from the migrated setup. Treat that final live message as the migration verdict.
Post-flight
Check whether `openclaw` still exists in PATH. If the command is gone but the old config remains, migrate from the config location directly and inspect the copied files before trusting the result.
Need a reset
If the migration feels premature, reinforce the base setup first.
A stable install makes migration debugging dramatically easier. If the current Hermes environment is still uncertain, go back to setup, verify the basics, and then repeat the migration path from a calmer starting point.