Migrating a local agent to managed hosting
A migration checklist for AI agent state, credentials, tools, channels, schedules, validation, and rollback, with Hermes and OpenClaw examples.
Moving a local AI agent to managed hosting means transferring the state and dependencies that make it useful, then switching control of its live channels. The installation is only one part of that move. Memory, credentials, scheduled work, file paths, and rollback all need an explicit destination.
The checklist below applies to a move that keeps the same agent runtime. Hermes and OpenClaw examples use their official documentation checked on September 5, 2026. Managed services may expose only part of these upstream capabilities, so confirm the destination's import and export support before transferring data.
Define what must survive the move
Begin with an inventory you can inspect without revealing secret values. List the runtime version, active profile, workspace directories, enabled tools, model provider, channel accounts, and scheduled tasks. Record the location and owner of each item.
Include files outside the default agent directory. A report script may read a spreadsheet from Downloads, or a tool may use a repository in another folder. Write down those paths and decide whether to copy the files, replace the dependency with an API, or keep part of the workflow local.
| Item | What to record | What to prove on the new host |
|---|---|---|
| Instructions and memory | Active files and profile | The agent uses the intended instructions |
| Sessions | Required history and retention | Needed history is available to the right user |
| Credentials | Provider, owner, scope, and renewal method | Authentication works without exposing the value |
| Tools | Packages, versions, paths, and permissions | A representative task completes |
| Channels | Account, routing, and allowed senders | Messages reach one intended agent |
| Schedules | Trigger, timezone, destination, and last result | The next run occurs once at the intended time |
| Recovery | Backup location and restore procedure | A replacement host can recover the setup |
Decide which history you need before copying everything. Old transcripts and files can contain client data that has no purpose on the destination. Retain the material needed for the work and the retention requirements you have agreed with its owner.
Confirm that the destination supports your workload
Ask the host which runtime versions it supports and whether it accepts a full state import, selected files, or only a fresh configuration. Check the available operating system, tool installation policy, storage paths, export method, and credential renewal process.
A Linux destination may not run a tool that depends on a local desktop application. An API integration may need an updated callback URL or a fresh authorization. Treat those as migration work, not as defects to discover after the laptop is switched off.
Request a concrete answer about backups: which data is included, where copies live, how long they are retained, and who can restore them. If the service has no documented restore path, keep a usable independent export and account for manual recovery.
The hosting comparison checklist covers the maintenance, access, and recovery responsibilities to settle before selecting that destination.
Separate a host move from a runtime change
Moving OpenClaw to another OpenClaw host is different from importing OpenClaw into Hermes. The first aims to preserve an existing setup. The second translates configuration and instructions into another runtime's model and needs a separate acceptance test.
If a runtime change is part of the plan, use the Hermes and OpenClaw comparison to choose the behaviors and permissions you need to test.
Hermes documents a preview for its OpenClaw importer, including skipped or conflicting items. OpenClaw also documents imports from other agent systems. If you are changing runtimes, inspect the migration report instead of treating a successful import command as functional equivalence. Hermes migration guide, OpenClaw migration guide
Where possible, change one major variable at a time. Establish that the existing runtime works on the new host before also changing the model, rewriting skills, and adding new integrations. That gives you fewer possible causes when a task behaves differently.
Create an archive using the runtime's supported method
For Hermes, the documented full-machine route uses hermes backup on the source and hermes import on the destination. The full archive includes credentials. A profile export excludes credentials, so it serves a different purpose and may require fresh authentication after import. Hermes backup and export documentation
For OpenClaw, the machine-migration guide instructs you to stop the gateway before creating a verified archive. It restores the archive to a staging directory and requires you to activate the restored state deliberately. Follow the current instructions for the version you deploy. OpenClaw machine migration
Keep the original archive unchanged and protect it as sensitive data. Transfer it through an authenticated channel, restrict access to the destination copy, and avoid placing it in a public file bucket or a support conversation. Write down its creation time and the source version.
Create separate backups for important external workspaces when the runtime archive does not include them. Verify the archive contents before the maintenance window. Do not discover during a restore that the document directory was a symlink to a disk you never copied.
Restore into a quiet destination
Keep live channels and schedules inactive while preparing the new host. If the platform automatically starts an imported agent, establish how to prevent outbound actions before using its import flow. Use separate test credentials where the integration allows them.
Restore the intended profile and check file ownership. Inspect absolute paths, executable locations, and environment variables. A directory owned by a different user may look present while remaining unreadable to the agent service.
The effective tool environment also matters. Hermes supports multiple terminal backends, while OpenClaw separately configures its execution sandbox. Recheck those settings after a move: the destination may place commands somewhere different from your old terminal session. Hermes backend configuration, OpenClaw sandboxing
Test the restored agent with a small task that uses its real instructions and a harmless tool. Confirm which filesystem it reads and where it writes the result. Follow with an access-denied test for a file or service it should not use.
For a Hermes destination you operate yourself, the 24/7 hosting guide covers service setup and checks after logout or reboot.
Rehearse the destination first
Create a cloudrun workspace and test whether its supported Hermes setup can complete your representative task. Check the required tools, credentials and state before moving production work. A new project does not automatically import everything from the old host.
The developer setup guide provides the entry point for evaluating that destination. For a client migration, use the client-agent launch checklist to record who approves the cutover and who owns rollback.
Set up the destination workspace, then follow the documented first-project steps. Keep the old gateway as the only active production gateway until the migration checks pass.
Switch live traffic with one active owner
Choose a maintenance window and tell the people who depend on the agent how to reach a person during the interruption. Record the last completed task and any work still in progress.
- Pause schedules and inbound processing on the source.
- Let active work finish or record exactly which runs you stopped.
- Take the final consistent archive and transfer changes since the rehearsal.
- Restore and verify the destination before activating its live credentials.
- Move the channel connection or callback to the destination.
- Send a test message and confirm a single reply from the intended agent.
- Enable schedules individually and inspect their next execution times.
Keep the old host available but stopped. Running both copies against the same channel or schedule makes it harder to distinguish a migration failure from duplicate execution. It also complicates deciding which copy contains the latest state.
Verify the complete workflow after cutover
Use actual acceptance criteria. "The dashboard opens" is useful evidence about the dashboard; it says nothing about whether the next client report will arrive.
| Check | Evidence to keep |
|---|---|
| Receive and reply | One incoming message and its matching delivered reply |
| Required tool | Expected output from a representative task |
| Access restriction | Rejection of an unauthorized request |
| Scheduled work | Run time, timezone, result, and destination |
| Restart recovery | Successful request after the service restarts |
| Data preservation | Required memory, files, and history found in the destination |
Include credential renewal in the operating handoff. A token that works today may require a person or supported refresh mechanism later. Assign the owner and record how the agent signals an authentication failure.
Make rollback a controlled switch
Define rollback triggers before the cutover: failed channel delivery, missing state, incorrect permissions, or a required tool that cannot run. Set a maximum troubleshooting window based on how long the users can tolerate the interruption.
To roll back, stop the destination first. Inspect whether it sent messages or changed external systems, then restore ownership of the live channel to the source. Reconcile work completed during the attempted migration before enabling schedules again.
A restored archive cannot undo an email already sent or a record changed in another service. Keep those actions in the cutover log so a person can resolve them without blindly replaying a task.
When can you retire the local copy?
Retire it after the destination has passed the acceptance checks, completed the schedule cycles that matter, and produced a backup you can restore. Record who now owns updates, credentials, incidents, and exports. Then remove obsolete local secrets and archives according to your retention policy, while keeping the agreed recovery copy protected.