How to move OpenClaw to a new server without losing anything

When you need to move OpenClaw to new server hardware, and the last thing you want is to lose your agent’s memory, your carefully tuned config, or the plugins that took time to set up. This article walks you through exactly what to copy, in what order, and how to verify everything works before you switch over. Start by asking your agent what you have.

Time estimate: 30 minutes

Step 1: Take inventory of what you have

Before you copy anything, you need to know exactly what you are copying. OpenClaw stores its state in several places: the config file, the plugins directory, the memory database, the session archives, the LCM database, and any cron jobs you have set up. Missing any one of these means your agent will not work the same way on the new server.

The inventory step is a single paste to your agent. It will list everything that needs to be moved.

Show me a complete inventory of everything that would need to be moved if I were migrating this OpenClaw instance to a new server. Include: config file location and size, list of enabled plugins with their configs, memory database location and size, session archive location and count, LCM database location and size, any cron jobs or systemd timers that run OpenClaw tasks, and any external dependencies such as Ollama or external APIs.

Your agent will produce a list. Here is what a complete inventory looks like:

Knowing what each directory and file contains helps you understand what you are risking if it does not transfer correctly.

openclaw.json is the master configuration file. It contains your model settings, all plugin configs, API keys stored in the file, gateway settings (port, bind address), channel configurations (Discord token, Telegram bot token), and compaction settings. Losing this file means manually rebuilding everything from scratch. It is small (usually 2 to 5KB) and easy to back up and restore.

The memory database is where your agent stores what it has learned across sessions. Depending on which memory plugin you use, this is either a directory of files (vector database files, embedding indexes) or a single database file. Losing this means your agent has no persistent memory. It will not remember your preferences, your name, your past decisions, or anything you told it to remember. The memory database grows over time and can reach hundreds of megabytes on an active install.

The LCM database (lcm.db) stores compressed conversation summaries. This is how your agent recalls details from sessions that happened weeks or months ago without keeping every word of every conversation in memory. Losing it means your agent cannot recall past sessions beyond what is in the active context window. On a busy install, this file can be several gigabytes.

Session archives are raw session JSON files, typically stored if you run the archive cron. These are useful for auditing and for re-feeding context to your agent, but they are not required for the agent to function. If you are short on transfer time, session archives can be transferred separately after the migration is complete.

The plugins directory contains the installed plugin packages. Most of these are JavaScript files that are safe to copy directly. The exception is plugins with native compiled binaries (C++ addons, Rust extensions). Those binaries are CPU-architecture-specific and cannot be moved from ARM to x86 or vice versa. The plugin’s config and database files are safe to move; only the binary itself needs to be rebuilt.

Show me the size of each of the following on this server: the memory database, the LCM database, the session archives directory, and the plugins directory. For each one, tell me whether it is safe to copy directly to a new server with a different CPU architecture, or whether any part of it needs to be rebuilt.

If your agent cannot reach the server, SSH into the old server and run ls -la ~/.openclaw/ and crontab -l to get a manual inventory.

Step 2: Backup everything before you touch anything

Once you know what you have, back it up. The backup is your safety net. If something goes wrong during the transfer, you can restore from this backup and start over. The backup should be a single compressed archive that contains everything from the inventory. Before creating it, stop the OpenClaw service on the old server. Some database files (particularly the LCM database and memory database) use file locks that can cause the archive to contain a corrupted snapshot if the service is writing to them during backup. Your agent can create it.

Create a backup archive of the entire OpenClaw data directory, including config, plugins, memory database, session archives, and LCM database. Exclude log files and cache directories. Show me the command you will run before running it, then create the archive and tell me where it is saved and its size.

Step 3: Prepare for the OpenClaw server transfer

The new server needs OpenClaw installed, ideally the same version you are running on the old server. Version mismatches can cause config parsing errors or plugin incompatibility. Check your current version before touching the new server.

