Migrate your Elasticsearch data

Transitioning between Elastic deployment types involves migrating your Elasticsearch data. This page helps you plan your migration by describing the main categories of data you may need to move (ingested user data, Elasticsearch system data, Kibana saved objects, and feature-specific data), the migration methods available for each, and where to find step-by-step guides for your scenario.

Your migration options depend on the type of data that you need to migrate, which can be categorized into four groups:

• Ingested user data: All of the data that you've added into Elasticsearch, structured or unstructured, for your own applications.

• Elasticsearch system data: Configuration and state information stored in Elasticsearch system indices. This data is used by Elasticsearch for its internal operations.

• Kibana saved objects: Dashboards, visualizations, maps, data views, Canvas workpads, and any other objects that you've saved in Kibana.

• Feature and component data: Data stored in Elasticsearch that is specific to a given Elastic feature or component. This includes, for example, configuration data for Fleet and Integrations, Watcher data, alerting and security detection rules, security data such as role mappings, API keys, and service tokens, and others.

Depending on the type of data that you need to move, various migration options are available:

• Reindex from source: For your own data, reindexing into your new, destination deployment from the data's original source is typically the most straightforward approach, since it's available without any need to consider differing Elasticsearch versions or deployment types.

  If you still have access to the original data source, outside of your former Elasticsearch cluster, you can load the data from there. You have the option to use any ingestion method that you want—Logstash, Elastic Agent, Beats, the Elasticsearch clients, or whatever works best for you.

  If the original source isn’t available or has other issues that make it non-viable, you can choose from one of the other migration options described here.

• Dual ingest: For data with a limited lifecycle (logs and metrics, for example), another approach is to ingest into both the original and new environment at the same time, for a set duration. You can ingest into both environments for long enough for the data retention period to elapse. Then, after confirming that everything is working well in the new environment, the original environment can be shut down.

• Snapshot and restore: Use a snapshot to create a backup of your running Elasticsearch cluster, and then migrate by restoring your data into a new cluster.

• Reindex API: Copy documents from a source index to a destination index. You can reindex across clusters and deployment types and transform the data en route.

• Logstash: With Logstash you can collect, process, and forward data from a variety of sources to a variety of destinations. It serves as a highly configurable option available for migrating data across any deployment types.

• Saved objects API: Use this API to migrate objects that you've saved in Kibana.

• Kibana saved object management: You can also use the Kibana UI to migrate your saved objects.

The following table describes the migration options available for each data type and where to find guidance.

To migrate your Elasticsearch ingested user data, choose one of the available migration options depending on your source and target deployment types.

Migrate data to Elastic Cloud Hosted:

• See also Reindex from a Self-managed cluster using a private CA

Migrate data to Elastic Cloud Enterprise:

Migrate data to Elastic Cloud on Kubernetes:

Migrate data to Elastic Cloud Serverless:

Migrate data to Elastic self-managed: