Migrating Your OpenClaw Agent Between Cloud Providers
You picked a cloud provider six months ago. Maybe it was the cheapest option, maybe a friend recommended it, maybe you just wanted to get your OpenClaw agent running and didn't think too hard about the decision. Now you need to move. Prices went up, latency is bad for your users, or the provider deprecated a feature you depend on.
And you realize your agent is stuck.
Not because OpenClaw locks you in. The open config format (SOUL.md, AGENTS.md, skill manifests) is deliberately portable. The lock-in comes from everything around it: the way your memory is stored, the environment variables baked into your setup, the webhook URLs hardcoded into third-party services, the filesystem paths your skills assume. That's the real migration challenge, and it's the one nobody warns you about.
## Why vendor lock-in is a real risk for AI agents
Traditional web apps are stateless enough that migration is mostly a deployment problem. Spin up the same Docker container somewhere else, point DNS, done. AI agents are different because they accumulate state over time.
Your agent's **memory** represents months of learned behavior. Conversation history, user preferences, contextual knowledge it picked up from thousands of interactions. This isn't just data. It's the difference between an agent that knows your customers and one that starts from zero.
Your agent's **skills** have their own state. A CRM skill caches customer records. A research skill maintains document indexes. A scheduling skill tracks calendar state. Each skill stores data in whatever format and location it prefers.
Your agent's **environment** includes API keys, webhook endpoints, file paths, network configurations, and provider-specific settings that are woven into every layer of your setup.
**Move the agent without moving all of this, and you get an agent with amnesia running in an unfamiliar environment.** It technically works. It practically doesn't.
## What you need to migrate
Before you touch anything, build a complete inventory. Most failed migrations fail because something was missed in the planning phase, not the execution phase.
### Memory and conversation state
Your agent's memory lives in a database or file store, depending on your hosting setup. Common configurations include:
- **SQLite files** on the local filesystem (common for single-server setups) - **PostgreSQL databases** managed by the cloud provider - **Redis** for session state and short-term memory - **File-based memory** in the OpenClaw workspace directory
Each of these requires a different export strategy. SQLite files can be copied directly. PostgreSQL needs a pg_dump. Redis needs an RDB snapshot or AOF export. File-based memory needs a recursive copy that preserves permissions and symlinks.
**Don't assume you know where all the memory lives.** Run a full filesystem search for any files modified by the OpenClaw process. Check database connection strings in your environment variables. Some skills create their own databases that aren't in the main config.
### Skills and skill state
Installed skills are declared in your AGENTS.md manifest, but the actual skill binaries, caches, and state files live in various locations. Export the skill registry state, not just the manifest. The registry tracks which versions are installed, which have pending updates, and which have been pinned to specific versions.
### Personality and configuration
Your SOUL.md, AGENTS.md, HEARTBEAT.md, and any custom configuration files are the easy part. These are text files in your workspace directory. Copy them as-is. But check for **provider-specific references** in these files. A SOUL.md that mentions specific file paths, API endpoints, or provider features will need updating.
### Environment variables and secrets
This is where migrations get painful. Environment variables contain API keys, database connection strings, webhook secrets, feature flags, and provider-specific configuration. Some of these transfer directly (your Stripe API key works anywhere). Others are provider-specific (a managed database connection string points to an IP that only exists in that provider's network).
**Make a complete list before you start.** Export every environment variable your agent process has access to. For each one, determine whether it transfers as-is or needs to be recreated at the destination.
### Webhook URLs and external integrations
Every external service that sends data to your agent (Stripe, GitHub, Sentry, Slack) has a webhook URL pointing to your current server. After migration, every single one of these needs updating. Miss one, and that integration silently stops working.
## Step-by-step migration process
### Step 1: Audit your current setup
Run a full dependency scan. ClawSail's audit command catalogs everything your agent depends on: files, databases, environment variables, network endpoints, external integrations. The output is a migration checklist with nothing left to guess about.
If you're doing this manually, start with:
- List all files in the OpenClaw workspace directory - Export all environment variables from the agent process - List all database connections - Document every webhook URL configured in external services - Record the OpenClaw version and all installed skill versions
### Step 2: Prepare the destination
Set up the new cloud provider with matching specifications. Pay attention to:
- **OpenClaw version**: install the exact same version. Upgrading during a migration adds unnecessary risk. - **Runtime dependencies**: same Node.js version, same system libraries, same filesystem layout. - **Network configuration**: the new server needs to accept connections on the same ports your agent uses. - **Storage**: enough disk space for your memory database, skill caches, and log files.
### Step 3: Export everything
Take a consistent snapshot. This means stopping your agent briefly to ensure no writes happen during export. For high-availability setups, use a read replica or consistent backup instead.
Export your memory database, skill state, configuration files, and environment variable mappings. ClawSail packages all of this into a single encrypted archive with integrity checksums for every file.
### Step 4: Transfer and restore
Move the archive to your new server. Restore in order: configuration files first, then the memory database, then skill state. This order matters because skills may depend on configuration being in place, and memory restoration may require skills to be available.
### Step 5: Update external integrations
Go through your webhook URL list and update every external service to point to the new server. This is the most tedious step and the one most likely to have something missed. ClawSail tracks all known webhook endpoints and can generate the update list automatically.
### Step 6: Verify
Run a health check that exercises every part of your agent. Don't just check if the process starts. Verify that:
- The agent can access its full conversation history - Every installed skill loads and functions correctly - All webhook endpoints receive test payloads - Response times are within expected ranges - Environment-specific integrations connect successfully
**Keep the old server running until verification is complete.** Don't decommission anything until you've confirmed the new setup handles real traffic correctly for at least 48 hours.
## How ClawSail simplifies this
ClawSail was built specifically for this problem. Instead of manually auditing, exporting, transferring, and verifying, you connect ClawSail to both your source and destination environments.
ClawSail scans the source environment and builds a complete dependency graph. It shows you exactly what will transfer automatically, what needs manual attention, and what won't transfer at all. During migration, data streams directly between source and destination with no intermediate storage. After transfer, ClawSail runs a comprehensive verification suite that checks every component.
The entire process takes minutes instead of hours, and the verification step catches problems that manual checking misses. Head over to [ClawSail's try page](/try) to see how it works with your specific setup.
## Avoiding lock-in from day one
The best migration is the one you never have to stress about. A few practices that keep your agent portable:
- **Keep everything in config files.** If a setting lives only in a provider dashboard, it won't survive a migration. - **Use standard databases.** PostgreSQL and SQLite are available everywhere. Provider-specific managed databases may not be. - **Document your webhook URLs.** Maintain a single document listing every external service integration and its webhook endpoint. - **Test portability regularly.** Once a quarter, try restoring your agent on a different provider. Discovering portability gaps during a planned test is far better than discovering them during an emergency. - **Use ClawSail's export regularly.** Even if you're not planning a migration, a recent export is an insurance policy against unexpected provider issues.
## Getting started
If you're planning a migration, or if you just want to verify that your agent could move if needed, [try ClawSail](/try). The audit function is free and shows you exactly how portable your current setup is. When you're ready to migrate, ClawSail handles the heavy lifting so you can focus on verifying the result instead of managing the process.