What version of OpenClaw am I currently running? Show me the exact version string. Then tell me the command to install that same version on a fresh Ubuntu 24.04 server, or the equivalent for whatever OS the new server runs.

Once OpenClaw is installed on the new server, do not start it yet. Starting it creates default directories you will later overwrite with your backup. Leave it stopped.

Check whether OpenClaw is already running on the new server. If it is, stop the service. Then verify that the openclaw data directory exists and is empty except for any default files installed by the package. Show me the current state.

Before you copy anything to the new server, confirm OpenClaw starts clean on its own. This proves the install itself is good. If the service fails to start on a fresh install, there is a package or dependency problem that would be hidden by your backup data. Find and fix that first.

Start the OpenClaw service on the new server with default settings. Show me the service status and the first 30 journal lines. Is it running without errors? If not, tell me exactly what failed and what I need to fix before I bring my data over.

Once a clean start succeeds, stop the service again before restoring your backup. You do not want the service writing to default database files that will be overwritten by your backup.

Step 4: Transfer the backup to the new server and restore it

Now copy the backup archive from the old server to the new server and extract it into the correct location. The goal is to make the openclaw data directory on the new server identical to the old one, minus logs and cache.

Copy the backup archive I created to the new server. Show me the exact scp or rsync command to use, including the destination path. Once the archive is on the new server, extract it into the openclaw data directory, preserving permissions. Show me each command before running it.

After extraction, verify that the files are in place and have the correct ownership. If permissions are wrong, the service will fail to start in ways that produce confusing errors.

After extracting the backup on the new server, list the contents of the openclaw directory and compare with the inventory from step 1. Are any files missing? Do the file sizes match? Are the permissions and ownership correct? Show me a side-by-side comparison.

Some plugins store absolute file paths in their config section inside openclaw.json. If the new server has a different home directory or username (e.g., the old server ran as ubuntu but the new one runs as node), those paths will point to non-existent locations. The plugin will fail silently.

Read my openclaw.json. Check every plugin config for any absolute file paths. List each one. For any path that starts with the old server’s home directory, tell me what the corrected path should be on the new server and update the config.

Step 5: Test the new server before cutting over

Do not switch your traffic to the new server yet. First, start OpenClaw on the new server and verify that it works exactly as expected. This test runs while the old server is still handling your requests, so there is no pressure to rush.

Start the OpenClaw gateway on the new server. Show me the command, then run it. Once it is running, check the service status and show me the last 20 journal lines. Are all plugins loading without errors? Is the memory system connecting to the right database file?

What to test after startup:

• Service is active with no errors in the journal
• All plugins initialize without errors (journal shows plugin load messages)
• Memory recall works: ask the agent something it should remember from the old server
• Cron jobs are present: verify each one is scheduled correctly
• External dependencies are reachable: Ollama, any configured APIs
• A simple task completes: have the agent do a web search or file read

Run a migration verification check. Test: (1) recall something from my long-term memory to confirm the memory database transferred correctly, (2) list all enabled plugins and confirm they loaded without errors, (3) check that all cron jobs are present, (4) run a simple web search to confirm external API access is working. Report pass or fail on each item.

Step 6: The cutover sequence

Once the new server passes all tests, you are ready to switch traffic. The cutover should be quick and deliberate. The goal is minimal downtime and no lost messages.

The exact cutover method depends on how you connect to OpenClaw:

• Direct IP and port: Update your client (Discord bot config, Telegram bot config, web UI) to point to the new server’s IP and port.
• DNS record: Update the A record for your OpenClaw domain to point to the new server’s IP. DNS changes propagate in 1 to 60 minutes depending on your TTL.
• Reverse proxy: Update the proxy upstream to forward to the new server’s internal address.
• Port forwarding rule: Change the firewall or router rule to forward the external port to the new server.

Help me plan the cutover from the old server to the new server. Tell me how you are currently being accessed (which channel, which IP or domain). Then list the exact steps to switch over, in order, including any commands I need to run. I want to see the full plan before I execute anything.

After cutover, verify traffic is reaching the new server. Monitor the journal on the new server for any errors that only appear under real load.

After the cutover is complete, check the journal on the new server for the last 10 minutes of activity. Are requests coming in? Are there any errors that were not present during testing? Show me the service status and the most recent journal entries.

Step 7: Final OpenClaw backup restore and decommission

Once the new server has been running stably for at least 24 hours, you can decommission the old server. Before shutting it down, make one final backup from the old server to capture any changes that happened during and after the cutover window: new memories, new session archives, or any config adjustments made on the old server that you forgot to port over.

Create a final backup from the old server covering only the data that changes over time: memory database, session archives, and LCM database. Then help me merge this data onto the new server without overwriting newer files that already exist there.

After the final merge, stop the OpenClaw service on the old server. Keep the old server alive (but with the service stopped) for 48 hours as a fallback before deprovisioning.

What actually gets lost when people skip steps

The “without losing anything” title is a real promise, but it depends on knowing what “anything” includes. Here is the complete picture of what exists in a running OpenClaw instance and what happens if each piece does not make it to the new server.

The environment variables item catches people most often. If you stored an API key as an environment variable instead of in openclaw.json (a common practice for security reasons), that key is invisible to any backup. It only exists in the shell session or systemd override where it was set. Export them manually.

Check the environment that OpenClaw runs in on this server. Are there any API keys, tokens, or configuration values set as environment variables rather than in openclaw.json? Check the systemd service override file, the shell profile for the user running openclaw, and any .env files in the workspace. List everything that would need to be recreated on the new server separately from the config backup.

How to confirm the migration was complete

After the cutover and the final backup merge, run one comprehensive check on the new server to confirm everything transferred correctly. This check covers the four things that most commonly break after a migration: memory, plugins, cron jobs, and environment.

Run a full post-migration verification on this server. Check and report on each of the following: (1) recall three things from my long-term memory to confirm the memory database is intact, (2) list all enabled plugins and confirm each one loaded without errors in the journal, (3) list all cron jobs and systemd timers that reference openclaw tasks and confirm they are present, (4) check whether any required environment variables are missing by testing each external integration, (5) check disk space, RAM, and swap to confirm the new server is healthy. Give me a pass or fail for each item with specifics.

What passing looks like for each check:

• Memory: the agent recalls specific facts from the old server without prompting
• Plugins: journal shows each plugin initialized successfully, no “failed to load” messages
• Cron jobs: the full list from the old server is present and scheduled with correct times
• Environment: every external integration responds (API calls succeed, no auth errors)
• Server health: RAM below 80% usage, swap enabled and not exhausted, disk below 70% usage

If any check fails, do not decommission the old server until you have fixed the issue. The old server is your fallback.

If something breaks during the migration

Even with a clean backup and careful execution, things can go wrong. The archive might be incomplete, a plugin might need to be rebuilt, or the config might have a path that breaks on the new server. Here is how to handle each failure mode without losing data.

Check the journal first. The error tells you exactly what is wrong. Most startup failures after a migration fall into three categories: a config field with an absolute path that no longer exists, a plugin with a native binary that needs to be rebuilt for the new architecture, or a missing environment variable that the service depends on.

Show me the last 50 lines of the openclaw journal on this server. I just completed a migration from another server. Look for any errors related to config fields, missing files, failed plugin loads, or missing environment variables. Tell me exactly what is wrong and what I need to fix.

Memory recall failing after a migration almost always means the memory database file is in the wrong location, or the plugin config still points to the old server’s path. The agent is connecting to an empty database instead of the one you transferred.

Check where my memory plugin is configured to look for its database file. Then check whether that file actually exists on this server. If the path is wrong or the file does not exist, tell me where the transferred database file is and what the config needs to be updated to.

