Your agent is a set of files, not the machine they live on. Copy the OpenClaw home directory, the secrets it loads, and its cron config to the new server, reinstall the runtime there, and it picks up where it left off. Qoren's migration script packs those files for you.
What actually carries your agent's state?
Open everything under `~/.openclaw` and you are looking at your agent. There is no database hiding somewhere else. The pieces:
- `openclaw.json`: the gateway and MCP server config. The MCP servers your agent can call live here, with their tool filters.
- `workspace/`: SOUL, IDENTITY, AGENTS, USER and MEMORY files, plus the `memory/` folder. This is who the agent is and what it remembers. Lose this and the new install is a stranger with your API keys.
- `skills/`: the skills it has picked up.
- `cron/jobs.json`: the scheduled jobs, the ones that send your morning brief at 7am whether you are watching or not.
Outside the home directory sit the environment variables, usually an env file loaded by the service manager. Those are part of the agent too: the model keys, the integration tokens, the webhook URLs.
What does not move is the runtime itself. The `openclaw` npm package installs fresh on the new machine in a minute. Treat it like you would treat Node: you reinstall it, you do not copy it. The docs on migrating a self-hosted agent to Qoren call this out directly: the export copies configuration, not the runtime.
Why move the agent instead of rebuilding it?
Because "rebuild it" means re-teaching the agent everything it knows. You can spin up a fresh OpenClaw on a new server, paste in a gateway config, and have something that answers messages. But the memory folder is empty. The skills are gone. The cron jobs are not scheduled. You have deployed a runtime, not your agent.
This is also why a change of server is the natural moment to stop hosting an agent on a laptop, where sleep kills it silently. We wrote a whole post on keeping an OpenClaw agent running after your laptop sleeps. If the server move is happening anyway, moving to a host that stays up costs nothing extra.
How does the migration script work?
Run this on the old machine, in the directory where you want the archive:
curl -fsSL https://qoren.sh/migrate.sh | shIf more than one runtime is installed, or you want secret values included, be explicit:
curl -fsSL https://qoren.sh/migrate.sh | sh -s -- --runtime openclaw --with-secretsWhat it does, at a high level. It finds the runtime under your home directory (or wherever `OPENCLAW_HOME` points), reads `openclaw.json` for the MCP servers and the cron config, and packs the workspace, memory, skills and scheduled jobs into one `tar.gz` with a `manifest.json` listing every file. It scrubs anything that looks like a key from the config files. It needs only `sh`, `tar` and `gzip`, so it runs on any cheap VPS.
Two details worth knowing before you run it:
1. Without `--with-secrets` the archive carries environment variable names but not values. With it, the values come along, and you should treat the archive like a password file until the import is done. 2. Cron entries with a five-field schedule become Qoren scheduled tasks. Interval expressions like `every 5m` are skipped and listed, so you can recreate those by hand instead of discovering the gap later.
The script prints a summary when it finishes: the model it found, the environment variable names, how many files were skipped as binary or too large. The migration docs cover every flag and what each runtime's files land as.
How do you import the archive?
Install the Qoren CLI and sign in, then preview first:
npm i -g @qoren/cli
qoren agent import ./qoren-export-openclaw-20260905-003200.tar.gz --env <environment-id> --dry-runThe dry run prints what would be created, the runtime, the model, the persona size, the file list, and stops before any API call. `--env` is the id of the Qoren environment the agent deploys onto. The script's closing hint prints the exact import command with your archive path, so you can copy it straight from the old machine's terminal.
If the preview looks right, run the same command again without `--dry-run`. That saves a template, deploys the agent, waits for the deploy, and copies memory and skills into place. If you exported with `--with-secrets`, add `--import-secrets` so the values go into the vault and get attached to the agent, rather than sitting in a file.
Prefer clicking to typing? The console has an Agents > Import page that takes the same archive.
Either way, the files end up in the same places they were on the old machine. Your agent starts wearing its own memory again.
Would rather move it yourself?
The script is a shortcut, not a gate. The generic path works on any pair of machines:
# on the old server
tar -czf openclaw-home.tar.gz -C ~ .openclaw
# move it
scp openclaw-home.tar.gz user@new-server:~
# on the new server: install the runtime, then unpack
npm install -g openclaw@latest
tar -xzf openclaw-home.tar.gz -C ~Then move the env file by hand, reinstall it into your service manager, and check that the cron config survived the trip. This path works. It also means you own the parts the script automates: scrubbing secrets from configs, excluding binaries and oversized files, and deciding which of those decisions matter. If you go this route, follow our OpenClaw security checklist on the new box before the agent goes live. A migration is the easiest time to get the env file permissions right.
How do you know the new server is running your agent?
Before you switch the old install off, check four things in the console:
1. Memory shows the persona. The workspace files are there, and the agent knows who it is. 2. Secrets are attached. If you imported them into the vault, they show on the agent. 3. Messaging is reconnected. Send it a message and get one back. 4. One scheduled task fires on time. Force the next cron job to run and confirm the output arrives.
When all four pass, shut the old install down. That is the whole migration: one script on the old machine, one import command on Qoren, four checks in the console.