OpenClaw to Hermes Agent Migration: What Actually Transfers

Am I going to stick on Hermes after this migration? That was the whole question behind this experiment. I run a real production multi-agent system on OpenClaw, and the migration skill promises a clean move over to Hermes. The marketing makes it sound seamless. I did not think it would be, and that is exactly why I ran the test on camera instead of trusting the pitch.

This is the honest version of what happened, including the part where I found out that zero of my 40-plus crons came across.

The system I was actually migrating

This was not a toy demo. The OpenClaw setup I put through the migration is fully in production and includes:

• 6 or more agent workspaces
• 20-plus sub-agents
• 59 custom-built skills
• Over 40 scheduled crons running daily, weekly, and monthly
• 44 active automations, with 11 of them showing errors after the move
• Real workloads like Muddy OS and Clearmud OS, plus a lot of skill-plus-cron combos

My main concern going in was coverage. Does the migration automatically detect Muddy OS and the rest? Does it reconfigure those crons? Does it recreate each agent as a profile on Hermes? Those are the questions that matter when you are moving a system that is actually working, not a fresh install with one agent.

Setting it up the right way: same machine vs cross-VM

I started on a clean demo Hermes account with nothing on it, kept separate from production so the experiment stayed safe. In Hermes I went to news research, searched the skills for "OpenClaw migration," and pulled up the documentation.

You can install it with the Hermes skill button, but I prefer to feed things to my agent directly. So I copied the documentation, opened a fresh terminal session to be thorough, and pasted the instructions in.

Here is the most important setup detail. The migration assumes both OpenClaw and Hermes live on the same root machine. When that is true, the Hermes setup wizard auto-detects the OpenClaw home directory, and you can simply feed the skill to your Hermes agent and let it run.

My case was different. My OpenClaw system is sandboxed on its own VM, separate from the Hermes VM. In that situation the wizard will not find any OpenClaw home directory on its own. So I gave the agent explicit environment context, telling it the OpenClaw setup was on another VM. If you are doing a real cross-machine production move, this is the realistic path, and you cannot rely on auto-detection.

Migrating through a GitHub backup

Because my OpenClaw system already backs up to a private GitHub repository twice a day, I used that as the migration source instead of trying to wire the two machines together directly.

The flow looked like this: clone the existing private backup repo, build a Hermes-compatible staging source from it, then run the official OpenClaw to Hermes migration against that staging source. The agent walked through every step, flagged that there was no local OpenClaw directory, and made the process easy to follow. I ran it with the full preset: allow-list, secret migration enabled, a soul.md override with a backup, targeting the Muddy OS root directory.

Before any of this, snapshot everything. I snapshotted both VMs so I could revert if anything went sideways. I highly recommend creating backups before you attempt to do anything.

What migrated cleanly

Once it ran, the speed surprised me. I was expecting it to take half an hour. It did not.

The core transferred well:

• Soul and workspace
• agents.md
• Memory
• User data

After running reset, the agent correctly self-identified as "Muddy COO," the theme survived, and a hard refresh of the dashboard confirmed the core identity made it across.

Then a late and pleasant surprise: my 59 custom skills imported too. They landed under an "OpenClaw imports" grouping, but they were there. Up to this point I had no complaints about the process itself. The agent's step-by-step handholding, the dry run, and the conflict prompts were genuinely good.

What did not migrate

This is where my opinion turned.

Agent profiles did not carry over. In OpenClaw each agent is a workspace made of markdown files. I expected the migration to detect each workspace and create one Hermes agent profile per agent. It did not convert them.

And the crons. Zero of my 40-plus scheduled crons carried over. None of them. That is the single biggest pain point, because rebuilding crons one at a time is too tedious to be reasonable on a system my size. On top of that, of the 44 active automations, 11 showed errors after the move, so even the partial transfers needed cleanup.

To be fair about cause: the process quality is not the problem. The disappointment is about coverage, not about how the tool walked me through the work.

Why my secrets did not migrate, and why that is correct

My secrets and private keys did not transfer either, but that one is by design, not a failure. I use a git-ignore rule that keeps secrets and private keys out of the GitHub backup. If that repo is ever compromised, there are no keys to rotate. The tradeoff is that secrets migrate separately, on purpose. I consider that the right security posture.

The verdict depends entirely on your setup

So, am I staying on Hermes? My honest read is that the answer scales inversely with how complex your system is.

If you just have one agent, the migration would be a better experience. If you do not have many crons scheduled, you would probably enjoy this process more. The complexity is what breaks it, especially a large pile of crons and skill-plus-cron combos. For a heavy production system like mine, the migration leaves enough manual reconstruction that I cannot recommend it without reservation.

Practical takeaways before you migrate

• Snapshot both VMs first, source and target, so you can revert.
• For cross-VM moves, give the agent explicit environment context. Do not trust auto-detection.
• If both systems share the same root machine, just feed the skill to your Hermes agent and let the wizard detect OpenClaw.
• If you already back up to GitHub, consider migrating from that repo: clone, build a staging source, run the official migration.
• Start a fresh terminal session before pasting migration instructions.
• Choose the full compatible migration mode over user-data-only if you want maximum coverage.
• Keep secrets out of your backups with a git-ignore rule, and plan to migrate them separately.
• On heavy systems, assume crons and agent profiles will not transfer and budget time to rebuild them.
• Audit your automations afterward and fix the errored ones.
• Right-size your expectations to your system's complexity.

Watch the full walkthrough here: https://www.youtube.com/watch?v=7XDB60X7BwQ