Reindexing is the process of copying documents from a source index into a destination index, re-running them through the indexing pipeline along the way. It’s built into Elasticsearch as a dedicated API — you don’t have to manually export and re-import data yourself. The destination index can have a completely different mapping, different settings, or even live on a different cluster, and the documents can optionally be transformed (filtered, renamed, or reshaped) as they move.

What it is: a built-in operation that reads documents from one index and writes them into another, applying the destination’s mapping and any requested transformations.

Why it exists: because a field’s type, an index’s shard count, and several other settings cannot be changed on a live index — reindexing is the only supported path to apply those kinds of structural changes.

Where it’s used: mapping corrections, shard count changes, Elasticsearch version upgrades, splitting or merging indices, and migrating data between clusters or environments.

Why Can’t Elasticsearch Just “Fix” the Field in Place?

Recall that Elasticsearch’s storage engine, Lucene, writes data into immutable segments — files that, once written, are never edited, only eventually merged or deleted. A field’s type governs exactly how its values were physically written into those segments (for example, as searchable text tokens versus as a raw number). There’s no way to reinterpret already-written bytes as a different type after the fact, so the only reliable fix is to read the original values back out and write them fresh, under the new, corrected rules — which is exactly what reindexing does.

graph LR
    A[Source Index
old_products_v1] -->|Read documents
in batches| B[Reindex Task]
    B -->|Optional script:
transform fields| C{Transform?}
    C -- Yes --> D[Apply script
per document]
    C -- No --> E[Pass through unchanged]
    D --> F[Destination Index
products_v2]
    E --> F
    F --> G[Alias 'products'
repointed to v2]
        

Notice the alias at the end of the diagram. Production teams almost never point application code directly at a raw index name like “products_v2” — instead, they point it at an alias like “products”, which can be instantly repointed from the old index to the new one the moment reindexing finishes. This is the architectural trick that makes reindexing feel “zero-downtime” from the application’s point of view.

The core trade-off is safety versus cost: reindexing trades additional disk space and processing time for the guarantee that your live, serving index is never put at risk while structural changes are made.

Because reindexing can run for minutes, hours, or occasionally longer on huge datasets, keeping an eye on it as it runs is essential:

• Task status API: Elasticsearch exposes a running task’s progress — total documents, documents processed so far, and any failures — so operators can watch it live rather than waiting blindly for completion.
• Cluster resource usage: reindexing generates significant CPU, memory, and I/O load; monitoring node-level metrics during a large reindex helps avoid impacting other live traffic on the same cluster.
• Document count parity: comparing the document count in the source and destination indices after completion is a simple, essential sanity check before cutting over.
• Failure logs: individual document failures (for example, from a script error or a type mismatch) are reported in the task’s response and should be reviewed, not ignored, before trusting the new index.