Migration Tool on Qdrant - Vector Search Engine

From Pinecone

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Migrate from Pinecone to Qdrant

What You Need from Pinecone

API key — from the Pinecone console
Index name — the name of the index to migrate
Index host URL — the host endpoint shown in your index dashboard

Concept Mapping

Pinecone	Qdrant	Notes
Index	Collection	One-to-one mapping
Namespace	Payload field or separate collection	No direct equivalent — the tool migrates all namespaces. Use `--pinecone.namespace` to migrate a specific one
Metadata	Payload	Direct mapping
Sparse values	Sparse vectors	Mapped to `sparse_vector` named vector by default
`cosine`	`Cosine`	Direct mapping
`dotproduct`	`Dot`	Pinecone requires unit-normalized vectors for dotproduct
`euclidean`	`Euclid`	Direct mapping

Run the Migration

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration pinecone \
 --pinecone.index-host 'https://your-index-host.pinecone.io' \
 --pinecone.index-name 'your-index' \
 --pinecone.api-key 'pcsk_...' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection'

Migrating a Specific Namespace

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration pinecone \
 --pinecone.index-host 'https://your-index-host.pinecone.io' \
 --pinecone.index-name 'your-index' \
 --pinecone.api-key 'pcsk_...' \
 --pinecone.namespace 'my-namespace' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection'

All Pinecone-Specific Flags

Flag	Required	Description
`--pinecone.index-name`	Yes	Name of the Pinecone index
`--pinecone.index-host`	Yes	Host URL of the Pinecone index
`--pinecone.api-key`	Yes	Pinecone API key
`--pinecone.namespace`	No	Specific namespace to migrate
`--pinecone.service-host`	No	Custom Pinecone service host

Qdrant-Side Options

Flag	Default	Description
`--qdrant.id-field`	`__id__`	Payload field name for original Pinecone IDs
`--qdrant.sparse-vector`	`sparse_vector`	Named vector for Pinecone sparse values

Gotchas

Score scaling: Pinecone cosine similarity returns values in [0, 1] (rescaled). Qdrant returns [-1, 1]. Rankings are identical, but raw scores won’t match.
Metadata size limits: Pinecone limits metadata to 40KB per vector. Qdrant has no per-payload size limit, so data is preserved as-is.
Namespace strategy: If you have multiple namespaces, decide upfront whether to merge them into a single Qdrant collection (using a namespace payload field for filtering) or create separate collections.

Next Steps

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

From Weaviate

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Migrate from Weaviate to Qdrant

What You Need from Weaviate

Host URL — the Weaviate instance address
Class name — the class to migrate
Authentication — API key, username/password, or bearer token depending on your setup
Vector dimensions — Weaviate does not expose vector dimensions through its API, so you must know this value

Pre-Create Your Qdrant Collection

curl -X PUT 'https://your-instance.cloud.qdrant.io:6333/collections/your-collection' \
 -H 'api-key: your-qdrant-api-key' \
 -H 'Content-Type: application/json' \
 -d '{
 "vectors": {
 "size": 384,
 "distance": "Cosine"
 }
 }'

Replace 384 with your actual vector dimensions. Set the distance metric to match your Weaviate configuration.

From Milvus

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Migrate from Milvus to Qdrant

What You Need from Milvus

Milvus URL — the gRPC endpoint of your Milvus instance
Collection name — the collection to migrate
API key — if using Zilliz Cloud or authenticated Milvus

Concept Mapping

Milvus	Qdrant	Notes
Collection	Collection	One-to-one mapping
Partition	Payload field or separate collection	Use `--milvus.partitions` to specify which partitions to migrate
Schema fields	Payload	Non-vector fields become payload
`COSINE`	`Cosine`	Direct mapping
`L2`	`Euclid`	Direct mapping
`IP` (inner product)	`Dot`	Direct mapping
Dynamic fields	Payload	JSON-typed dynamic fields are preserved

Run the Migration

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

Migrating Specific Partitions

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration milvus \
 --milvus.url 'your-milvus-host:19530' \
 --milvus.collection 'your-collection' \
 --milvus.partitions 'partition_a,partition_b' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection'

All Milvus-Specific Flags

Flag	Required	Description
`--milvus.url`	Yes	Milvus gRPC endpoint
`--milvus.collection`	Yes	Collection name to migrate
`--milvus.api-key`	No	API key (for Zilliz Cloud)
`--milvus.username`	No	Username for authentication
`--milvus.password`	No	Password for authentication
`--milvus.db-name`	No	Database name
`--milvus.partitions`	No	Comma-separated partition names
`--milvus.server-version`	No	Override detected server version
`--milvus.enable-tls-auth`	No	Enable TLS authentication

