Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsSome links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
Elasticsearch reindexing copies documents from a source index, alias, or data stream into a different destination. It is a copy-and-index operation—not a rename—and it does not copy the source index’s mappings, settings, shard count, or replica configuration. Create and configure the destination first, reindex the documents, validate the result, and only then route production traffic to it. For an alias-based cutover, coordinate writes separately: an atomic alias change prevents a gap in the read target, but it does not capture writes made while the copy is running.
When should you reindex?
Reindex when existing documents need to be indexed under a different configuration or representation. Typical reasons include:
- Changing an existing field to an incompatible type, such as
texttokeyword, or changing object structure to or fromnested. - Applying a different analyzer, tokenizer, normalizer, or synonym strategy to already-indexed text.
- Changing the number of primary shards or other index-wide configuration that requires a new index.
- Converting, normalizing, renaming, or removing values in historical documents.
- Applying corrected mappings or templates, rebuilding for new search requirements, or moving selected data to another index, cluster, or environment.
- Reprocessing documents through an ingest pipeline or migrating existing data-stream backing indices.
Not every schema change requires a rebuild. Adding a new mapping field is often possible in place, and some index settings are dynamic. Reindex when the values already stored need to be interpreted differently or the required change cannot safely be made to the existing index. Changing an analyzer definition alone does not retroactively rebuild the terms already indexed for existing documents.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
What the Reindex API does—and does not do
The API reads documents from a source and indexes them into a different destination. The source can be an index, alias, or data stream; source documents must have _source enabled. You can copy all documents or filter them, and you can transform documents with a script or ingest pipeline. The destination must differ from the source. See Elastic’s Reindex documents API for source, destination, permissions, and remote-reindex requirements.
#1 Best Overall
Reindexing does not copy index configuration. Prepare the destination’s mappings, analysis, shard and replica settings, templates, routing, and other required configuration explicitly. A successful request is not proof that every document was copied: inspect failures and conflicts, then validate the destination against the application’s actual queries.
| Operation | Use it for |
|---|---|
_reindex |
Copying documents to a different destination, especially when its configuration or document shape differs. |
_update_by_query |
Changing selected documents in the same index when its mapping remains suitable. |
| Refresh | Making already-indexed changes searchable; it does not rebuild mappings or reprocess documents. |
| Rollover | Moving writes to a new index when age, size, or document-count conditions are met; it does not rebuild historical documents. |
| Snapshot and restore | Backup, recovery, or moving index data and Elasticsearch-managed structures; use reindex instead when documents must be filtered or transformed. |
| Force merge | Optimizing segments; it does not change mappings or reprocess documents. |
Prepare the destination before copying
Create the destination deliberately rather than relying on automatic index creation or assuming the intended template will be applied. The following example is illustrative; choose settings and mappings for your workload.
PUT /products-v2
Content-Type: application/json
{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1,
"analysis": {
"analyzer": {
"product_text": {
"type": "custom",
"tokenizer": "standard",
"filter": ["lowercase"]
}
}
}
},
"mappings": {
"properties": {
"name": {
"type": "text",
"analyzer": "product_text",
"fields": { "keyword": { "type": "keyword" } }
},
"price": {
"type": "scaled_float",
"scaling_factor": 100
}
}
}
}Before starting, verify the effective configuration and operational prerequisites:
- Check the destination’s mapping, analysis, shard and replica configuration, and intended index or component templates. For example:
GET /products-v2/_settingsandGET /products-v2/_mapping. - Confirm the destination’s ingest pipeline, routing rules, index sorting, and lifecycle or data-stream configuration where relevant.
- Test the mappings and any transformations against representative documents. Consider strict dynamic mapping when unexpected fields must not silently acquire an unintended type.
- Plan disk capacity for both source and destination to coexist, plus replicas, segment merges, translog and recovery overhead, and any rollback copy. The required headroom varies by data and configuration.
- Ensure the caller can read the source and write to the destination; automatic destination creation requires additional privileges. For remote reindexing, source-side access is also required.
Test with a representative subset
A small trial can reveal mapping errors, bad transformations, and unexpected query behavior before the full copy. Filter the source or use a document limit, then inspect the destination and test it with representative application queries.
POST /_reindex
Content-Type: application/json
{
"max_docs": 1000,
"source": { "index": "products-v1" },
"dest": { "index": "products-v2-test" }
}Use a subset that represents important field shapes and edge cases; an arbitrary sample may miss rare malformed or unusually large documents. Treat a test destination as disposable until its mappings, transformation results, and search behavior are verified.
Run a production reindex asynchronously
For a long-running migration, request asynchronous execution so a client or proxy timeout does not end the wait for the response. The API returns a task ID:
POST /_reindex?wait_for_completion=false
Content-Type: application/json
{
"source": { "index": "products-v1" },
"dest": { "index": "products-v2" }
}Monitor the returned task and list active reindex operations with these Task Management requests:
GET /_tasks/<task_id>
GET /_tasks?actions=*reindexCheck whether the task is complete and review its counts, batches, retries, throttling information, version conflicts, and failures. A task can have written part of the destination before an error or cancellation, and a completed task can still report partial failures. Keep the destination out of production until those results are understood. Elastic’s Reindex indices examples document asynchronous operation, task inspection, slicing, and throttling.
Rank #2
Throttle to protect live traffic
Set a request rate when migration work competes with production searches or writes. The value below is an example, not a universal safe rate:
POST /_reindex?wait_for_completion=false
Content-Type: application/json
{
"source": { "index": "products-v1" },
"dest": { "index": "products-v2" },
"requests_per_second": 500
}You can change the rate of an existing reindex task:
POST /_reindex/<task_id>/_rethrottle?requests_per_second=100Throttle if CPU, disk I/O, heap, search latency, or indexing latency is under pressure. A lower rate trades elapsed time for reduced load; it does not replace capacity planning.
Use slicing cautiously
Slicing can parallelize source scanning. Start conservatively and observe the cluster before increasing concurrency:
POST /_reindex?wait_for_completion=false
Content-Type: application/json
{
"source": { "index": "products-v1" },
"dest": { "index": "products-v2" },
"slices": 4
}More slices can raise search and bulk-indexing load, heap use, disk use, segment creation, and contention with live traffic; they do not guarantee a faster migration. If you combine slicing with max_docs, the final count can be slightly below that limit because work is divided among slices and the data distribution may be uneven.
Filter or transform documents when needed
Copy only matching documents
A source query can select a time range, tenant, or other subset. Confirm that the query field and its semantics match the intended selection; a timestamp boundary, for example, must be interpreted consistently.
POST /_reindex?wait_for_completion=false
Content-Type: application/json
{
"source": {
"index": "events-v1",
"query": {
"range": {
"@timestamp": {
"gte": "now-30d"
}
}
}
},
"dest": { "index": "events-v2" }
}Modify documents with a script or pipeline
A Painless script can transform each document during reindexing. For example, this lowercases a present email field and removes another field by assigning null:
Recommended Free Tools
POST /_reindex?wait_for_completion=false
Content-Type: application/json
{
"source": { "index": "customers-v1" },
"dest": { "index": "customers-v2" },
"script": {
"lang": "painless",
"source": "if (ctx._source.email != null) { ctx._source.email = ctx._source.email.toLowerCase(); } if (ctx._source.remove_me != null) { ctx._source.remove_me = null; }"
}
}For a reusable transformation, define and test an ingest pipeline, then name it in the destination:
PUT /_ingest/pipeline/normalize-customers
Content-Type: application/json
{
"processors": [
{ "lowercase": { "field": "email", "ignore_missing": true } }
]
}
POST /_reindex?wait_for_completion=false
Content-Type: application/json
{
"source": { "index": "customers-v1" },
"dest": {
"index": "customers-v2",
"pipeline": "normalize-customers"
}
}Validate scripts and pipelines against representative inputs, including missing, null, malformed, and unexpected values. A transformation can produce semantically incorrect documents without an obvious request-level error.
Account for live writes before cutover
A bulk reindex is not, by itself, a live synchronization mechanism. Writes made to the source while the copy runs may not be reflected in the destination when the task completes. Choose a write-coordination approach before beginning:
- Pause writes: pause application writes, complete the copy, validate, switch the alias, and resume writes. This is straightforward but requires an acceptable write pause.
- Dual-write: write changes to both destinations while historical documents are copied, then reconcile and validate convergence before switching reads. Define failure handling so one successful write and one failed write cannot go unnoticed.
- Capture and replay changes: record writes made during the bulk copy and replay them to the destination before cutover.
- Use a source-of-truth and version strategy: where supported, use external versioning or another reconciliation mechanism to decide which document state should win.
An alias makes the final target change atomic, but it does not coordinate writes during the copy. Define how the application routes reads and writes, what consistency is required, and how to recover from partial dual-writes before relying on the migration.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteSwitch production traffic with an alias
Applications that use a stable alias can avoid changing a physical index name in every client. If an alias does not yet exist, attach it to the current index:
POST /_aliases
Content-Type: application/json
{
"actions": [
{ "add": { "index": "products-v1", "alias": "products" } }
]
}Reindex from the alias into the already-created destination:
POST /_reindex?wait_for_completion=false
Content-Type: application/json
{
"source": { "index": "products" },
"dest": { "index": "products-v2" }
}After resolving live writes and completing validation, move the alias in one multi-action request. Do not remove it and add it back in separate requests:
POST /_aliases
Content-Type: application/json
{
"actions": [
{ "remove": { "index": "products-v1", "alias": "products" } },
{
"add": {
"index": "products-v2",
"alias": "products",
"is_write_index": true
}
}
]
}Elastic documents multi-action alias changes as atomic in its Aliases guide. Retain the old index while the new target is under observation. If validation or application behavior fails after cutover, move the alias back using a corresponding atomic remove/add request, provided writes made after cutover have also been reconciled. Keep the old index only as long as its rollback value justifies the storage and operational cost.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Validate before and after cutover
Check structure and counts
Compare source and destination counts, allowing for filters or intentional exclusions. Inspect the destination’s mapping and settings rather than relying on the creation request alone:
GET /products-v1/_count
GET /products-v2/_count
GET /products-v2/_mapping
GET /products-v2/_settingsA matching count is necessary in many migrations, but not sufficient: documents can have the expected count and still contain wrong values, mapping behavior, or search results.
Test behavior that matters to the application
Run representative exact-match, full-text, phrase, prefix or autocomplete, filter, aggregation, sort, and nested queries. Also check highlighting, geospatial behavior, security filters, response shape, and application-generated queries where applicable. Compare relevance and aggregation results, not just whether a query returns hits.
Inspect failures and cluster health
Review the task’s failure details, version conflicts, retries, and rejected requests. Monitor cluster health, shards, node statistics, and destination index state while the operation runs:
Free tools Windows power users keep installed
One-click scans. No signup required.
GET /_cluster/health
GET /_cat/indices/products-v2?v
GET /_cat/shards/products-v2?v
GET /_nodes/statsWatch heap and CPU pressure, disk watermarks, search and indexing latency, thread-pool queues and rejections, segment and merge activity, and recovery. Restore any temporary operational settings and confirm cluster health before treating the migration as complete.
Handle IDs, versions, conflicts, and retries deliberately
By default, reindex uses ordinary destination versioning behavior; a document with the same ID already in the destination can be overwritten. Decide whether that is acceptable, especially if the destination has other writers or the operation may be repeated. Where the source’s external versions should govern writes, the API supports external versioning:
POST /_reindex?wait_for_completion=false
Content-Type: application/json
{
"source": { "index": "orders-v1" },
"dest": {
"index": "orders-v2",
"version_type": "external"
}
}Version conflicts can arise from concurrent writes, duplicate IDs, external versioning, or repeated attempts. Do not blindly set conflicts=proceed: it permits the operation to continue past conflicts, but does not make skipped or competing document states correct. Proceed only when the conflict policy is intentional and conflicts will be independently reconciled.
Cancel or recover a failed task
For task-management cancellation, use the returned task ID:
POST /_tasks/<task_id>/_cancelThe reindex-specific endpoint is also documented:
POST /_reindex/<task_id>/_cancelElastic’s reindex-specific cancellation documentation identifies that endpoint as generally available starting in Elasticsearch 9.5.0 and describes it as following reindex tasks across node-shutdown relocations. For older deployments, use the Task Management cancellation endpoint. See Cancel an ongoing reindex task and the reindex examples.
Best Value
A failed or cancelled task can leave a partly populated destination. If the destination is disposable and the process can be restarted, a controlled recovery is usually clearer than blindly rerunning into the partial index:
- Keep the destination out of production and record the task’s error and progress.
- Identify and fix the cause, such as an incompatible mapping, malformed input, pipeline failure, permissions issue, capacity shortage, or rejected requests.
- Delete and recreate the destination if a clean restart is the chosen recovery. Deletion is destructive; confirm the index is disposable before issuing it.
- Restart from a known state, then repeat structural, functional, and operational validation.
DELETE /products-v2Resuming against a partially populated destination without a reconciliation plan can overwrite data, create conflicts, or conceal gaps.
Data streams need a different migration plan
Data streams are append-only. Reindexing into a data stream requires op_type: create; it cannot ordinarily update an existing stream document through reindex. Use _update_by_query to update matching documents already in a data stream. See Elastic’s Use a data stream documentation.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →POST /_reindex?wait_for_completion=false
Content-Type: application/json
{
"source": { "index": "logs-old" },
"dest": {
"index": "logs-prod",
"op_type": "create"
}
}For upgrading backing indices, Elasticsearch also documents POST /_migration/reindex with "mode": "upgrade". This is a background persistent migration API intended for indirect use by Kibana’s Upgrade Assistant, not a general substitute for ordinary reindexing. Consult the Reindex data stream API for its intended use.
Move documents from a remote cluster
Remote reindex copies documents over a network; it is not replication. For example, the request can specify a remote host and source credentials:
POST /_reindex?wait_for_completion=false
Content-Type: application/json
{
"source": {
"remote": {
"host": "https://source.example.com:9243",
"username": "reindex-user",
"password": "REDACTED"
},
"index": "products-v1"
},
"dest": { "index": "products-v2" }
}Confirm remote-host permissions, TLS and authentication, source privileges, destination capacity, and network throughput before starting. Remote reindex has hosted-environment restrictions: self-managed destinations may require remote-host permission through reindex.remote.whitelist, while Elastic Cloud and Serverless restrict permitted remote hosts according to their environment. Latency and bandwidth may determine runtime more than local indexing speed. Avoid placing real passwords in shell history or shared documentation; use the authentication mechanism and secret storage supported by your environment.
Common failure symptoms and what to check
| Symptom | What to inspect |
|---|---|
| Mapping or parse exception | Read the task failure details; identify the field and document shape, correct the destination mapping or transformation, and test the problematic value before restarting. |
| Version conflicts | Check for concurrent destination writes, duplicate IDs, or external-version behavior. Reconcile the affected IDs; do not suppress conflicts unless the policy explicitly permits it. |
| Rejected requests or rising latency | Inspect node statistics, thread-pool rejections, CPU, heap, disk I/O, and production latency. Reduce the request rate or slicing concurrency and reassess capacity. |
| Disk watermark or allocation problem | Check free disk, shard allocation, replica requirements, and temporary merge/recovery overhead. Do not continue filling a cluster that cannot safely accommodate the destination. |
| Task times out or becomes hard to track | Use asynchronous execution for long operations and inspect Task Management. A lost client wait does not establish whether the destination is complete; check task state and failures. |
| Documents missing after copy | Compare counts against filters and exclusions, inspect failures and conflicts, verify source query boundaries, and reconcile writes made during migration. |
| Wrong search results despite expected count | Compare mappings and analyzer behavior; test representative full-text, phrase, aggregation, sort, nested, and application queries. |
| Alias cutover fails or targets an unexpected index | Inspect current alias membership and write-index configuration, then make the intended change as one atomic multi-action request. |
| Data-stream create failures | Confirm the destination is a data stream and the request uses op_type: create; resolve duplicate document IDs rather than expecting ordinary overwrite behavior. |
Choose the right migration mechanism
- Use
_update_by_queryif the same index remains appropriate and only selected document fields need changing. - Use snapshot and restore when the goal is backup, recovery, or moving index data without transforming documents; validate version and compatibility requirements for the specific migration.
- Use rollover for a new write target driven by age, size, or document count, not as a substitute for rebuilding old documents.
- For time-series workloads, a data stream with a composable index template and lifecycle policy can make future rollover and retention more systematic; historical corrections may still require a migration.
- For a major version or cluster move, treat reindexing as one part of a broader migration plan, not as a replacement for the applicable compatibility, snapshot, plugin, and upgrade requirements.
A managed Elasticsearch service can reduce infrastructure operations, but it does not remove the need to plan destination configuration, temporary capacity, write coordination, validation, cutover, and rollback. Choose a managed or self-managed deployment based on operational control and service requirements, not on an assumption that the platform will make an unsafe reindex safe.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
