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, 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 stored in Elasticsearch system indices that supports core Elasticsearch platform operation—cluster coordination, engine-level services, and other internal metadata—rather than the settings, rules, or operational history tied to a specific Elastic feature or integration. That product-specific data is covered under Feature and component data.

• 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:

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. The guides each use a specific source and target deployment type as an example, but they can all be adapted to your specific migration use case.

* See also Reindex from a self-managed cluster using a private CA.