Migrating your AI agent to a new host without losing memories or downtime

Migrating your AI agent to a new host without losing memories or downtime

Sooner or later every agent moves: from a laptop to a server, from one VPS to another, from self-hosted to managed. The migration itself is rarely hard — what bites people is state loss (the agent forgets everything) and silent breakage (it runs but half its tools fail). This is the checklist we use, in order.

Before you touch anything: inventory

Write down what your agent actually consists of. For most setups it's four things:

1. The runtime — the agent binary/container and its version.
2. Configuration — config files, environment variables, API keys, model settings.
3. State — memories, session history, databases, uploaded files, n8n workflows and credentials.
4. Integrations' view of the agent — webhook URLs registered with external services, OAuth apps, cron schedules pointing at the old host.

Item 4 is the one people forget. Your agent can migrate perfectly and still be dead because Telegram webhooks point at the old IP, or a SaaS sends its events to a URL that no longer exists.

Step 1: Export state while the old host still runs

Never migrate from backups alone if you can export live. Stop writes first (pause schedules, put the agent in a quiet state), then export:

• n8n: export workflows and credentials through the CLI or UI; back up the database that stores execution history.
• Agents with memory stores: dump the memory database (SQLite file, Postgres dump, vector store export) — not just config.
• Files: session data, uploads, anything under the agent's data directory.

Verify the export before proceeding: restore it into a scratch directory on the new host and confirm the files open, the database connects, the row counts match. An unverified backup is a hope, not a plan.

Step 2: Stand up the new host in parallel

Provision the new host completely before touching DNS or webhooks: runtime installed, config copied, secrets set, state restored, agent started on a test port or internal address. Then verify against reality, not vibes:

• The agent starts without errors and answers a health check.
• It can reach its model provider (one real round-trip).
• Memories survived: ask it something only the migrated state would know.
• Tools work: send a test message that exercises its most-used integration.

This parallel-running window is your safety net. Keep the old host fully intact until step 4 succeeds.

Step 3: Cut over deliberately

The cutover order matters: point consumers at the new host before decommissioning anything.

• Update DNS with a low TTL (300s) if you use a domain.
• Re-register webhooks: most services let you re-set the callback URL via their dashboard or API; do this for every integration in your inventory from the preflight.
• Update any external schedulers or cron jobs that call the agent directly.
• Send one message through each critical channel (chat app, email trigger, scheduled task) and watch it process end-to-end on the new host.

Expect a short overlap where both hosts could receive traffic. That's fine — it's why you paused schedules in step 1 and why the old host stays up.

Step 4: Verify for a day, then decommission

Run both hosts for 24 hours with the old one stopped-but-present (processes stopped, data intact). If nothing breaks and the new host's logs look normal, take a final backup of the old host's state and shut it down. Keep that final backup for at least a month; storage is cheap and "we deleted the old VPS last week" is a painful sentence.

Rollback: decide it now, not during the incident

Rollback is trivial if you follow this order: flip DNS/webhooks back to the old host, start its processes, done — because you never destroyed it. If you skipped parallel running and migrated in place, rollback means restoring backups and losing whatever happened since. That asymmetry is the entire argument for doing this properly.

Common post-migration failures

• Webhooks still on the old host: the agent works when you talk to it directly but never reacts to external events. Check inbound event logs on both hosts.
• Timezone drift: the new host runs UTC, the old ran local time; schedules fire at wrong hours. Set the timezone explicitly in the container/systemd config.
• Missing env vars: the agent starts fine but a tool fails on first use because a key lived in an old shell profile, not the exported config.
• Stale OAuth callbacks: integrations that redirect to the old domain need their redirect URLs updated in the provider's developer console.

Migrations reward boring discipline: inventory, export, verify, parallel-run, cut over, watch, decommission. Every horror story we've seen started with someone skipping the verification steps to save an hour.