If a plugin loads without errors but does not work the same way, the most common cause is a missing config value. When you transferred openclaw.json, the plugin section transferred with it, but any values that were set as environment variables or defaults that differed between versions will be missing or wrong.

Read my openclaw.json and show me the full config section for [plugin name]. Compare it with the documented required fields for that plugin. Are any required fields missing or set to incorrect values? Tell me what the correct values should be.

If the new server has a critical problem you cannot diagnose quickly, roll back to the old server by reversing the cutover steps: point DNS or your client config back to the old server’s IP and restart the old service. The old server should still be alive with its data intact. This is why you kept it running for 48 hours after cutover.

I need to roll back to the old server. Tell me what I need to update to point traffic back to the old server’s IP address. Then check whether the old server’s openclaw service is still running and healthy.

Questions people actually ask about this

Ideally yes. Version mismatches can cause config parsing errors or plugin incompatibility. If you cannot install the exact same version, install the latest stable release and ask your agent to identify any breaking config changes between your current version and the new one. The agent can update your config file automatically.

Compare my current OpenClaw version with the latest stable release. Are there any breaking changes to the config format between these versions? If yes, show me what fields need to be updated and make those changes to my openclaw.json now.

Plugins with native dependencies (like memory-lancedb-pro, which uses compiled SQLite bindings) ship as pre-built binaries for each CPU architecture. These binaries are not cross-compatible. Copying the plugins directory from an ARM server to an x86 server will cause the native plugins to fail on load. After transferring the config, reinstall any native plugins on the new server by running their install command inside the OpenClaw plugins directory. The config is safe to transfer; the compiled binaries are not.

Check whether any of my enabled plugins have native compiled dependencies. For any that do, tell me the exact command to reinstall them on the new server’s architecture, and whether the plugin’s data files (databases, indexes) can be safely transferred or need to be rebuilt.

Yes. The inventory and backup steps happen entirely on the old server with no downtime. The new server tests happen independently. The only moment of potential disruption is the cutover itself, which takes seconds to minutes depending on your access method. Any messages or tasks that arrive during that window will miss. To minimize data loss, take a final backup just before cutover and merge it onto the new server as described in Step 7.

Cron jobs. They live outside the openclaw data directory in the system crontab. They are invisible to the agent unless you specifically ask it to check. Every operator who has moved servers and found their scheduled tasks stopped working missed this step. Check and export your crontab before you shut down the old server.

Show me all cron jobs on this server that run OpenClaw tasks or reference openclaw directories. Give me the complete crontab entries I need to recreate on the new server, with any file paths adjusted for the new server’s directory structure.

If the LCM database or memory database is several gigabytes, scp over a slow connection can take a long time. Two alternatives: use rsync with compression (rsync -avz) which handles interruptions and resumes transfers, or copy the archive to an intermediate S3-compatible storage and download it on the new server. For very large databases, the rsync approach is more reliable because it can restart after a dropped connection.

How large is my LCM database and my memory database? If they are over 1GB each, recommend the fastest and most reliable transfer method for moving them to a new server, and give me the exact commands.

Two things cause this most commonly. First, the cron jobs did not transfer and the agent is no longer running its scheduled tasks (heartbeats, morning briefs, etc.). Second, an environment variable that was set on the old server is not set on the new one. API keys in environment variables, not in openclaw.json, are invisible to the backup. Check the old server’s shell profile for any export statements that OpenClaw depends on.

Check the openclaw service environment on the new server. Are there any environment variables that need to be set for plugins or external services to work? Compare with what I had on the old server. List anything that might be missing.

If the agent on the old server is still reachable via chat, ask it to create a backup archive and upload it to a location you can access (like a temporary Cloudflare R2 bucket, S3, or even a large Discord file if the archive is under 25MB). If the agent is also unreachable, the data on that server is inaccessible without SSH. This is why the backup step happens first, before any migration work, while everything is still working.

Go deeper