Backup and Migration

Back up the readable artifacts and the daemon application data together. The readable side gives you pages, sessions, status records, and local git history. The daemon data side keeps the database, index, config, and service-facing state.

A backup that only includes ~/.wenlan may preserve useful Markdown, but it should not be treated as a complete live runtime restore.

Wenlan memory can contain project decisions, private preferences, client names, sensitive repo details, and old versions preserved by local git history.

Do not put backups in a shared cloud folder, public issue, or team drive unless that is an intentional data-governance decision.

Install the Wenlan runtime on the new machine first, then restore the backed-up data into the matching platform locations.

MCP client settings may contain absolute paths to wenlan-mcp. After migration, rerun wenlan mcp add for each client instead of assuming old settings still point to the right binary.

Do not judge a migration from file presence alone. Verify the daemon can read the store, the MCP connector can reach the daemon, and the client can recall a known fact.

If doctor reports path or service problems, fix those before capturing new production memories on the restored machine.

If you cannot restore the daemon immediately, the projected Markdown under ~/.wenlan is still useful as a human-readable fallback.

That fallback does not provide capture, recall, distill, review, forget, or index updates. Treat it as readable continuity, not a full Wenlan runtime.

Uninstalling Wenlan's service does not delete memory data. Deleting memory data is a separate decision because it can remove the only local record of project history.

When removing Wenlan permanently, review what is in ~/.wenlan and the daemon data directory first. For normal troubleshooting, keep the data and use doctor output to diagnose the install.