Migrate Between Qdrant Instances

Use the qdrant subcommand to copy a collection from one Qdrant instance to another or copy data between collections within the same instance.

If the target collection does not exist, the tool automatically creates it using the source collection’s configuration (vector config, HNSW settings, quantization, sharding). To change the target collection’s configuration, create the target collection manually before running the migration.

What You Need

• Source Qdrant URL — gRPC endpoint of the source instance
• Target Qdrant URL — gRPC endpoint of the target instance
• Source collection name
• Target collection name (must be different from source if using the same instance)
• API keys — for each instance, if authentication is enabled

Concept Mapping

Run the Migration

Between Two Instances

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration qdrant \
    --source.url 'http://source-instance:6334' \
    --source.api-key 'source-api-key' \
    --source.collection 'your-collection' \
    --target.url 'https://your-instance.cloud.qdrant.io:6334' \
    --target.api-key 'your-qdrant-api-key' \
    --target.collection 'your-collection'

Within the Same Instance

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration qdrant \
    --source.url 'http://localhost:6334' \
    --source.collection 'original-collection' \
    --target.url 'http://localhost:6334' \
    --target.collection 'new-collection'

With Parallel Workers

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration qdrant \
    --source.url 'http://source-instance:6334' \
    --source.api-key 'source-api-key' \
    --source.collection 'your-collection' \
    --target.url 'https://your-instance.cloud.qdrant.io:6334' \
    --target.api-key 'your-qdrant-api-key' \
    --target.collection 'your-collection' \
    --migration.num-workers 4

All Source Flags

All Target Flags

Parallel Worker Option

Gotchas

• Source and target must differ: You cannot migrate a collection to itself.
• Parallel workers and resume: Migration progress is tracked per worker. If you change --migration.num-workers between runs, the saved offsets are invalidated and the migration restarts from scratch. Use --migration.restart explicitly if you intentionally want to change the worker count.
• Large messages: If you encounter gRPC message size errors, increase --source.max-message-size.
• Existing target collection: If the target collection already exists, the tool uses it as-is without modifying the schema.

Next Steps

After migration, verify your data arrived correctly with the Migration Verification Guide.