What a Qdrant migration involves
This page covers two different jobs that teams often call a Qdrant migration. The first moves vectors and payloads from another vector store or search engine into self-hosted Qdrant using the Qdrant Migration Tool. The source can be Pinecone, Weaviate, Milvus, Elasticsearch, OpenSearch, pgvector, Chroma, Redis, MongoDB or FAISS. The second moves an existing collection from one Qdrant cluster to another using collection snapshots. Confirm which of these you are doing before scoping, because the risks, tooling and acceptance tests differ.
Common triggers include leaving a managed vector service, consolidating search onto one stack, moving off pgvector or Elasticsearch once vector workloads outgrow the original store, and relocating into a data center or air-gapped network that a hosted service cannot reach. Each trigger changes what the source system can export. Ask the source vendor what export formats and API limits apply to your account, and whether vectors, payloads and IDs can all be read back in full.
Most teams with a capable platform group run the move in-house for a small or single collection. Teams often bring in a partner when the migration spans several collections, when the source is a managed service with restricted export, or when search results must be proven equivalent before cutover. Whichever route you choose, the written scope should name the source, the collections, the acceptance tests and who signs off the cutover. Quotes should separate the one-time migration effort from the recurring platform costs that follow.
What the work includes
A migration to self-hosted Qdrant moves vectors and payloads from a source system and proves the results match before users depend on them. Each stage below is scoped in writing before work starts.
Source inventory and mapping
We catalog every source collection or index, its vector dimensions, distance metric, payload fields and the queries that depend on them. Each source field is mapped to a Qdrant payload field or index, and gaps such as unsupported types or missing IDs are logged before any data moves.
Target collection and payload design
We design the target Qdrant collections for the migration, including vector configuration, payload indexes for the filters your queries use, shard count and replication factor. Decisions here are hard to change later, so they are reviewed with your team before the first batch runs.
Batched migration with resume
The Qdrant Migration Tool streams data in batches and can resume an interrupted run. We set batch size and concurrency against the capacity of your source and target, record checkpoints, and confirm the target point count after each stage so a failed run restarts from a known position.
Embedding consistency checks
We compare migrated vectors with the source for a sample of records and across full collections, checking dimensions, distance metric, normalization and data types. This catches cases where an embedding model, precision or preprocessing step changed during transfer, which would silently degrade search quality.
Search result verification against the source
We run a fixed set of representative queries, with and without filters, against both systems and compare the ranked results. Differences are reviewed with your team, since small ranking changes can be expected from index differences while missing or filtered-out records are defects.
Cluster-to-cluster snapshot transfers
When moving between Qdrant clusters, we use collection snapshots and check the version rules first: a snapshot restores only to a cluster on the same minor version or the next one. We confirm storage location, transfer integrity and shard layout on the receiving cluster.
Cutover and rollback plan
We agree the cutover sequence, the freeze window for writes, the traffic switch and the criteria for going back to the source. The rollback plan states what must be preserved on the source and how writes made on the new cluster are handled if a reversal is needed.
Deliverables you keep
You receive the migration runbook, the mapping specification, reconciliation reports, verification results and a signed-off cutover record. These documents let your own team repeat, audit or reverse the migration without depending on us.
What drives cost and duration
This table lists the effort drivers in a Qdrant migration, why each one changes the work, and how to keep it manageable when you request a scoped quote.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Source systems and collections | Each source has its own export format, authentication and field mapping, so every collection needs separate mapping and validation. | Inventory sources and collections first, and merge or drop unused collections before mapping starts. |
| Total vector count and dimensions | Upload time, staging disk and memory needs grow with vector count and dimension size. | Ask for exact counts and dimensions per collection, and test a sample batch before estimating the full run. |
| Payload size and nested metadata | Large or deeply nested payloads increase transfer time and storage, and nested fields require flattening decisions. | Remove unused fields, flatten nesting you do not query, and measure payload size on a representative sample. |
| Filtering fields and payload indexes | Every field used in filters must map to a Qdrant payload index, which adds index build time and disk use. | List the filters the application actually runs, and index only the fields those queries use. |
| Re-embedding | Re-embedding calls the embedding model for every record, adding compute, time and a retrieval test for the new model version. | Keep existing vectors when the model and dimensions match, and confirm this with the application owner before the project starts. |
| Number of target environments | Each environment repeats loading, verification and access setup, so effort multiplies with every added tier. | Run one scripted load and verification process per environment, and promote configuration through your normal pipeline. |
| Cluster topology | A replication factor of 2 doubles stored data, and Qdrant requires block storage that network file systems and object storage cannot provide. | Size storage for doubled data, confirm block-level volumes early, and plan at least three nodes for production quorum. |
| Compliance evidence needs | Assessors may expect data mapping records, access control settings, audit logs and migration verification results, adding documentation work. | Agree the evidence list before build, including API key or JWT settings, audit log retention and verification reports. |
| Downtime tolerance | A zero-downtime cutover needs dual running, delta synchronization and a switch plan, while a write freeze window simplifies the work. | Agree in writing whether a write freeze is acceptable, and confirm what the source platform supports for delta sync. |
Migration phases and outputs
The sequence moves vectors and payloads into self-hosted Qdrant in controlled stages, with a written record at each phase so counts, payloads and search results can be checked before the source is retired.
Inventory the source and its data
We catalog the source system (Pinecone, Weaviate, Milvus, Elasticsearch, OpenSearch, pgvector or another supported source), its collections or indexes, vector dimensions, distance metrics, payload fields, record counts and the applications that query it. The output is a source inventory and a list of open questions for your team to confirm, which is complete when the client signs off on it.
Design the target and field mapping
We design the Qdrant collections, vector configuration, payload fields and indexes that filtering needs, then write a field mapping sheet that links each source field to its target. Sharding and replication are set against your node count. The mapping sheet, with decisions on types, IDs and metric choices, is approved before any data moves.
Build staging and run a trial migration
We stand up a staging Qdrant environment in your infrastructure and run the Qdrant Migration Tool against a representative sample. The trial shows which mappings, types and batch settings need adjustment. The output is a trial migration log listing errors, rejected records and the fixes applied, and the run is repeated until the sample loads cleanly.
Run the full migration in batches
We migrate the full dataset in batches with resume enabled, so an interrupted run continues from its last point instead of restarting. Each batch writes a progress record that shows source counts, loaded counts and any failed IDs. The step closes when every batch has completed and the failure list is empty or explained.
Verify counts, payloads and search results
We reconcile record counts per collection, compare sampled payloads field by field, and run a set of reference queries against both systems to compare returned IDs and ranking. Filtered queries are included. The output is a reconciliation report and a verification log, and differences are resolved or accepted in writing before cutover.
Cut over and run in parallel
Applications are pointed at Qdrant while the source stays readable for an agreed parallel period, so rollback is possible. We monitor query behavior and error rates during that window. The cutover record captures the switch time, configuration changes, rollback criteria and sign-off. Confirm the length of the parallel period with your team, as it depends on your risk tolerance.
Take a final backup and decommission the source
Once parallel running ends cleanly, we take a snapshot of the migrated Qdrant collections, store it in your backup location, and then retire the source system according to your data retention policy. The decommissioning record lists what was removed, where backups are kept and who approved the change. Duration of the whole sequence depends on the effort drivers and is set in the written scope.
What usually goes wrong
These failure points come up in moves to self-hosted Qdrant. Each card names the early signal to check before or during cutover.
Embeddings from a different model
If the target collection receives vectors from a different embedding model or a different dimension than the source, searches still return results, but relevance shifts without an error. Confirm the model name, version and vector size for every source collection, then compare top results for a set of known queries on source and target before cutover.
Payload fields that do not map
Nested objects, arrays and mixed value types in source payloads may not carry over cleanly, so values can be dropped, flattened or stored with an unexpected type. Export a sample of records with nested fields, run the Qdrant Migration Tool on that sample, and compare field counts and values in the target.
Missing payload indexes after cutover
Filtered searches on fields without a payload index can become slow once live traffic moves to the new cluster, even when unfiltered queries perform well. List every filter your application sends, create indexes for those fields, and time filtered queries against a copy of the data under realistic concurrency before cutover.
Snapshot restores and rollback
Qdrant snapshots restore only to clusters on the same minor version or the next minor version, so a snapshot from an older release may not load into the target. Record source and target versions in the runbook, rehearse a snapshot restore, and document a return path to the source cluster that covers writes made after cutover.
Data directory on network storage
Qdrant needs block-level storage with a POSIX-compatible file system, so network file systems such as NFS and object storage such as S3 are not supported for the data directory. Object storage can hold snapshots since v1.10.0, but not live data. Confirm the volume type and file system on each node, and prefer local SSD or NVMe.
Open instances during the migration
By default, self-deployed Qdrant listens on all network interfaces and has no authentication configured. A migration adds temporary clusters, tool containers and open ports that can outlive the job. Before loading data, set an admin API key, restrict network access to the migration hosts, and test the target ports from outside that network.
What to keep in-house and what to outsource
This table lists each part of a Qdrant migration, who usually owns it, and the skills it requires, so you can see where your team should hold decisions and where a partner can carry tooling and runbook work.
| Migration part | Usually owned by | Skills it needs |
|---|---|---|
| Source access and export permissions | Your platform or data team, with the source system owner | Admin rights on the source (Pinecone, Weaviate, Milvus, Elasticsearch, OpenSearch, pgvector or another), network access rules, credential handling |
| Mapping decisions (collections, vector fields, payload fields) | Application team, with a partner reviewing feasibility | Knowledge of current data model, understanding of how queries use payload fields, Qdrant collection and payload design |
| Embedding decisions (reuse or re-embed, model version) | Application or ML team | Embedding model knowledge, understanding of vector dimension and distance metric, relevance evaluation |
| Migration Tool runs (configuration, batching, resume) | Partner, with your team present for source-side checks | Qdrant Migration Tool configuration, container or binary operation, logging and error triage |
| Verification design (what counts as a match) | Partner builds the checks; application team sets acceptance criteria | Test query design, result comparison methods, sampling strategy, reading recall and ranking differences |
| Cutover coordination (timing, rollback, dual running) | Your change management and application owners, with partner runbook | Release management, traffic switching, rollback planning, communication with service owners |
| Application changes to query clients | Application team owns query behavior; partner supports client code changes | Client SDK use, filter and query syntax, relevance tuning, regression testing of search results |
| Source decommissioning | Your data owner and security team | Data retention policy knowledge, deletion evidence, access revocation, vendor contract handling |
How the work changes by starting point
Moving from a managed service such as Pinecone means the source is a hosted API, so extraction depends on what the provider's export interface allows and on your API limits. Mapping focuses on how namespaces, metadata and sparse data translate into Qdrant collections and payloads.
- Extraction: Confirm the export path, rate limits and whether vectors and metadata can be read back in full.
- Mapping: Decide whether each namespace becomes a collection, a payload field or a separate tenant, and fix the distance metric and vector dimension before the first batch.
- Verification: Compare record counts per namespace, then run a sample of known queries against both systems and review the overlap of top results.
- Cutover: Plan a period where writes go to both systems, because the source keeps changing while data is copied.
- Confirm with the vendor: Export limits, index deletion rules, retention after plan changes, and whether metadata filters have documented equivalents in Qdrant.
Moving from pgvector, Elasticsearch or OpenSearch means vectors sit beside relational or document data. Extraction is a query against tables or indices, so the work centers on choosing which columns or fields become vectors and which become payload.
- Extraction: Select the vector column or field and the identifiers that must survive, and check that the query returns stable, paged results.
- Mapping: Decide which relational columns or document fields become payload, and which stay in the source for joins that Qdrant does not replace.
- Verification: Reconcile row or document counts and spot-check filtered queries, since filter semantics often differ between SQL, Lucene-based queries and Qdrant filters.
- Index settings: Confirm the approximate search algorithm and recall you had before, and tune Qdrant index settings against a test set.
- Confirm with the source team: Whether vectors are stored in a format the tool reads directly, and whether application code also depends on the database for non-vector queries.
Moving from Weaviate, Milvus or Chroma usually means the source has its own schema, collection model and index types. Extraction is often simpler because the data is already vectors with payloads, but the mapping has to reconcile concepts that do not line up one to one.
- Extraction: Confirm the collection or class names, the vector fields (including named or multiple vectors) and whether IDs are preserved.
- Mapping: Translate the source schema into Qdrant collections, named vectors and payload indexes, and note any source features with no direct Qdrant equivalent.
- Verification: Compare counts per collection, then compare top-k results for a fixed query set, accounting for approximate search differences.
- Embedding consistency: Confirm the same embedding model and version produced the stored vectors, so queries from the application return comparable scores.
- Confirm with the source vendor: Export formats, the supported vector types for each collection, and any multi-tenancy or hybrid search features the application uses.
Moving between self-hosted Qdrant clusters uses snapshots rather than the Migration Tool. Collection snapshots are tar archives of one collection on one node, and full-storage snapshots apply only to single-node deployments, so the topology of source and target shapes the procedure.
- Extraction: Create snapshots for each collection, store them on protected storage, and record the source version and shard layout.
- Version rule: Restore only to a cluster on the same minor version or the next minor version, so plan any upgrade as a separate step.
- Mapping: Confirm that shard count and replication factor on the target suit its node count, since these settings are part of the target design.
- Verification: Compare point counts, payload samples and query results per collection after restore, and rerun your query test set.
- Confirm with your team: Where snapshots are stored (including any S3-compatible target), who may access them, and how they are deleted after cutover.
Two deployment targets change the procedure more than the source does. Kubernetes adds storage and upgrade requirements, and an air-gapped network removes access to external registries and the internet, so every image and snapshot must be carried in.
- Kubernetes: Confirm the storage class provides block storage with a POSIX-compatible file system, since Qdrant cannot run on NFS or object storage, and plan rolling upgrades around the Helm chart or enterprise operator you choose.
- Air-gapped transfer: Move the Migration Tool image, the Qdrant image and snapshot archives across the boundary through your approved media process, and record checksums on each side.
- Verification: Repeat the count and query checks inside the isolated network, because external services used for comparison may be unavailable.
- Operations: Confirm how security patches reach a closed environment and how the release notes for each version are reviewed before import.
- Confirm with your platform team: Registry mirroring rules, available storage performance, and whether the chosen Qdrant release is approved for the network.
What you need to provide
The migration starts only when the client has committed the inputs below. Each one removes a specific risk from the Qdrant Migration Tool run and from the cutover that follows it. Confirm them in writing before the schedule is fixed, because most delays come from items that were assumed to exist rather than checked. First, provide read access to the source system with export rights, such as a Pinecone index, Weaviate class, Milvus collection, Elasticsearch or OpenSearch index, or pgvector table. Without export rights, the tool cannot stream vectors and payloads in batches, and the team is left with API-level exports that are slower and harder to verify.
Second, provide sample data and representative queries with expected results. These are the basis for verification after migration. Ask your application owners for a set of queries that matter to users, with the top results they expect, including queries that use payload filters. If this set is missing, the team can confirm that record counts match but cannot show that search results still behave the same way. Third, document the embedding model and its exact version. Vectors from different models or versions are not comparable, so any change in the model during migration silently breaks similarity search. Name the model, dimension count, distance metric and any preprocessing used at ingestion.
Fourth, name the target environment: a cloud account, data center or Kubernetes cluster. Qdrant needs block-level storage with a POSIX-compatible file system, SSD or NVMe is recommended, and network file systems or object storage cannot be used for data. Confirm the storage class and capacity you can provide. Also provide network and access rules, including which subnets may reach Qdrant, how the application and migration host connect, and whether the instance will be secured with API keys or TLS before any data is loaded, since Qdrant listens on all interfaces by default. Fifth, name owners for data, application changes and cutover approval. Each owner must have authority to decide. A missing data owner delays decisions on which collections and payload fields move, and a missing cutover approver means no one can sign off the switch.
Frequently asked questions
How much does a migration to self-hosted Qdrant cost?
The cost depends on the size and shape of your data, the source platform, how much transformation the payloads need, and the environment you deploy into. The engine itself is open source under Apache-2.0 and free to self-host, so the cost is the work to plan, move, verify and hand over, plus the infrastructure you run. Costs are one-time for the migration and recurring for the infrastructure and any support retainer. Ask for a quote built from a written scope that lists the source, collection count, vector and payload volume, embedding strategy, target cluster layout and verification method.
How long does a Qdrant migration take?
Duration depends on the effort drivers: the number of collections, total vector and payload volume, whether embeddings are reused or regenerated, the source platform's export options, network and storage limits, and how many environments need validation. DeployOpen does not publish a fixed timeline. The duration is set in the written scope after the source and target are assessed, and it should state which phases are included, such as a pilot collection, full cutover and post-migration verification.
Can our team migrate to Qdrant without a partner?
Yes, for simple cases. A small number of collections with straightforward payloads can often be moved with the Qdrant Migration Tool, which runs as a container or binary, streams data in batches and resumes interrupted runs. Bring in help when collections are large, embeddings must be regenerated, payload schemas need reshaping, the cluster is distributed with replication, or search results must be proven equivalent before cutover. Your team should first confirm the tool supports your exact source version.
Do embeddings have to be regenerated during a migration?
Not always. If the source stores the vectors you already use, and your embedding model and dimensions stay the same, the vectors can be moved as they are. Regeneration is needed when you change embedding models, dimensions or distance metrics, or when the source does not expose stored vectors in a usable form. Confirm the model name, version, vector size and distance metric in both systems before you decide, because a mismatch is the most common cause of altered results.
Will search results be identical after migration, and how is that verified?
Identical results are not guaranteed, because approximate nearest neighbor search, index parameters, payload indexing and filter behavior can differ between platforms. Verification compares a fixed set of representative queries, with and without filters, against the source and target, and measures overlap in the top results and differences in ranking and payload. The acceptance criteria should be agreed in writing before the cutover, and the test set should include real user query patterns.
Can snapshots move between Qdrant versions?
Snapshots can be restored only to clusters running the same minor version or the next minor version, according to the Qdrant snapshot documentation. This means a snapshot from one minor release cannot simply be restored several minor versions ahead. For upgrades, plan a sequence of minor-version steps and take a snapshot before each change. Check the release notes for the version you are moving to, and confirm the exact rule for your build before you rely on it.
What must our team provide on day one?
Expect to provide access to the source system with read permissions, a target environment in your cloud account, data center or air-gapped network, the infrastructure requirements the storage guidance calls for, and named owners for identity, network and data decisions. Storage must be block-level with a POSIX-compatible file system, not NFS or S3, and SSD or NVMe is recommended. You should also provide sample queries, acceptance criteria, a change window and a rollback owner.
How DeployOpen runs Qdrant migrations
DeployOpen scopes, builds, verifies and hands over each move into self-hosted Qdrant inside infrastructure you control, whether the source is another vector database or a snapshot from an existing Qdrant cluster. Engagements are fixed-scope, with the scope agreed in writing before work starts.
How we scope
- Inventory the source system, collections, vector dimensions, distance metrics and payload fields that must carry over unchanged.
- Confirm the source (Pinecone, Weaviate, Milvus, Elasticsearch, pgvector or another supported origin) and the Qdrant version and deployment path before migration begins.
- Agree in writing which collections, payload indexes, access rules and search-result checks are in the migration and which are excluded.
How we build
- Run the Qdrant Migration Tool in batches, with a staging cluster used first so throughput and resume behavior are observed before production.
- Size storage on block-level SSD or NVMe, not network file systems or object storage, and set shard count and replication factor for the target cluster.
- Move collections between Qdrant clusters with snapshots, checking that source and target minor versions are compatible before each restore.
How we hand over
- Verify migrated results by comparing sample queries, filtered searches and record counts between the source system and the new Qdrant collections.
- Document the migration runbook, collection configuration, API key and access setup, and snapshot locations so your team can repeat or audit the move.
- Walk your engineers through the cutover steps, rollback path and post-migration checks, then record sign-off against the agreed scope.
How we support
- Keep a backup or snapshot of each migrated collection before any later change, so a failed upgrade or bad import can be reversed.
- Offer ongoing support, upgrades and testing as a retainer after go-live if your team wants DeployOpen to keep operating the cluster.
- Ask for a quote that separates one-time migration work from recurring operational support, and confirm which items each covers.