Qdrant-Side Options

Flag	Default	Description
`--qdrant.distance-metric`	—	Distance metric per vector field (map format, e.g., `field1:cosine,field2:dot`)

Gotchas

Partition handling: Milvus partitions can map to Qdrant collections or payload filters. If you merge partitions into a single collection, add a partition name as a payload field for filtering.
Schema strictness: Milvus enforces schema on write; Qdrant is schema-flexible. Verify that the schema-less flexibility didn’t cause payload fields to drift during migration.
Dynamic fields: Milvus dynamic fields (introduced in 2.3) may serialize differently. Check that JSON-typed dynamic fields survived the migration with correct structure.

Next Steps

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

From Elasticsearch

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Migrate from Elasticsearch to Qdrant

What You Need from Elasticsearch

Elasticsearch URL — the HTTP endpoint
Index name — the index containing your vectors
Credentials — username/password or API key

Concept Mapping

Elasticsearch	Qdrant	Notes
Index	Collection	One-to-one mapping
Document	Point	Each document becomes a point
`dense_vector` field	Vector	Mapped automatically
Document fields	Payload	Non-vector fields become payload
`cosine`	`Cosine`	ES returns `1 - cosine_distance`; Qdrant returns cosine similarity directly
`l2_norm`	`Euclid`	Direct mapping
`dot_product`	`Dot`	Direct mapping

Run the Migration

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration elasticsearch \
 --elasticsearch.url 'https://your-es-host:9200' \
 --elasticsearch.index 'your-index' \
 --elasticsearch.username 'elastic' \
 --elasticsearch.password 'your-password' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection'

Using API Key Authentication

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration elasticsearch \
 --elasticsearch.url 'https://your-es-host:9200' \
 --elasticsearch.index 'your-index' \
 --elasticsearch.api-key 'your-es-api-key' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection'

All Elasticsearch-Specific Flags

Flag	Required	Description
`--elasticsearch.url`	Yes	Elasticsearch HTTP endpoint
`--elasticsearch.index`	Yes	Index to migrate
`--elasticsearch.username`	No	Username for basic auth
`--elasticsearch.password`	No	Password for basic auth
`--elasticsearch.api-key`	No	API key for authentication
`--elasticsearch.insecure-skip-verify`	No	Skip TLS certificate verification

Qdrant-Side Options

Flag	Default	Description
`--qdrant.id-field`	`__id__`	Payload field name for original Elasticsearch document IDs

Hybrid Search Considerations

If your Elasticsearch setup uses hybrid BM25 + kNN scoring, you’ll need to reconstruct this in Qdrant using sparse vectors (for BM25-like behavior) alongside dense vectors. The migration tool transfers the dense vectors; you’ll need to generate sparse vectors separately if you want hybrid search in Qdrant.

From OpenSearch

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Migrate from OpenSearch to Qdrant

What You Need from OpenSearch

OpenSearch URL — the HTTP endpoint
Index name — the index containing your vectors
Credentials — username/password or API key

Concept Mapping

OpenSearch	Qdrant	Notes
Index	Collection	One-to-one mapping
Document	Point	Each document becomes a point
`knn_vector` field	Vector	Mapped automatically
Document fields	Payload	Non-vector fields become payload
`cosinesimil`	`Cosine`	Direct mapping
`l2`	`Euclid`	Direct mapping
`innerproduct`	`Dot`	Direct mapping

Run the Migration

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration opensearch \
 --opensearch.url 'https://your-opensearch-host:9200' \
 --opensearch.index 'your-index' \
 --opensearch.username 'admin' \
 --opensearch.password 'your-password' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection'

Using API Key Authentication

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

All OpenSearch-Specific Flags

Flag	Required	Description
`--opensearch.url`	Yes	OpenSearch HTTP endpoint
`--opensearch.index`	Yes	Index to migrate
`--opensearch.username`	No	Username for basic auth
`--opensearch.password`	No	Password for basic auth
`--opensearch.api-key`	No	API key for authentication
`--opensearch.insecure-skip-verify`	No	Skip TLS certificate verification

Qdrant-Side Options

Flag	Default	Description
`--qdrant.id-field`	`__id__`	Payload field name for original OpenSearch document IDs

Gotchas

