In this article
Chat exports preserve conversations; Workspace exports move selected definitions. Neither should be treated as a complete deployment backup or an idempotent import.
Open WebUI can export conversation history and move reusable workspace items, but these operations have different scopes. A chat transcript is not a complete definition of the assistant that produced it. Moving a model wrapper also does not move every conversation that used it or provision the external inference server.
Export the conversation history deliberately
The chat import and export guide places the controls under the profile menu, Settings and Data Controls. Use the documented conversation export when the goal is preserving messages and conversation structure. Keep the exported file alongside a note of the source application version.
Choose a small representative conversation for the first migration test. Include a branch if branching matters to the workflow. A readable list of final answers is less informative than checking whether the expected active branch and its preceding messages remain available after import.
Move workspace definitions separately
The Workspace guide distinguishes model wrappers, prompts, knowledge and other items. Its current Create menu provides section-specific import and export operations where supported. Permissions can hide an operation, so a missing menu entry does not necessarily mean the product lacks the capability.
Inventory the items needed by the migrated workflow. Export the supported definitions separately from chat history. Do not assume a conversation’s model name is a serialized copy of all workspace instructions, tools and resources that previously applied to it.
Resolve the base model on the target
The model workspace documentation describes wrapping a base model with instructions and other configuration. The target installation must still have an eligible connection and model identity. A wrapper’s display label cannot start an unavailable inference backend.
For a local assistant, confirm the target runtime is running and the wrapper resolves to the intended model. Then inspect attached knowledge and tools individually. A successful import dialog proves that an object was accepted, not that its dependencies became reachable or that access permissions are equivalent.
Treat repeated imports as new work
The chat guide documents that imported conversations receive fresh identifiers. Reimporting the same file creates additional conversations rather than synchronizing existing ones. Build a small import log so an interrupted migration does not become an unexplained collection of duplicates.
Check source and target counts together with titles and branches. If a migration needs retries, identify what has already been imported before trying again. Avoid treating a file timestamp as a stable conversation identity or deleting the original history merely because the target shows some messages.
Verify a complete workflow rather than one artifact
Open the imported conversation, inspect the expected history and run a new bounded question through the intended target model. Confirm workspace instructions and required resources separately. Document any omitted attachments or unsupported objects for the tested export path.
Keep the distinction from a server backup clear. Accounts, database state, external storage and runtime deployment can require other preservation mechanisms. A useful migration record states what each exported artifact contains and what the target still needs, rather than promising that one JSON file reproduces the entire installation.
Related reading
vLLM served-model-name: Fix a Missing API Model, llama.cpp server: a local API from a GGUF model.