Qdrant Migration Tool

Qdrant Migration Tool

The tool is a Docker container (registry.cloud.qdrant.io/library/qdrant-migration), not a library you import. It streams data in batches through the machine it runs on rather than connecting source and target directly, and it resumes by default rather than restarting from scratch. Migrate to Qdrant

Picking the Right Subcommand

Use when: starting a new migration and choosing the source-specific CLI subcommand.

• Match the source to its subcommand: pinecone, weaviate, milvus, elasticsearch, opensearch, pg (pgvector), s3 (S3 Vectors), azure (Azure AI Search), chroma, redis, mongodb, faiss, solr, or qdrant. Migrate to Qdrant
• Weaviate, Redis, MongoDB, and Apache Solr do not auto-create the target collection; create it in Qdrant first with matching vector size and distance metric before running the migration. All other sources auto-create it.
• Each source has its own credential and mapping guide; read it before running the migration, since concept mapping (namespaces, indexes, metadata fields) is source-specific. Pinecone Weaviate Milvus Elasticsearch OpenSearch Azure AI search pgvector S3 Vectors Chroma Redis MongoDB FAISS Apache Solr Qdrant-to-Qdrant
• Source not listed? Point to the GitHub issue tracker rather than improvising a custom pipeline. Open an issue

Running Against Local Instances

Use when: either the source or target database runs on the same machine as the migration container.

• Add --net=host to the docker run command; without it, the container cannot resolve localhost on the host machine. Migrate to Qdrant
• Run the container on a machine with low latency to both databases. Direct source-target connectivity is not required since the tool streams through wherever it runs, but round trips from the migration host to each database still add up.

Migration Was Interrupted

Use when: a migration stopped partway through and needs to continue, or needs to be re-run from zero.

• Re-run the exact same command. Progress is tracked in the _migration_offsets collection in Qdrant, so it resumes automatically rather than re-copying already-migrated points.
• Pass --migration.restart to discard saved progress and start over, e.g. after fixing a bad source-side filter or changing collection schema mid-migration.
• Custom offsets-collection name only matters if you're running multiple concurrent migrations into the same Qdrant instance; otherwise leave --migration.offsets-collection at its default to avoid tracking state you'll forget to look for later.

Migration Is Too Slow

Use when: throughput is too low for the size of the source dataset.

• Raise --migration.batch-size from the default of 50 to 256 or 512 for large migrations; small batches under-use each upsert round trip.
• --migration.num-workers only exists for the pg and qdrant subcommands; other sources have no parallel-worker flag, so throughput there is bounded by batch size and network proximity alone.
• --migration.batch-delay defaults to 0; only raise it deliberately to throttle load on a source database that can't absorb full-speed reads, not as a default tuning knob.
• Run the container close to both databases rather than over a slow network path, since the tool has no way to compensate for source/target latency.

After Migration

Use when: the migration command finished and data needs to be trusted before cutting over traffic.