diff --git a/deploy-manage/deploy/elastic-cloud/azure-native-isv-service.md b/deploy-manage/deploy/elastic-cloud/azure-native-isv-service.md index a0e5bcc813..cb204af0c2 100644 --- a/deploy-manage/deploy/elastic-cloud/azure-native-isv-service.md +++ b/deploy-manage/deploy/elastic-cloud/azure-native-isv-service.md @@ -260,7 +260,7 @@ $$$azure-integration-migrate$$$How do I migrate my data from the classic Azure m 3. Navigate to Azure and log in as the user that manages the {{es}} resources. 4. Before proceeding, ensure the new account is configured according to the [prerequisites](#azure-integration-get-started). 5. Create a [new {{es}} resource](#azure-integration-get-started) for each existing deployment that needs migration from the classic Azure account. - 6. In the new {{es}} resource, follow the steps in [Restore from a snapshot](../../../manage-data/migrate.md#ec-restore-snapshots) to register the custom snapshot repository from Step 1. + 6. In the new {{es}} resource, follow the steps in [Restore from a snapshot](/manage-data/migrate/migrate-to-ech-or-ece.md#ec-restore-snapshots) to register the custom snapshot repository from Step 1. 7. In the same set of steps, restore the snapshot data from the snapshot repository that you registered. 8. Confirm the data has moved successfully into your new {{es}} resource on Azure. 9. To remove the old Azure subscription and the old deployments, go to the [Azure SaaS page](https://portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/Microsoft.SaaS%2Fresources) and unsubscribe from the {{ecloud}} ({{es}}) marketplace subscription. This action triggers the existing deployments termination. diff --git a/deploy-manage/deploy/elastic-cloud/serverless.md b/deploy-manage/deploy/elastic-cloud/serverless.md index a229986c38..5180fc4561 100644 --- a/deploy-manage/deploy/elastic-cloud/serverless.md +++ b/deploy-manage/deploy/elastic-cloud/serverless.md @@ -80,7 +80,7 @@ A: {{serverless-full}} is available in select AWS, GCP, and Azure regions, with ### Data management **Q: How can I move data to or from {{serverless-short}} projects?** -A: We are working on data migration tools. In the interim, [use Logstash](logstash://reference/index.md) with {{es}} input and output plugins to move data to and from {{serverless-short}} projects. +A: You can migrate data into your {{serverless-short}} projects using either the reindex API or {{ls}}. Refer to [Migrate data to {{serverless-short}}](/manage-data/migrate/migrate-to-serverless.md) to learn more. **Q: Can I request backups or restores for my serverless projects?** A: Request for project backups or restores is currently unsupported, and we are working on data migration tools to better support this. diff --git a/manage-data/migrate.md b/manage-data/migrate.md index 6b8918a5f1..f97da2f7b5 100644 --- a/manage-data/migrate.md +++ b/manage-data/migrate.md @@ -4,219 +4,69 @@ mapped_pages: - https://www.elastic.co/guide/en/cloud-enterprise/current/ece-migrating-data.html - https://www.elastic.co/guide/en/cloud-heroku/current/ech-migrate-data2.html applies_to: - deployment: - ess: ga - ece: ga + stack: ga + serverless: ga products: + - id: elasticsearch - id: cloud-hosted - id: cloud-enterprise + - id: cloud-kubernetes --- -# Migrate your {{es}} data +# Migrate your {{es}} data [migrate-your-elasticsearch-data] -You might have switched to {{ech}} (ECH) or {{ece}} (ECE) for any number of reasons, and you’re likely wondering how to get your existing {{es}} data into your new infrastructure. Along with easily creating as many new deployments with {{es}} clusters that you need, you have several options for moving your data over. Choose the option that works best for you: +Transitioning between Elastic deployment types involves migrating your {{es}} data. This page helps you plan your migration by describing the main categories of data you may need to move (ingested user data, {{es}} system data, {{kib}} saved objects, and feature-specific data), the migration methods available for each, and where to find step-by-step guides for your scenario. -* Index your data from the original source, which is the simplest method and provides the greatest flexibility for the {{es}} version and ingestion method. -* Reindex from a remote cluster, which rebuilds the index from scratch. -* Restore from a snapshot, which copies the existing indices. +## Data types [migration-data-types] -::::{note} -Although this guide focuses on migrating data from a self-managed cluster to an {{ech}} or {{ece}} deployment, the steps can also be adapted for other scenarios, such as when the source cluster is managed by {{eck}}, or when migrating from {{ece}} to {{ech}}. +Your migration options depend on the type of data that you need to migrate, which can be categorized into four groups: -If both clusters belong to the same {{ech}} or {{ece}} environment, refer to [](/deploy-manage/tools/snapshot-and-restore/ece-restore-across-clusters.md). -:::: +- **Ingested user data**: All of the data that you've added into {{es}}, structured or unstructured, for your own applications. -## Before you begin [ec_migrate_before_you_begin] +- **{{es}} system data**: Configuration and state information stored in {{es}} [system indices](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#system-indices). This data is used by {{es}} for its internal operations. -Depending on which option you choose, you might have limitations or need to do some preparation beforehand. +- **{{kib}} saved objects**: Dashboards, visualizations, maps, data views, Canvas workpads, and any other objects that you've saved in {{kib}}. -Indexing from the source -: The new cluster must be the same size as your old one, or larger, to accommodate the data. +- **Feature and component data**: Data stored in {{es}} 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. -Reindex from a remote cluster -: The new cluster must be the same size as your old one, or larger, to accommodate the data. Depending on your security settings for your old cluster, you might need to temporarily allow TCP traffic on port 9243 for this procedure. +## Migration options [migration-options] - For {{ech}}, if your old cluster is self-managed and uses [TLS certificates](/deploy-manage/security/set-up-basic-security-plus-https.md) signed by a private (non–publicly trusted) certificate authority, follow [this guide](migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md) to establish trust and configure remote reindex to ECH. +Depending on the type of data that you need to move, various migration options are available: -Restore from a snapshot -: The new cluster must be the same size as your old one, or larger, to accommodate the data. The new cluster must also be an {{es}} version that is compatible with the old cluster (check [Elasticsearch snapshot version compatibility](/deploy-manage/tools/snapshot-and-restore.md#snapshot-restore-version-compatibility) for details). If you have not already done so, you need to [set up snapshots for your old cluster](/deploy-manage/tools/snapshot-and-restore/self-managed.md) using a repository that the new cluster can access. + - **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 {{es}} versions or deployment types. + - **Snapshot and restore**: Use a snapshot to create a backup of your running {{es}} 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. + - **{{ls}}**: With {{ls}} 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**: You can use this API or the {{kib}} UI to migrate objects that you've saved in {{kib}}. + - **{{kib}} saved object management**: You can also use the {{kib}} UI to to migrate your saved objects. -:::{admonition} Migrating system {{es}} indices -In {{es}} 8.0 and later versions, to back up and restore system indices and system data streams such as `.kibana` or `.security`, you must snapshot and restore the related feature's [feature state](/deploy-manage/tools/snapshot-and-restore.md#feature-state). +The following table describes the migration options available for each data type and where to find guidance. -Refer to [Migrate system indices](./migrate/migrate-internal-indices.md) to learn how to restore the internal {{es}} system indices from a snapshot. -::: +| Data type | Migration options | +| ------ | ------ | +| Ingested user data | The reindex API, snapshot and restore, and {{ls}} migration options are available for your user data, with some restrictions based on the source and target deployment type. Refer to the [data migration guides](#data-migration-guides) listed on this page to learn more. | +| {{es}} system data | System indices must be migrated using the snapshot and restore [feature states](/deploy-manage/tools/snapshot-and-restore.md#feature-state) component. Refer to [Migrate system indices](/manage-data/migrate/migrate-internal-indices.md) for detailed migration steps. | +| {{kib}} saved objects | {{kib}} saved objects can be migrated using the snapshot and restore [feature states](/deploy-manage/tools/snapshot-and-restore.md#feature-state) component or the {{kib}} import and export tools. The tools include the import and export endpoints of the [Saved objects API](https://www.elastic.co/docs/api/doc/kibana/group/endpoint-saved-objects) and the [import and export](/explore-analyze/find-and-organize/saved-objects.md#saved-objects-import-and-export) options in the {{kib}} UI.

Snapshot and restore is generally the preferred migration method due to both speed and ease of use. In case you need to migrate {{fleet}} configuration data through snapshot and restore, this requires also restoring the {{kib}} feature state. | +| Elastic feature and component data | Configuration data for products such as {{fleet}}, {{integrations}}, and {{watcher}} is typically migrated using the snapshot and restore feature. Refer to [Snaphot and restore](/deploy-manage/tools/snapshot-and-restore.md) and to the documentation for each specific product for additional detail. | -## Index from the source [ec-index-source] +## Data migration guides [data-migration-guides] -If you still have access to the original data source, outside of your old {{es}} cluster, you can load the data from there. This might be the simplest option, allowing you to choose the {{es}} version and take advantage of the latest features. You have the option to use any ingestion method that you want—Logstash, Beats, the {{es}} clients, or whatever works best for you. +Choose one of our guides for detailed steps to migrate your {{es}} data. -If the original source isn’t available or has other issues that make it non-viable, there are still two more migration options, getting the data from a remote cluster or restoring from a snapshot. +Migrate your user data to {{serverless-full}}: -## Reindex from a remote cluster [ech-reindex-remote] +- [Migrate with the reindex API](/manage-data/migrate/migrate-with-reindex-api.md) +- [Migrate with {{ls}}](/manage-data/migrate/migrate-with-logstash.md) -Through the {{es}} [reindex API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex), you can connect your new {{es}} deployment remotely to your old {{es}} cluster. This pulls the data from your old cluster and indexes it into your new one. Reindexing essentially rebuilds the index from scratch and it can be more resource intensive to run than a [snapshot restore](#ec-restore-snapshots). +Migrate your user data to {{ech}} or {{ece}}: -::::{warning} -Reindex operations do not migrate index mappings, settings, or associated index templates from the source cluster. +- [Migrate to {{ech}} or ECE](/manage-data/migrate/migrate-to-ech-or-ece.md) +- [Reindex using a private CA](/manage-data/migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md) {applies_to}`ece: unavailable` -Before migrating your {{es}} data, define the necessary [mappings](/manage-data/data-store/mapping.md) and [templates](/manage-data/data-store/templates.md) on the new cluster. The easiest way to do this is to copy the relevant index templates from the old cluster to the new one before starting reindex operations. -:::: +Migrate data using snapshot and restore, including system data: -::::{note} -:applies_to: { ess: } +- [Minimal-downtime migration using snapshots](/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md) +- [Migrate system indices](/manage-data/migrate/migrate-internal-indices.md) -For {{ech}}, if your old cluster uses [TLS certificates](/deploy-manage/security/set-up-basic-security-plus-https.md) signed by a private (non–publicly trusted) certificate authority, follow [this guide](migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md) to establish trust. -:::: -Follow these steps to reindex data remotely: -1. Log in to {{ech}} or {{ece}}. -2. Select a deployment or create one. -3. Ensure that the new deployment can access your old cluster to perform the reindex operation. Access is controlled by the {{es}} `reindex.remote.whitelist` user setting. - - Domains matching the patterns `["*.io:*", "*.com:*"]` are allowed by default, so if your remote host URL matches that pattern you do not need to explicitly define `reindex.remote.whitelist`. - - Otherwise, if your remote endpoint is not covered by the default patterns, adjust the setting to add the remote {{es}} cluster as an allowed host: - - 1. From your deployment menu, go to the **Edit** page. - 2. In the **Elasticsearch** section, select **Manage user settings and extensions**. For deployments with existing user settings, you might have to expand the **Edit elasticsearch.yml** caret for each node type instead. - 3. Add the following `reindex.remote.whitelist: [REMOTE_HOST:PORT]` user setting, where `REMOTE_HOST` is a pattern matching the URL for the remote {{es}} host that you are reindexing from, and `PORT` is the host port number. Do not include the `https://` prefix. - - If you override the parameter, it replaces the defaults: `["*.io:*", "*.com:*"]`. If you still want these patterns to be allowed, you need to specify them explicitly in the value. - - For example: - - `reindex.remote.whitelist: ["*.us-east-1.aws.found.io:9243", "*.com:*"]` - - 4. Save your changes. - -4. Using the **API Console** or within {{kib}}, either create the destination index with the appropriate settings and [mappings](/manage-data/data-store/mapping.md), or ensure that the relevant [index templates](/manage-data/data-store/templates.md) are in place. - -5. Using the **API Console** or [{{kib}} DevTools Console](/explore-analyze/query-filter/tools/console.md), reindex the data remotely from the old cluster: - - ```sh - POST _reindex - { - "source": { - "remote": { - "host": "https://:", - "username": "USER", - "password": "PASSWORD" - }, - "index": "INDEX_NAME", - "query": { - "match_all": {} - } - }, - "dest": { - "index": "INDEX_NAME" - } - } - ``` - - For additional options and details, refer to the [reindex API documentation](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex). - -6. Verify that the new index is present: - - ```sh - GET INDEX-NAME/_search?pretty - ``` - -7. If you are not planning to reindex more data from the remote, you can remove the `reindex.remote.whitelist` user setting that you added previously. - -## Restore from a snapshot [ec-restore-snapshots] - -[Restoring from a snapshot](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md) is often the fastest and most reliable way to migrate data between {{es}} clusters. It preserves mappings, settings, and optionally parts of the cluster state such as index templates, component templates, and system indices. - -You can restore system indices by including their corresponding [feature states](/deploy-manage/tools/snapshot-and-restore.md#feature-state) in the restore operation, allowing you to retain internal configurations related to security, {{kib}}, or other stack features. - -This method is especially useful when: - -* You want to fully replicate the old cluster or when remote reindexing is not feasible, for example if the old cluster is in a degraded or unreachable state. -* Your old cluster contains mostly static data, allowing you to snapshot the old cluster, restore in the new cluster, and continue operations. - -When your source cluster is actively ingesting data, such as logs, metrics, or traces, and you need a seamless migration with minimal downtime, consider using the [minimal downtime migration](migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md) guide. - -### Requirements [ec-restore-snapshots-requirements] - -* The new cluster must have access to the snapshot repository that contains the data from the old cluster. If snapshots are not already configured on the old cluster, refer to [Snapshot and restore](/deploy-manage/tools/snapshot-and-restore/self-managed.md) to enable and configure snapshots, or use a different data migration method. -* Both clusters must use [compatible versions](/deploy-manage/tools/snapshot-and-restore.md#snapshot-compatibility). - -For more information, refer to [Restore into a different cluster](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md#restore-different-cluster). - -::::{note} -For {{ece}}, Amazon S3 is the most common snapshot storage, but you can restore from any accessible external storage that contains your {{es}} snapshots. -:::: - -### Step 1: Set up the repository in the new cluster [migrate-repo-setup] - -In this step, you’ll configure a read-only snapshot repository in the new cluster that points to the storage location used by the old cluster. This allows the new cluster to access and restore snapshots created in the original environment. - -::::{tip} -If your new {{ech}} or {{ece}} deployment cannot connect to the same repository used by your self-managed cluster, for example if it's a private Network File System (NFS) share, consider one of the following alternatives: - -* [Back up your repository](/deploy-manage/tools/snapshot-and-restore/self-managed.md#snapshots-repository-backup) to a supported storage system such as AWS S3, Google Cloud Storage, or Azure Blob Storage, and then configure your new cluster to use that location for the data migration. -* Expose the repository contents over `ftp`, `http`, or `https`, and use a [read-only URL repository](/deploy-manage/tools/snapshot-and-restore/read-only-url-repository.md) type in your new deployment to access the snapshots. -:::: - -1. On your old {{es}} cluster, retrieve the snapshot repository configuration: - - ```sh - GET /_snapshot/_all - ``` - - Take note of the repository name and type (for example, `s3`, `gcs`, or `azure`), its base path, and any additional settings. Authentication credentials are often stored in the [secure settings](/deploy-manage/security/secure-settings.md) on each node. You’ll need to replicate all this configuration when registering the repository in the new ECH or ECE deployment. - - If your old cluster has multiple repositories configured, identify the repository with the snapshots containing the data that you want to migrate. - -2. Add the snapshot repository on the new cluster. - - Considerations: - - * If you're migrating [searchable snapshots](/deploy-manage/tools/snapshot-and-restore/searchable-snapshots.md), the repository name must be identical in the old and new clusters. - * If the old cluster still has write access to the repository, register the repository as read-only to avoid data corruption. You can do this using the `readonly: true` option. - - To connect the existing snapshot repository to your new deployment, follow the steps for the storage provider where the repository is hosted: - - * **Amazon Web Services (AWS) Storage** - * [Store credentials in the keystore](/deploy-manage/tools/snapshot-and-restore/ec-aws-custom-repository.md#ec-snapshot-secrets-keystore) - * [Create the repository](/deploy-manage/tools/snapshot-and-restore/ec-aws-custom-repository.md#ec-create-aws-repository) - * **Google Cloud Storage (GCS)** - * [Store credentials in the keystore](/deploy-manage/tools/snapshot-and-restore/ec-gcs-snapshotting.md#ec-configure-gcs-keystore) - * [Create the repository](/deploy-manage/tools/snapshot-and-restore/ec-gcs-snapshotting.md#ec-create-gcs-repository) - * **Azure Blob Storage** - * [Store credentials in the keystore](/deploy-manage/tools/snapshot-and-restore/ec-azure-snapshotting.md#ec-configure-azure-keystore). - * [Create the repository](/deploy-manage/tools/snapshot-and-restore/ec-azure-snapshotting.md#ec-create-azure-repository). - - ::::{important} - Although these instructions focus on {{ech}}, you should follow the same steps for {{ece}} by configuring the repository directly **at the deployment level**. - - **Do not** configure the repository as an [ECE-managed repository](/deploy-manage/tools/snapshot-and-restore/cloud-enterprise.md), which is intended for automatic snapshots of deployments. In this case, you need to add a custom repository that already contains snapshots from another cluster. - :::: - - -### Step 2: Run the snapshot restore [migrate-restore] - -After you have registered and verified the repository, you are ready to restore any data from any of its snapshots to your new cluster. - -You can run a restore operation using the {{kib}} Management UI, or using the {{es}} API. Refer to [Restore a snapshot](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md) for more details, including API-based examples. - -For details about the contents of a snapshot, refer to [](/deploy-manage/tools/snapshot-and-restore.md#snapshot-contents). - -To start the restore process: - -1. Open Kibana and go to the **Snapshot and Restore** management page using the navigation menu or the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). -2. Under the **Snapshots** tab, you can find the available snapshots from your newly added snapshot repository. Select any snapshot to view its details, and from there you can choose to restore it. -3. Select **Restore**. -4. Select the index or indices you wish to restore. -5. Optionally, configure additional restore options, such as **Restore aliases**, **Restore global state**, or **Restore feature state**. -6. Select **Restore snapshot** to begin the process. - -7. Verify that each restored index is available in your deployment. You can do this using {{kib}} **Index Management** UI, or by running this query: - - ```sh - GET INDEX_NAME/_search?pretty - ``` - - If you have restored many indices you can also run `GET _cat/indices?s=index` to list all indices for verification. diff --git a/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md b/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md index 43bc969b0f..213e692339 100644 --- a/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md +++ b/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md @@ -34,7 +34,7 @@ Before you migrate, review the prerequisites and requirements. ### Prerequisites * Learn how to [set up and manage snapshot repositories](/deploy-manage/tools/snapshot-and-restore/manage-snapshot-repositories.md). * If restoring to a different cluster, review [Restore to a different cluster](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md#restore-different-cluster). -* As an alternative migration method, you can [reindex from a remote cluster](/manage-data/migrate.md#ech-reindex-remote). +* As an alternative migration method, you can [reindex from a remote cluster](/manage-data/migrate/migrate-to-ech-or-ece.md#ech-reindex-remote). ### Requirements * **Cluster size** – The new cluster must be the same size or larger than the old cluster. @@ -45,7 +45,7 @@ Before you migrate, review the prerequisites and requirements. * **Custom integrations** – Some integrations that use the {{es}} API directly, such as the [Elasticsearch Java Client library](elasticsearch-java://reference/index.md), can require additional handling during cutover. ## Recommended migration timeline [recommended-migration-timeline] -Tp complete the migration with minimal downtime, use incremental snapshots. While the exact sequence may differ depending on your infrastructure and operational requirements, you can use the recommended migration timeline as a reliable baseline that you can adapt. Adjust the steps and times to fit your own operational needs. +To complete the migration with minimal downtime, use incremental snapshots. While the exact sequence might differ depending on your infrastructure and operational requirements, you can use the recommended migration timeline as a reliable baseline that you can adapt. Adjust the steps and times to fit your own operational needs. 1. **09:00**: Take the initial full snapshot of the old cluster. You can also take the initial full snapshot the day before. 2. **09:30**: Restore the snapshot to the new cluster. diff --git a/manage-data/migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md b/manage-data/migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md index ba3d943187..8f19d4090e 100644 --- a/manage-data/migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md +++ b/manage-data/migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md @@ -3,7 +3,6 @@ navigation_title: Reindex using a private CA mapped_pages: - https://www.elastic.co/guide/en/cloud/current/ec-remote-reindex.html applies_to: - serverless: unavailable deployment: ess: all products: @@ -70,7 +69,7 @@ The `Destination` cluster should be the same or newer version as the `Source` cl ## Step 5: Reindex from remote `Source` cluster [ec-remote-reindex-step5] -You can now run a remote reindex operation on the {{ech}} `Destination` cluster from the `Source` cluster, as described in the [migration guide](/manage-data/migrate.md#ech-reindex-remote): +You can now run a remote reindex operation on the {{ech}} `Destination` cluster from the `Source` cluster, as described in the [migration guide](/manage-data/migrate/migrate-to-ech-or-ece.md#ech-reindex-remote). ```text POST _reindex diff --git a/manage-data/migrate/migrate-internal-indices.md b/manage-data/migrate/migrate-internal-indices.md index 76c45d5e84..5e96ba4116 100644 --- a/manage-data/migrate/migrate-internal-indices.md +++ b/manage-data/migrate/migrate-internal-indices.md @@ -18,7 +18,7 @@ However, using snapshot and restore for system indices does not mean you must us ## Migrate system indices using snapshot and restore -To restore system indices from a snapshot, follow the same procedure described in [](../migrate.md#ec-restore-snapshots) and select the appropriate feature states when preparing the restore operation, such as `kibana` or `security`. +To restore system indices from a snapshot, follow the same procedure described in [](/manage-data/migrate/migrate-to-ech-or-ece.md#ec-restore-snapshots) and select the appropriate feature states when preparing the restore operation, such as `kibana` or `security`. For more details about restoring feature states, or the entire cluster state, refer to [](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md#restore-feature-state). diff --git a/manage-data/migrate/migrate-to-ech-or-ece.md b/manage-data/migrate/migrate-to-ech-or-ece.md new file mode 100644 index 0000000000..5ed1e5a44b --- /dev/null +++ b/manage-data/migrate/migrate-to-ech-or-ece.md @@ -0,0 +1,221 @@ +--- +navigation_title: Migrate data to Cloud Hosted or ECE +mapped_pages: + - https://www.elastic.co/guide/en/cloud/current/ec-migrate-data-internal.html + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-migrate-data-internal.html +applies_to: + stack: ga +products: + - id: cloud-hosted +--- + +# Migrate data to {{ech}} or {{ece}} [migrate-to-ech-or-ece] + +You might have switched to {{ech}} (ECH) or {{ece}} (ECE) for any number of reasons, and you’re likely wondering how to get your existing {{es}} data into your new infrastructure. Along with easily creating as many new deployments with {{es}} clusters that you need, you have several options for moving your data over. Choose the option that works best for you: + +* Index your data from the original source, which is the simplest method and provides the greatest flexibility for the {{es}} version and ingestion method. +* Reindex from a remote cluster, which rebuilds the index from scratch. +* Restore from a snapshot, which copies the existing indices. + +::::{note} +Although this guide focuses on migrating data from a self-managed cluster to an {{ech}} or {{ece}} deployment, the steps can also be adapted for other scenarios, such as when the source cluster is managed by {{eck}}, or when migrating from {{ece}} to {{ech}}. + +If both clusters belong to the same {{ech}} or {{ece}} environment, refer to [](/deploy-manage/tools/snapshot-and-restore/ece-restore-across-clusters.md). + +If you're migrating data to {{ech}} from a self-managed cluster that uses non–publicly trusted TLS certificates, refer to [Reindex from a self-managed cluster using a private CA](/manage-data/migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md) for instructions. +:::: + +## Before you begin [ec_migrate_before_you_begin] + +Depending on which option you choose, you might have limitations or need to do some preparation beforehand. + +Indexing from the source +: The new cluster must be the same size as your old one, or larger, to accommodate the data. + +Reindex from a remote cluster +: The new cluster must be the same size as your old one, or larger, to accommodate the data. Depending on your security settings for your old cluster, you might need to temporarily allow TCP traffic on port 9243 for this procedure. + + For {{ech}}, if your old cluster is self-managed and uses [TLS certificates](/deploy-manage/security/set-up-basic-security-plus-https.md) signed by a private (non–publicly trusted) certificate authority, follow [this guide](/manage-data/migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md) to establish trust and configure remote reindex to ECH. + +Restore from a snapshot +: The new cluster must be the same size as your old one, or larger, to accommodate the data. The new cluster must also be an {{es}} version that is compatible with the old cluster (check [Elasticsearch snapshot version compatibility](/deploy-manage/tools/snapshot-and-restore.md#snapshot-restore-version-compatibility) for details). If you have not already done so, you need to [set up snapshots for your old cluster](/deploy-manage/tools/snapshot-and-restore/self-managed.md) using a repository that the new cluster can access. + +:::{admonition} Migrating system {{es}} indices +In {{es}} 8.0 and later versions, to back up and restore system indices and system data streams such as `.kibana` or `.security`, you must snapshot and restore the related feature's [feature state](/deploy-manage/tools/snapshot-and-restore.md#feature-state). + +Refer to [Migrate system indices](/manage-data/migrate/migrate-internal-indices.md) to learn how to restore the internal {{es}} system indices from a snapshot. +::: + +## Index from the source [ec-index-source] + +If you still have access to the original data source, outside of your old {{es}} cluster, you can load the data from there. This might be the simplest option, allowing you to choose the {{es}} version and take advantage of the latest features. You have the option to use any ingestion method that you want—Logstash, Beats, the {{es}} clients, or whatever works best for you. + +If the original source isn’t available or has other issues that make it non-viable, there are still two more migration options, getting the data from a remote cluster or restoring from a snapshot. + +## Reindex from a remote cluster [ech-reindex-remote] + +Through the {{es}} [reindex API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex), you can connect your new {{es}} deployment remotely to your old {{es}} cluster. This pulls the data from your old cluster and indexes it into your new one. Reindexing essentially rebuilds the index from scratch and it can be more resource intensive to run than a [snapshot restore](#ec-restore-snapshots). + +::::{warning} +Reindex operations do not migrate index mappings, settings, or associated index templates from the source cluster. + +Before migrating your {{es}} data, define the necessary [mappings](/manage-data/data-store/mapping.md) and [templates](/manage-data/data-store/templates.md) on the new cluster. The easiest way to do this is to copy the relevant index templates from the old cluster to the new one before starting reindex operations. +:::: + +::::{note} +:applies_to: { ess: } + +For {{ech}}, if your old cluster uses [TLS certificates](/deploy-manage/security/set-up-basic-security-plus-https.md) signed by a private (non–publicly trusted) certificate authority, follow [this guide](/manage-data/migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md) to establish trust. +:::: + +Follow these steps to reindex data remotely: + +1. Log in to {{ech}} or {{ece}}. +2. Select a deployment or create one. +3. Ensure that the new deployment can access your old cluster to perform the reindex operation. Access is controlled by the {{es}} `reindex.remote.whitelist` user setting. + + Domains matching the patterns `["*.io:*", "*.com:*"]` are allowed by default, so if your remote host URL matches that pattern you do not need to explicitly define `reindex.remote.whitelist`. + + Otherwise, if your remote endpoint is not covered by the default patterns, adjust the setting to add the remote {{es}} cluster as an allowed host: + + 1. From your deployment menu, go to the **Edit** page. + 2. In the **Elasticsearch** section, select **Manage user settings and extensions**. For deployments with existing user settings, you might have to expand the **Edit elasticsearch.yml** caret for each node type instead. + 3. Add the following `reindex.remote.whitelist: [REMOTE_HOST:PORT]` user setting, where `REMOTE_HOST` is a pattern matching the URL for the remote {{es}} host that you are reindexing from, and `PORT` is the host port number. Do not include the `https://` prefix. + + If you override the parameter, it replaces the defaults: `["*.io:*", "*.com:*"]`. If you still want these patterns to be allowed, you need to specify them explicitly in the value. + + For example: + + `reindex.remote.whitelist: ["*.us-east-1.aws.found.io:9243", "*.com:*"]` + + 4. Save your changes. + +4. Using the **API Console** or within {{kib}}, either create the destination index with the appropriate settings and [mappings](/manage-data/data-store/mapping.md), or ensure that the relevant [index templates](/manage-data/data-store/templates.md) are in place. + +5. Using the **API Console** or [{{kib}} DevTools Console](/explore-analyze/query-filter/tools/console.md), reindex the data remotely from the old cluster: + + ```sh + POST _reindex + { + "source": { + "remote": { + "host": "https://:", + "username": "USER", + "password": "PASSWORD" + }, + "index": "INDEX_NAME", + "query": { + "match_all": {} + } + }, + "dest": { + "index": "INDEX_NAME" + } + } + ``` + + For additional options and details, refer to the [reindex API documentation](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex). + +6. Verify that the new index is present: + + ```sh + GET INDEX-NAME/_search?pretty + ``` + +7. If you are not planning to reindex more data from the remote, you can remove the `reindex.remote.whitelist` user setting that you added previously. + +## Restore from a snapshot [ec-restore-snapshots] + +[Restoring from a snapshot](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md) is often the fastest and most reliable way to migrate data between {{es}} clusters. It preserves mappings, settings, and optionally parts of the cluster state such as index templates, component templates, and system indices. + +You can restore system indices by including their corresponding [feature states](/deploy-manage/tools/snapshot-and-restore.md#feature-state) in the restore operation, allowing you to retain internal configurations related to security, {{kib}}, or other stack features. + +This method is especially useful when: + +* You want to fully replicate the old cluster or when remote reindexing is not feasible, for example if the old cluster is in a degraded or unreachable state. +* Your old cluster contains mostly static data, allowing you to snapshot the old cluster, restore in the new cluster, and continue operations. + +When your source cluster is actively ingesting data, such as logs, metrics, or traces, and you need a seamless migration with minimal downtime, consider using the [minimal downtime migration](/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md) guide. + +### Requirements [ec-restore-snapshots-requirements] + +* The new cluster must have access to the snapshot repository that contains the data from the old cluster. If snapshots are not already configured on the old cluster, refer to [Snapshot and restore](/deploy-manage/tools/snapshot-and-restore/self-managed.md) to enable and configure snapshots, or use a different data migration method. +* Both clusters must use [compatible versions](/deploy-manage/tools/snapshot-and-restore.md#snapshot-compatibility). + +For more information, refer to [Restore into a different cluster](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md#restore-different-cluster). + +::::{note} +For {{ece}}, Amazon S3 is the most common snapshot storage, but you can restore from any accessible external storage that contains your {{es}} snapshots. +:::: + +### Step 1: Set up the repository in the new cluster [migrate-repo-setup] + +In this step, you’ll configure a read-only snapshot repository in the new cluster that points to the storage location used by the old cluster. This allows the new cluster to access and restore snapshots created in the original environment. + +::::{tip} +If your new {{ech}} or {{ece}} deployment cannot connect to the same repository used by your self-managed cluster, for example if it's a private Network File System (NFS) share, consider one of the following alternatives: + +* [Back up your repository](/deploy-manage/tools/snapshot-and-restore/self-managed.md#snapshots-repository-backup) to a supported storage system such as AWS S3, Google Cloud Storage, or Azure Blob Storage, and then configure your new cluster to use that location for the data migration. +* Expose the repository contents over `ftp`, `http`, or `https`, and use a [read-only URL repository](/deploy-manage/tools/snapshot-and-restore/read-only-url-repository.md) type in your new deployment to access the snapshots. +:::: + +1. On your old {{es}} cluster, retrieve the snapshot repository configuration: + + ```sh + GET /_snapshot/_all + ``` + + Take note of the repository name and type (for example, `s3`, `gcs`, or `azure`), its base path, and any additional settings. Authentication credentials are often stored in the [secure settings](/deploy-manage/security/secure-settings.md) on each node. You’ll need to replicate all this configuration when registering the repository in the new ECH or ECE deployment. + + If your old cluster has multiple repositories configured, identify the repository with the snapshots containing the data that you want to migrate. + +2. Add the snapshot repository on the new cluster. + + Considerations: + + * If you're migrating [searchable snapshots](/deploy-manage/tools/snapshot-and-restore/searchable-snapshots.md), the repository name must be identical in the old and new clusters. + * If the old cluster still has write access to the repository, register the repository as read-only to avoid data corruption. You can do this using the `readonly: true` option. + + To connect the existing snapshot repository to your new deployment, follow the steps for the storage provider where the repository is hosted: + + * **Amazon Web Services (AWS) Storage** + * [Store credentials in the keystore](/deploy-manage/tools/snapshot-and-restore/ec-aws-custom-repository.md#ec-snapshot-secrets-keystore) + * [Create the repository](/deploy-manage/tools/snapshot-and-restore/ec-aws-custom-repository.md#ec-create-aws-repository) + * **Google Cloud Storage (GCS)** + * [Store credentials in the keystore](/deploy-manage/tools/snapshot-and-restore/ec-gcs-snapshotting.md#ec-configure-gcs-keystore) + * [Create the repository](/deploy-manage/tools/snapshot-and-restore/ec-gcs-snapshotting.md#ec-create-gcs-repository) + * **Azure Blob Storage** + * [Store credentials in the keystore](/deploy-manage/tools/snapshot-and-restore/ec-azure-snapshotting.md#ec-configure-azure-keystore). + * [Create the repository](/deploy-manage/tools/snapshot-and-restore/ec-azure-snapshotting.md#ec-create-azure-repository). + + ::::{important} + Although these instructions focus on {{ech}}, you should follow the same steps for {{ece}} by configuring the repository directly **at the deployment level**. + + **Do not** configure the repository as an [ECE-managed repository](/deploy-manage/tools/snapshot-and-restore/cloud-enterprise.md), which is intended for automatic snapshots of deployments. In this case, you need to add a custom repository that already contains snapshots from another cluster. + :::: + + +### Step 2: Run the snapshot restore [migrate-restore] + +After you have registered and verified the repository, you are ready to restore any data from any of its snapshots to your new cluster. + +You can run a restore operation using the {{kib}} Management UI, or using the {{es}} API. Refer to [Restore a snapshot](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md) for more details, including API-based examples. + +For details about the contents of a snapshot, refer to [](/deploy-manage/tools/snapshot-and-restore.md#snapshot-contents). + +To start the restore process: + +1. Open Kibana and go to the **Snapshot and Restore** management page using the navigation menu or the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). +2. Under the **Snapshots** tab, you can find the available snapshots from your newly added snapshot repository. Select any snapshot to view its details, and from there you can choose to restore it. +3. Select **Restore**. +4. Select the index or indices you wish to restore. +5. Optionally, configure additional restore options, such as **Restore aliases**, **Restore global state**, or **Restore feature state**. +6. Select **Restore snapshot** to begin the process. + +7. Verify that each restored index is available in your deployment. You can do this using {{kib}} **Index Management** UI, or by running this query: + + ```sh + GET INDEX_NAME/_search?pretty + ``` + + If you have restored many indices you can also run `GET _cat/indices?s=index` to list all indices for verification. diff --git a/manage-data/migrate/migrate-to-serverless.md b/manage-data/migrate/migrate-to-serverless.md new file mode 100644 index 0000000000..58ca9f9960 --- /dev/null +++ b/manage-data/migrate/migrate-to-serverless.md @@ -0,0 +1,30 @@ +--- +navigation_title: Migrate data to {{serverless-short}} +mapped_pages: + - https://www.elastic.co/guide/en/cloud/current/ec-migrate-data-internal.html + - https://www.elastic.co/guide/en/cloud-heroku/current/ech-migrate-data-internal.html +applies_to: + stack: ga + serverless: ga +products: + - id: elasticsearch + - id: cloud-hosted + - id: cloud-enterprise + - id: cloud-kubernetes +--- + +# Migrate data to {{serverless-full}} [migrate-to-serverless] + +You might currently be using ECH or another deployment type and want to switch to {{serverless-short}}. To better understand the differences between these offerings, refer to [Compare {{ech}} and {{serverless-short}}](/deploy-manage/deploy/elastic-cloud/differences-from-other-elasticsearch-offerings.md). + +To make the change, you first need to [create a {{serverless-short}} project](/deploy-manage/deploy/elastic-cloud/create-serverless-project.md). Once the new project is set up, you're ready to migrate your data. + +There are two approaches to migrating ECH data into {{serverless-short}}: + + - [Migrate with the reindex API](/manage-data/migrate/migrate-with-reindex-api.md): The [reindex API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex) is a built-in component of {{es}}. You can use it to migrate your data from source indices, aliases, or data streams, and optionally to filter and transform documents as they are ingested into the target cluster. {applies_to}`serverless: preview 9.3` + + This method is not currently available for migrating {{es}} data from self-hosted deployments. + + - [Migrate with {{ls}}](/manage-data/migrate/migrate-with-logstash.md): [{{ls}}](logstash://reference/index.md) is a separately installable {{es}} product that, with its {{es}} input and {{es}} output plugins, allows for various advanced configuration options during data migration. For example, you can control how many documents are retrieved in a single HTTP request, enable parallel reads from the source index, or track documents fields in order to resume data migration in the event that {{ls}} needs to be restarted. + + While this guide shows steps specifically for migrating from ECH deployments to {{serverless-short}}, {{ls}} can be used to migrate {{es}} data between all deployment types. diff --git a/manage-data/migrate/migrate-using-snapshots.md b/manage-data/migrate/migrate-using-snapshots.md new file mode 100644 index 0000000000..3606a18983 --- /dev/null +++ b/manage-data/migrate/migrate-using-snapshots.md @@ -0,0 +1,21 @@ +--- +navigation_title: Migrate data using snapshots +applies_to: + stack: ga + serverless: unavailable +products: + - id: elasticsearch + - id: cloud-hosted + - id: cloud-enterprise + - id: cloud-kubernetes +--- + +# Migrate {{ech}} data using snapshots [migrate-using-snapshots] + +A [snapshot](/deploy-manage/tools/snapshot-and-restore.md) is a backup of a running {{es}} cluster that includes both indexed documents and configuration data. As a migration path, you can take a new snapshot or use an existing one, and then restore it into a new, destination cluster. This is the recommended procedure for migrating system indices. + +Learn about migrating your {{es}} data between Elastic deployment types by using snapshots: + + - [Minimal-downtime migration using snapshots](/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md) + + - [Migrate system indices](/manage-data/migrate/migrate-internal-indices.md) diff --git a/manage-data/migrate/migrate-with-logstash.md b/manage-data/migrate/migrate-with-logstash.md index c786b4453b..934e9c4506 100644 --- a/manage-data/migrate/migrate-with-logstash.md +++ b/manage-data/migrate/migrate-with-logstash.md @@ -1,5 +1,5 @@ --- -navigation_title: Migrate Elastic Cloud Hosted data to Serverless with Logstash +navigation_title: Migrate with {{ls}} applies_to: serverless: deployment: @@ -17,9 +17,9 @@ products: Familiarity with {{ech}}, {{es}}, and {{ls}} is helpful, but not required. :::{admonition} Basic migration -This guide focuses on a basic data migration scenario for moving static data from an {{ech}} deployment to a {{serverless-full}} project. +This guide focuses on a basic data migration scenario for moving static data from an {{ech}} deployment to a {{serverless-full}} project. The steps can also be adapted for other scenarios, such as when the source cluster is managed by {{eck}}, or when migrating across other deployment types including self-managed, {{ech}}, {{ece}}, or {{eck}}. -The Elasticsearch input plugin offers [additional configuration options](#additional-config) that can support more advanced use cases and migrations. More information about those options is available near the end of this topic. +The {{es}} input plugin also offers [additional configuration options](#additional-config) that can support more advanced use cases and migrations. More information about those options is available near the end of this topic. ::: ## Prerequisites [migrate-prereqs] @@ -30,7 +30,7 @@ The Elasticsearch input plugin offers [additional configuration options](#additi - API keys in {{ls}} format for authentication with both deployments :::{important} -Kibana assets much be migrated separately using the {{kib}} [export/import APIs](https://www.elastic.co/docs/api/doc/kibana/group/endpoint-saved-objects) or recreated manually. +Kibana assets must be migrated separately using the {{kib}} [export/import APIs](https://www.elastic.co/docs/api/doc/kibana/group/endpoint-saved-objects) or recreated manually. Templates, data stream definitions, and ILM policies, must be in place _before_ you start data migration. Visual components, such dashboard and visualizations, can be migrated after you have migrated the data. diff --git a/manage-data/migrate/migrate-with-reindex-api.md b/manage-data/migrate/migrate-with-reindex-api.md new file mode 100644 index 0000000000..d3ab3a230e --- /dev/null +++ b/manage-data/migrate/migrate-with-reindex-api.md @@ -0,0 +1,89 @@ +--- +navigation_title: Migrate with the reindex API +applies_to: + serverless: preview 9.3 + deployment: + ess: ga + self: unavailable +products: + - id: elasticsearch + - id: cloud-hosted +--- + +# Migrate {{ech}} data to {{serverless-short}} with the reindex API [migrate-reindex-from-remote] + +The [reindex API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex) offers a convenient way for you to migrate your documents from a source index, data stream, or alias in an {{ech}} deployment to an index in an {{serverless-full}} project. + +:::{admonition} Basic migration +This guide focuses on a basic data migration scenario for moving a full index or selected index documents from an {{ech}} deployment to an {{serverless-full}} project. + +For more advanced use cases, including data modification using scripts or ingest pipelines, refer to the [Reindex indices examples](elasticsearch://reference/elasticsearch/rest-apis/reindex-indices.md#reindex-from-remote) and the [reindex API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-reindex) documentation. + +To migrate data from {{ech}}, you need to include the remote host parameters as shown in the [reindex from remote](elasticsearch://reference/elasticsearch/rest-apis/reindex-indices.md#reindex-from-remote) example and as described here. +::: + +## Prerequisites [migrate-reindex-from-remote-prereqs] + +- An {{ech}} deployment with data to migrate +- A [{{serverless-full}}](/deploy-manage/deploy/elastic-cloud/serverless.md) project configured and running +- An [API key](/deploy-manage/api-keys/elastic-cloud-api-keys.md) for authentication with the {{ech}} deployment + + Basic authentication can be used in place of an API key, but an API key is recommended as a more secure option. + +:::{important} +Kibana assets must be migrated separately using the {{kib}} [export/import APIs](https://www.elastic.co/docs/api/doc/kibana/group/endpoint-saved-objects) or recreated manually. + +Templates, data stream definitions, and ILM policies, must be in place _before_ you start data migration. However, be mindful that if you have any [ingest pipelines](/manage-data/ingest/transform-enrich/ingest-pipelines.md) configured, it's typically best to add these _after_ data migration so as to avoid re-transforming data that had already been transformed at the time that it was ingested into your source deployment (though if the data is idempotent, re-transforming is not a concern). + +Visual components, such dashboard and visualizations, can be migrated after you have migrated the data. +::: + +## Migrate documents from {{ech}} to {{serverless-short}} + +1. In your {{ech}} deployment: + + 1. Navigate to the deployment home page and copy the {{es}} endpoint. + + 1. Go to the **Index Management** page in the navigation menu or use the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). + + 1. Use the search field to identify the indices that you want to migrate. + +1. In your {{serverless-short}} project: + + 1. Open the Developer Tools [Console](/explore-analyze/query-filter/tools/console.md). + + 1. Call the reindex API to migrate your index. If you have multiiple indices to migrate, we recommend doing a separate call for each. + + ``` + POST _reindex + { + "source": { + "remote": { + "host": "https://:443", <1> + "api_key": "" <2> + }, + "index": "" <3> + }, + "dest": { + "index": "" <4> + } + } + ``` + 1. The URL for your {{serverless-short}} project. This is the {{es}} endpoint that you copied in Step 1. + 1. The API key for authenticating the connection to your {{ech}} deployment. + 1. The source index to copy from your {{ech}} deployment. + 1. The destination index in your {{serverless-short}} project. + + 1. Go to the **Index Management** page in the navigation menu or use the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). + + 1. Use the search field to confirm that your destination index has been created with the expected number of documents. + + + + + + + + + + diff --git a/manage-data/toc.yml b/manage-data/toc.yml index b1fad8ba28..dcc616e166 100644 --- a/manage-data/toc.yml +++ b/manage-data/toc.yml @@ -167,8 +167,15 @@ toc: - file: lifecycle/rollup/migrating-from-rollup-to-downsampling.md - file: migrate.md children: - - file: migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md - - file: migrate/migrate-internal-indices.md - - file: migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md - - file: migrate/migrate-with-logstash.md + - file: migrate/migrate-to-serverless.md + children: + - file: migrate/migrate-with-reindex-api.md + - file: migrate/migrate-with-logstash.md + - file: migrate/migrate-to-ech-or-ece.md + children: + - file: migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md + - file: migrate/migrate-using-snapshots.md + children: + - file: migrate/migrate-internal-indices.md + - file: migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md - file: use-case-use-elasticsearch-to-manage-time-series-data.md