There's no one-click selective migration tool, but you can recreate specific datasets and agents on Server B using the API. Here's a step-by-step approach:

For Agents (straightforward):

Agents are stored as JSON DSL and can be exported/imported via the API [1]:

1. On Server A, export the agent's DSL:

   GET http://serverA:port/api/v1/agents/<agent_id>
   Authorization: Bearer <api_key>
   

2. Save the dsl field from the response as a JSON file

3. On Server B, create the agent from the DSL:

   POST http://serverB:port/api/v1/agents
   Authorization: Bearer <api_key>
   Body: { "dsl": <saved_dsl_json> }
   

For Datasets (manual recreation):

There's no export/import endpoint for datasets, so you need to recreate them [2]:

1. On Server B, create the dataset:

   POST http://serverB:port/api/v1/datasets
   Body: { "name": "...", "chunk_method": "...", "embedding_model": "..." }
   

2. Re-upload your original documents to the new dataset via the document upload API

3. Trigger parsing/chunking — the documents will be re-embedded using Server B's configured embedding model

Important notes:

• The agent DSL may reference dataset IDs from Server A. You'll need to update these references in the DSL to point to the new dataset IDs created on Server B before importing.
• Make sure the same LLM and embedding models are configured on Server B.
• If your datasets are linked to connectors (S3, web, etc.), you can simply re-create the connector on Server B and rebuild — it will re-sync the data automatically [3].

Would you like help with the specific API calls or a script to automate this?

To reply, just mention @dosu.

Docs are dead. Just use Dosu.

What if I use migration.sh? Since I can guarantee that server A has everything that server B has, can I directly overwrite server B's data with server A's data? @dosu

Yes, docker/migration.sh is exactly the tool for this. It's a backup/restore script for RAGFlow's Docker volumes [1]. If Server A is the superset and you're fine completely replacing Server B's data, here's the process:

On Server A (backup):

cd docker
bash migration.sh backup

This creates a backup of mysql_data, minio_data, redis_data, and esdata01 [2].

Transfer the backup to Server B, then:

On Server B (restore):

# Stop all containers first
docker compose down

# Restore (this OVERWRITES all existing data)
bash migration.sh restore

The script will warn you that restoring completely overwrites Server B's data and ask for confirmation [3].

Important caveats:

• Same RAGFlow version required — Make sure both servers are running the same version. The script doesn't check for version/schema compatibility, so a mismatch could cause issues.
• This is a full replacement, not a merge — Everything on Server B (users, datasets, agents, documents) will be replaced with Server A's data.
• All containers must be stopped before restore [4].

Since you said Server A has everything Server B has, this is the fastest and simplest approach — much easier than the manual API-based recreation we discussed earlier.

To reply, just mention @dosu.

Docs are dead. Just use Dosu.

when i used agent, i got error:2026-07-24 14:54:04,754 ERROR 21 Unhandled exception during request
Traceback (most recent call last):
File "/ragflow/api/apps/canvas_app.py", line 335, in reset
canvas = Canvas(json.dumps(user_canvas.dsl), current_user.id, canvas_id=user_canvas.id)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/ragflow/agent/canvas.py", line 292, in init
super().init(dsl, tenant_id, task_id, custom_header=custom_header)
File "/ragflow/agent/canvas.py", line 90, in init
self.load()
File "/ragflow/agent/canvas.py", line 296, in load
super().load()
File "/ragflow/agent/canvas.py", line 105, in load
cpn["obj"] = component_class(cpn["obj"]["component_name"])(self, k, param)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/ragflow/agent/component/agent_with_tools.py", line 86, in init
LLM.init(self, canvas, id, param)
File "/ragflow/agent/component/llm.py", line 87, in init
self.chat_mdl = LLMBundle(self._canvas.get_tenant_id(), TenantLLMService.llm_id2llm_type(self._param.llm_id),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/ragflow/api/db/services/llm_service.py", line 87, in init
super().init(tenant_id, llm_type, llm_name, lang, **kwargs)
File "/ragflow/api/db/services/tenant_llm_service.py", line 383, in init
self.mdl = TenantLLMService.model_instance(tenant_id, llm_type, llm_name, lang=lang, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/ragflow/.venv/lib/python3.12/site-packages/peewee.py", line 3159, in inner
return fn(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^
File "/ragflow/api/db/services/tenant_llm_service.py", line 137, in model_instance
model_config = TenantLLMService.get_model_config(tenant_id, llm_type, llm_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/ragflow/.venv/lib/python3.12/site-packages/peewee.py", line 3159, in inner
return fn(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^
File "/ragflow/api/db/services/tenant_llm_service.py", line 113, in get_model_config
assert False, "LLM type error"
^^^^^
AssertionError: LLM type error

what is the reason? @dosu

The AssertionError: LLM type error means the LLM model configured in your agent node can't be resolved to a valid model type. The code tries to look up the llm_id stored in your agent's canvas, but it either can't find the model at all or gets an unexpected type back [1].

Most likely cause: Given your recent migration, the llm_id embedded in your agent's canvas DSL still references a model configuration from Server A that doesn't exist (or is registered differently) on your current server. Agent nodes store the llm_id inside the canvas JSON [2], so it doesn't get automatically updated when model configurations change.

How to fix:

1. Check your model setup — Go to Model Providers in the RAGFlow UI and verify that the LLM you're using (likely your Qwen3 model via vLLM) is properly registered and accessible.

2. Re-select the model in your agent node — Open your agent canvas, click on the LLM node that's failing, and re-select the model from the dropdown. This will update the llm_id in the canvas DSL to match your current server's model configuration.

3. Save and retry — Save the agent canvas and try running it again.

The root issue is that llm_id2llm_type() searches through multiple lookup paths (factory configs, LLM service, tenant LLM service) and returns None when nothing matches [3]. That None then hits the assertion because it's not one of the valid types (chat, embedding, rerank, etc.).

Did this start happening after the migration?

To reply, just mention @dosu.

Share context across your team and agents. Try Dosu.