OpenSearch vs. Elasticsearch: OpenSearch is a fork of Elasticsearch, so many of the same considerations apply. However, the CLI subcommand is opensearch, not elasticsearch.
Score normalization: OpenSearch _score values are not directly comparable to Qdrant scores. Use rank-based metrics when verifying your migration.
Nested documents: OpenSearch nested documents need to be flattened or restructured for Qdrant’s payload model.

Next Steps

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

From pgvector

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Migrate from pgvector to Qdrant

What You Need from Postgres

Connection URL — a standard Postgres connection string
Table name — the table containing your vector data

Concept Mapping

pgvector	Qdrant	Notes
Table	Collection	One-to-one mapping
Row	Point	Each row becomes a point
`vector` column	Vector	Mapped automatically
Other columns	Payload	All non-vector columns become payload fields
`vector_cosine_ops`	`Cosine`	pgvector returns distance (1 - similarity); Qdrant returns similarity
`vector_l2_ops`	`Euclid`	Direct mapping
`vector_ip_ops`	`Dot`	pgvector uses negative inner product for ordering; scores will be inverted

Run the Migration

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration pg \
 --pg.url 'postgres://user:password@host:5432/dbname' \
 --pg.table 'your_embeddings_table' \
 --pg.key-column 'id' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection'

Selecting Specific Columns

By default, all columns are migrated. Use --pg.columns to select specific ones:

From S3 Vectors

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Migrate from S3 Vectors to Qdrant

What You Need from AWS

S3 bucket name — the bucket containing your vector data
Index name — the S3 Vectors index to migrate
AWS credentials — configured via aws configure or environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)

Set your AWS credentials using the AWS CLI's configure command or environment variables before running the migration container.

Run the Migration

docker run --net=host --rm -it \
 -e AWS_ACCESS_KEY_ID='your-access-key' \
 -e AWS_SECRET_ACCESS_KEY='your-secret-key' \
 -e AWS_REGION='us-east-1' \
 registry.cloud.qdrant.io/library/qdrant-migration s3 \
 --s3.bucket 'your-bucket-name' \
 --s3.index 'your-index-name' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection'

All S3 Vectors-Specific Flags

Flag	Required	Description
`--s3.bucket`	Yes	S3 bucket name
`--s3.index`	Yes	S3 Vectors index name

AWS credentials are passed via environment variables or the default AWS credential chain, not CLI flags.

From Chroma

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Migrate from Chroma to Qdrant

What You Need from Chroma

Chroma URL — the HTTP endpoint of your Chroma server
Collection name — the collection to migrate
Authentication — API token or basic auth credentials, if configured

Concept Mapping

Chroma	Qdrant	Notes
Collection	Collection	One-to-one mapping
Document	Point	Each document becomes a point
Embeddings	Vector	Mapped automatically
Metadata	Payload	Direct mapping
Documents (text)	Payload field	Stored via `--qdrant.document-field`

Run the Migration

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

With Authentication

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration chroma \
 --chroma.url 'https://your-chroma-host:8000' \
 --chroma.collection 'your-collection' \
 --chroma.auth-type token \
 --chroma.token 'your-chroma-token' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection'

All Chroma-Specific Flags

Flag	Required	Description
`--chroma.url`	No	Chroma HTTP endpoint (default: `http://localhost:8000`)
`--chroma.collection`	Yes	Collection name to migrate
`--chroma.tenant`	No	Chroma tenant
`--chroma.database`	No	Chroma database
`--chroma.auth-type`	No	`none`, `basic`, or `token` (default: `none`)
`--chroma.username`	No	Username (when auth-type is `basic`)
`--chroma.password`	No	Password (when auth-type is `basic`)
`--chroma.token`	No	Token (when auth-type is `token`)
`--chroma.token-header`	No	Custom header name for token auth

Qdrant-Side Options

Flag	Default	Description
`--qdrant.document-field`	`document`	Payload field name to store Chroma document text
`--qdrant.id-field`	`__id__`	Payload field name for original Chroma IDs
`--qdrant.distance-metric`	`euclid`	`cosine`, `dot`, `manhattan`, or `euclid`

Gotchas

Document text: Chroma stores raw document text alongside embeddings. Use --qdrant.document-field to preserve this text as a payload field in Qdrant.
ID mapping: Chroma uses string IDs. The migration tool maps these to Qdrant point IDs and stores the original Chroma ID in a payload field (default: __id__).
Distance metric: Chroma defaults to L2 distance. Verify which metric your collection uses and set --qdrant.distance-metric accordingly.

Next Steps

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

