5 Practical Ways to Migrate Elasticsearch Data to Easysearch

Background

During migration of cloud Elasticsearch data to on‑premise INFINI Easysearch, five common migration approaches were evaluated; three were found feasible.

Comparison of Migration Options

Feasible Options

Option 1: Logstash

Officially recommended, stable and reliable

Supports data filtering and transformation

Suitable for large‑scale migrations

Applicable scenario: Migration tasks that require data cleaning or transformation.

Option 2: Elasticdump

Lightweight tool, easy to use

Supports index mapping and selective export

Suitable for medium‑size migrations

Applicable scenario: Quick migration of one or multiple indices.

Option 3: Custom Python script

Highest flexibility, custom logic possible

Uses the scroll API for efficient bulk reads

Can add data validation and error handling

Applicable scenario: Migration tasks with special requirements or need for fine‑grained control.

Infeasible Options

Option 4: Reindex

Failure reason: SSL certificate path construction error.

PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: 
unable to find valid certification path to requested target

Root cause: TLS certificate verification problem between cloud Elasticsearch and local Easysearch prevents a secure cross‑network reindex operation.

Option 5: Snapshot restore

Failure reason: Snapshot format incompatibility.

{
  "error": {
    "type": "parsing_exception",
    "reason": "Failed to parse object: unknown field [uuid] found"
  },
  "status": 500
}

Root cause: Metadata format differences (e.g., the uuid field) prevent Easysearch from parsing the snapshot.

Recommended Solution Selection

< 10 GB: Elasticdump – simple and fast.

10 GB – 100 GB: Logstash – stable and efficient.

> 100 GB: Logstash + Python – batch migration with monitoring.

Special requirements: Custom Python – flexible and controllable.

Practical Guidance

Pre‑migration Preparation

Verify version compatibility between Easysearch and the source Elasticsearch, especially index mappings, query syntax and aggregation support.

Assess source data volume, number of indices and total documents; estimate migration time based on network bandwidth and machine performance; avoid large migrations during peak business hours.

Prepare a rollback plan: retain source data, record migration start point, and design an emergency switch‑back procedure.

Migration Execution Tips

Prefer bulk API (1000–5000 documents per batch) over single‑document writes to balance speed and stability.

Implement progress monitoring: record migrated document count, failures and error logs for troubleshooting and resumable transfers.

Control concurrency carefully; start with a low concurrency level and gradually tune to avoid overloading source or target nodes.

Post‑migration Validation

Compare total document count, index count and per‑index document numbers between source and target to ensure data completeness.

Sample random documents and verify that field values (especially dates, arrays and nested objects) match.

Run typical queries, aggregations and sorts on the target to confirm business functionality and acceptable response times before switching traffic.

Summary

API‑based data transfer methods (Logstash, Elasticdump, Python scripts) proved more reliable than storage‑based approaches (snapshot, reindex). The recommendation is to use mature tools first and resort to custom development only for special needs.