What has to survive when an AI assistant moves machines

I'm starting this migration with an inventory instead of a copy of the home directory. A home directory copy moves whatever's visible, misses state held by services, databases and external credentials, and copies caches that should be rebuilt anyway. For an AI assistant the list covers model config, system instructions, memory records, source documents, indexes, tool definitions, scheduled jobs, service units and secrets, each with a location, owner, backup method and recovery test. I'm also marking which machine is authoritative during the move. If both hosts accept jobs, their memory and activity records will drift apart, and a short read-only period is much easier than merging two histories later.

The main prompt is simple to find, but it probably refers to files, environment variables, tools and paths that only exist on the old host. So I'm recording the active instructions with versions or hashes, listing their dependencies alongside, and mapping any host-specific paths explicitly. Then I'll check in a clean session on the destination with a read-only question. Does it load the right instructions, report the expected identity and follow a harmless standing rule?

For memory, an export is only one layer. The destination also needs the schema, indexes, embeddings, retrieval config and the links back to sources, otherwise the assistant keeps its records but can't find or verify them. I'm keeping durable records, correction history and source references in the backup, and treating a vector index as something to rebuild, which works as long as the embedding model and chunking rules are known. After import I'll ask for a known current decision, a superseded one and a source-linked record. Matching row counts won't show that graph relationships survived, so I'll also check counts by node and relationship type, look for dangling source references and run a few traversals with known results.

Tools are where the assistant's actual permissions sit. For each one I want to know whether it's read-only or can change an external system, how it authenticates, where its secret is stored and what approval rule applies. Secrets move through the secret store, never the general file copy, and anything without a clear owner gets rotated. Each tool also gets a small acceptance test that confirms the account, scope and target, so a valid credential for the wrong environment can't pass just because the HTTP call succeeded.

Scheduled work is easy to miss, because the assistant can look fine in an interactive session while its jobs are dead. I'm listing every worker and schedule with its timezone, command, service user, input queue and output location, then draining the old runner before turning on the new one so both machines don't pick up the same work. Host timezone, app timezone and how the schedule is interpreted all need to be written down, or a copied schedule can fire at the wrong local hour. My acceptance list is:

• services start after a reboot without an interactive login
• the assistant loads the intended instruction set
• current memory records and their sources can be retrieved
• obsolete memory doesn't override current state
• each required tool passes a scope-appropriate check
• one background job completes and leaves an inspectable record
• backups are created from the destination and can be read

What has to survive when the assistant moves machines comes down to a handful of things: the active instructions, memory with its source links, tools with the right scope and the scheduled jobs. Copying the prompt or the home directory won't carry most of that across, which is why the old host stays as it is until the acceptance list passes and the destination has produced its first usable backup. Next I'm finishing the component inventory and giving every item that can't simply be rebuilt one concrete recovery test, so I know each one actually made the move.