Skip to main content
migrate supports two migration modes:
  • Run a local structured migration for LangChain, LangGraph, ADK, Strands, or Bedrock AgentCore projects and generate an AgentKit app.
  • Start a remote migration job for a Dify Workflow, Dify Chatflow, or another type of agent project, then download the generated VeADK project when the job finishes.

Dify Migration Scope

With --framework dify create, the input path must be an existing directory and should contain at least one Dify DSL YAML document. The migration flow recursively scans .yml and .yaml files in that directory and treats a file as Dify only when its content matches the Dify DSL structure: the root object is kind: app, app contains a non-empty mode, and workflow.graph contains both nodes and edges lists. File names and directory depth are not part of detection; an ordinary YAML file named workflow.yml is not treated as Dify DSL by name alone. Before the remote migration starts, the CLI reads the matched Dify DSL and provides read-only context to the migration process: DSL version, app mode, nodes and edges, variables, app features, dependencies, diagnostics, and locations of truncated content. Credential fields and common authentication text are redacted. If the directory contains multiple valid Dify DSL files, migration selects the first path in lexicographic order and records the candidates in diagnostics. Node-level supplemental configuration is also matched by content: only YAML that can be associated with a main DSL node through node ID, node type, or explicit override fields is used as node supplemental configuration. Both Dify workflow and advanced-chat apps are in scope. For Chatflow, migration also pays attention to conversation variables, sys.query, sys.files, sys.conversation_id, LLM node memory windows, Answer node order, file upload, speech features, citation resources, and content moderation context.
This context helps migration understand the source graph; it does not mean every Dify node maps one-to-one to an AgentKit capability with the same name. Review the generated report and the source project behavior before accepting the result.

migrate

A local structured migration analyzes the entry object, generates the service entry point, deployment configuration, and migration plan in the source project, and updates project dependencies. The command reports the files it creates, updates, or overwrites. Use --dry-run to inspect the plan only.
This command modifies the source project. --force overwrites existing generated files. Commit or back up existing changes and inspect the plan with --dry-run first.

migrate create

Create a remote migration job for a Dify export or another agent project. The command uploads the source directory, creates a remote sandbox, returns the job ID, and leaves the job running in the background. If an active job already has the same workspace, source directory, and migration configuration, the command reuses it.
This operation uploads the source directory to a remote sandbox and may create billable cloud resources. Remove credentials, user data, and other files that must not be uploaded. The generated result must use a dedicated sibling directory; it cannot overwrite the source directory or be placed inside it.

migrate list

List locally stored Dify or Any migration job metadata for the selected workspace. This action does not query other workspaces or create cloud resources.

migrate status

Query a remote job. After a job succeeds, partially succeeds, or fails, this command downloads the result or failure report to the output directory selected at creation time. Later invocations reuse a local terminal result.
--overwrite replaces files that have already been downloaded to the result directory. Use it only when local changes do not need to be preserved.
Last modified on September 19, 2026