From Redis

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Migrate from Redis to Qdrant

What You Need from Redis

Redis address — host and port of your Redis instance
FT index name — the RediSearch full-text index that contains your vectors
Authentication — username and password, if configured

Concept Mapping

Redis	Qdrant	Notes
FT Index	Collection	One-to-one mapping
Document	Point	Each document becomes a point
Vector field	Vector	Named vectors are preserved
Hash/JSON fields	Payload	Direct mapping
Document key	Payload field	Stored via `--qdrant.id-field`

Run the Migration

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration redis \
 --redis.index 'your-ft-index' \
 --redis.addr 'localhost:6379' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection'

With Authentication

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration redis \
 --redis.index 'your-ft-index' \
 --redis.addr 'your-redis-host:6379' \
 --redis.username 'your-username' \
 --redis.password 'your-password' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection' \
 --migration.create-collection false

All Redis-Specific Flags

Flag	Required	Description
`--redis.index`	Yes	RediSearch FT index name
`--redis.addr`	No	Redis address (default: `localhost:6379`)
`--redis.protocol`	No	Redis protocol version (default: `2`)
`--redis.username`	No	Username for authentication
`--redis.password`	No	Password for authentication
`--redis.client-name`	No	Client name
`--redis.db`	No	Database number
`--redis.network`	No	Network type: `tcp` or `unix` (default: `tcp`)

Qdrant-Side Options

Flag	Default	Description
`--qdrant.id-field`	`__id__`	Payload field name for original Redis document keys

Gotchas

Named vectors: If your Redis index has multiple vector fields, all are migrated as named vectors. Ensure your pre-created Qdrant collection has a matching named vector configuration.
ID mapping: Redis document keys are converted to Qdrant point IDs. The original key is stored in the payload under --qdrant.id-field.

Next Steps

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

From MongoDB

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Migrate from MongoDB to Qdrant

What You Need from MongoDB

Connection string — MongoDB URI (e.g., mongodb://user:pass@host:27017)
Database name — the database containing your collection
Collection name — the collection to migrate
Vector field names — the names of fields that store vector embeddings

Concept Mapping

MongoDB	Qdrant	Notes
Collection	Collection	One-to-one mapping
Document	Point	Each document becomes a point
Vector field	Vector	Named vectors are preserved
Non-vector fields	Payload	Direct mapping
`_id` (ObjectID or string)	Point ID + Payload	Converted to UUID; original stored in payload

Run the Migration

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration mongodb \
 --mongodb.url 'mongodb://localhost:27017' \
 --mongodb.database 'your-database' \
 --mongodb.collection 'your-collection' \
 --mongodb.vector-fields 'embedding' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection'

With Multiple Vector Fields

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration mongodb \
 --mongodb.url 'mongodb+srv://user:pass@cluster.mongodb.net' \
 --mongodb.database 'your-database' \
 --mongodb.collection 'your-collection' \
 --mongodb.vector-fields 'title_embedding,body_embedding' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection' \
 --migration.create-collection false

All MongoDB-Specific Flags

Flag	Required	Description
`--mongodb.url`	Yes	MongoDB connection string
`--mongodb.database`	Yes	Database name
`--mongodb.collection`	Yes	Collection name
`--mongodb.vector-fields`	Yes	Comma-separated list of vector field names

Qdrant-Side Options

Flag	Default	Description
`--qdrant.id-field`	`__id__`	Payload field name for original MongoDB `_id` values

Gotchas

Vector field names are required: MongoDB has no schema-level marker for vector fields. You must explicitly list them via --mongodb.vector-fields.
ID mapping: MongoDB _id values (ObjectID or string) are converted to Qdrant UUIDs. The original value is stored in payload under --qdrant.id-field.

Next Steps

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

From FAISS

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Migrate from FAISS to Qdrant

What You Need from FAISS

Index file path — path to your FAISS index file
Distance metric — the metric used when the index was built (l2, inner product, etc.)

Important: Only non-quantized FAISS index types are supported. Quantized indexes (e.g., IndexIVFPQ) do not store the original vectors and cannot be migrated.

Supported Index Types

FAISS Index Type	Supported	Notes
`IndexFlatL2`	Yes	Maps to `euclid` distance
`IndexFlatIP`	Yes	Maps to `dot` distance
`IndexHNSWFlat`	Yes	Full vectors are stored
`IndexIVFFlat`	Yes	Full vectors are stored
`IndexIVFPQ`	No	Quantized — original vectors not stored
`IndexPQ`	No	Quantized — original vectors not stored

Concept Mapping

FAISS	Qdrant	Notes
Index	Collection	One-to-one mapping
Vector (by position)	Point	Position in index becomes point ID

Run the Migration

docker run --net=host --rm -it \
 -v /path/to/your/index:/data \
 registry.cloud.qdrant.io/library/qdrant-migration faiss \
 --faiss.index-path '/data/your-index.index' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection' \
 --qdrant.distance-metric cosine

All FAISS-Specific Flags

Flag	Required	Description
`--faiss.index-path`	Yes	Path to the FAISS index file (inside the container)

Qdrant-Side Options

Flag	Default	Description
`--qdrant.distance-metric`	`cosine`	Distance metric: `cosine`, `dot`, `euclid`, or `manhattan`

Gotchas

No metadata: FAISS indexes store only vectors. All points will have empty payloads. If you have a separate metadata store keyed by vector position, import that separately after migration.
Point IDs: Points are assigned IDs based on their position in the FAISS index. Use this to join with any external metadata store.

Next Steps

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

From Apache Solr

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Migrate from Apache Solr to Qdrant

What You Need from Solr

Solr URL — the base URL of your Solr instance (e.g., http://localhost:8983)
Collection name — the Solr collection to migrate
Authentication — username and password, if configured

Concept Mapping

Solr	Qdrant	Notes
Collection	Collection	One-to-one mapping
Document	Point	Each document becomes a point
Dense vector field	Vector	Named vectors are preserved
Non-vector fields	Payload	Direct mapping
Document ID (`id` field)	Payload field	Stored via `--qdrant.id-field`

Run the Migration

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

With Authentication

docker run --net=host --rm -it registry.cloud.qdrant.io/library/qdrant-migration solr \
 --solr.url 'https://your-solr-host:8983' \
 --solr.collection 'your-collection' \
 --solr.username 'your-username' \
 --solr.password 'your-password' \
 --qdrant.url 'https://your-instance.cloud.qdrant.io:6334' \
 --qdrant.api-key 'your-qdrant-api-key' \
 --qdrant.collection 'your-collection' \
 --migration.create-collection false

All Solr-Specific Flags

Flag	Required	Description
`--solr.url`	Yes	Solr base URL (e.g., `http://localhost:8983`)
`--solr.collection`	Yes	Solr collection name
`--solr.username`	No	Username for basic authentication
`--solr.password`	No	Password for basic authentication
`--solr.insecure-skip-verify`	No	Skip TLS certificate verification (default: `false`)

Qdrant-Side Options

Flag	Default	Description
`--qdrant.id-field`	`__id__`	Payload field name for original Solr document IDs

Gotchas

Named vectors: If your Solr schema has multiple dense vector fields, all are migrated as named vectors. Ensure your pre-created collection has matching named vector configurations.
ID mapping: Solr document IDs (strings) are converted to Qdrant UUIDs. The original Solr ID is stored in payload under --qdrant.id-field.

Next Steps

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

From Qdrant

info@qdrant.tech (Andrey Vasnetsov) — Mon, 01 Jan 0001 00:00:00 +0000

Migrate Between Qdrant Instances

Use the qdrant subcommand to copy a collection from one Qdrant instance to another — or between collections within the same instance. The tool automatically recreates the full collection schema (vector config, HNSW settings, quantization, sharding) on the target.

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

Source Qdrant	Target Qdrant	Notes
Collection	Collection	Recreated with exact schema
Named vectors	Named vectors	All vector types preserved
Sparse vectors	Sparse vectors	Direct mapping
Payload	Payload	Direct mapping
Payload indexes	Payload indexes	Recreated if `--target.ensure-payload-indexes` is `true`
Shard keys	Shard keys	Recreated automatically

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

Flag	Required	Description
`--source.collection`	Yes	Source collection name
`--source.url`	No	Source gRPC URL (default: `http://localhost:6334`)
`--source.api-key`	No	API key for the source instance
`--source.max-message-size`	No	Maximum gRPC message size in bytes (default: `33554432` = 32 MB)

All Target Flags

Flag	Required	Description
`--target.collection`	Yes	Target collection name
`--target.url`	No	Target gRPC URL (default: `http://localhost:6334`)
`--target.api-key`	No	API key for the target instance
`--target.ensure-payload-indexes`	No	Recreate payload indexes from source (default: `true`)

Parallel Worker Option

Flag	Default	Description
`--migration.num-workers`	Number of CPU cores	Number of parallel workers for migration

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.