Rework migrate data docs (Take 2)

[kilfoyle]

This is a redo of #4914 to reorganize the "Migrate your Elasticsearch data" section of the docs. It:

• Creates a new top-level Migrate your Elasticsearch data page.
• Adds Migrate Elasticsearch data using the reindex API (with the specific example of using reindex from remote to migrate data from ECH to Serverless).
• Reorganizes existing content for easier navigation:
  

Note: one source file was renamed so a few of the files here are included just for link fixes.

---

Closes: #4353
Rel: https://github.com/elastic/docs-team/issues/30
Rel: https://github.com/elastic/docs-content-internal/issues/467

Generative AI disclosure

1. Did you use a generative AI (GenAI) tool to assist in creating this contribution?

• Yes
• No

[github-actions]

Vale Linting Results

Summary: 2 warnings, 2 suggestions found

⚠️ Warnings (2)

File	Line	Rule	Message
manage-data/migrate-data.md	55	Elastic.Spelling	'Snaphot' is a possible misspelling.
manage-data/migrate/migrate-data-using-reindex-api.md	69	Elastic.Spelling	'multiiple' is a possible misspelling.

💡 Suggestions (2)

File	Line	Rule	Message
deploy-manage/deploy/cloud-enterprise/create-deployment.md	50	Elastic.Semicolons	Use semicolons judiciously.
manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md	53	Elastic.WordChoice	Consider using 'can, might' instead of 'may', unless the term is in the UI.

---

The Vale linter checks documentation changes against the Elastic Docs style guide.

To use Vale locally or report issues, refer to Elastic style guide for Vale.

[github-actions]

🔍 Preview links for changed docs

• manage-data/migrate-data.md
• manage-data/migrate/migrate-data-using-reindex-api.md
• deploy-manage/deploy/cloud-enterprise/create-deployment.md
• deploy-manage/deploy/elastic-cloud/azure-native-isv-service.md
• deploy-manage/deploy/elastic-cloud/heroku.md
• manage-data/index.md
• manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md
• manage-data/migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md
• manage-data/migrate/migrate-internal-indices.md
• manage-data/migrate/migrate-with-logstash.md

[pete-naylor]

"from an ECH deployment to an Elastic Cloud Serverless project"

[pete-naylor]

This tip doesn't apply for serverless destinations (as serverless currently only supports ECH sources). This is a general page and the example just happens to be ECH -> ECS, so the tip itself is still valid. But there's something about the placement right here that causes a bit of a context switch for me - or might tend to have readers expecting that it could apply in the example. I wonder if it could fit better somewhere else - maybe even back on the main migration page.

[kilfoyle]

Good point! I've moved this and the whitelisting guidance to a "Notes for migrating between other deployment types" section at the bottom of the page. On the main "Migrate your Elasticsearch Data" page there's also a note guiding people using private CA to the page for that.

[pete-naylor]

This section does not apply for serverless destinations - in serverless, we automatically allow access to all ECH endpoints as source. But this is great information and it needs to be kept somewhere. Do you think we could take this (and perhaps the tip about the certificates above) and shift it to a different section of this page? Somewhere clearly delineated from the guided example?

[kilfoyle]

For sure! I've put this in a new "Notes for migrating between other deployment types" section at the bottom of the page, along with the note for folks using private CA.

[pete-naylor]

ILM does not apply for serverless - perhaps we should mention DLM too? Or just generalize with something like "data lifecycle settings" ?

[kilfoyle]

Changed to Index templates, data stream definitions, and data lifecycle settings must be in place...

[kilfoyle]

Thanks for the superb suggestions @pete-naylor! All fixed. :-)

[shainaraskas]

really great work.

I think that there are some surprisingly quick wins left in terms of recontextualizing the tutorials that currently only look at serverless/ech ... otherwise, some super nice improvements and a win for migrators everywhere.

left a bunch of comments so you prob want a re-review after taking a look. I am super slow so don't consider getting my review to be a requirement (but I can come do another round if you like)

[shainaraskas]

I don't think this title was too gory ... we might avoid renaming it to retain some seo signals even if the title was not perfectly ideal?

[shainaraskas]

would leave these blank so the titles stay in sync

Suggested change

	You can now run a `reindex from remote` reindex operation on the {{ech}} `Destination` cluster from the `Source` cluster, as described in [Migrate Elasticsearch data using the reindex API](/manage-data/migrate/migrate-data-using-reindex-api.md):
	You can now run a `reindex from remote` reindex operation on the {{ech}} `Destination` cluster from the `Source` cluster, as described in [](/manage-data/migrate/migrate-data-using-reindex-api.md):

[shainaraskas]

Suggested change

	To restore system indices from a snapshot, follow the same procedure described in [Migrate Elasticsearch data with minimal downtime using snapshots](/manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md) 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-data-between-elasticsearch-clusters-with-minimal-downtime.md) and select the appropriate feature states when preparing the restore operation, such as `kibana` or `security`.

[shainaraskas]

This is close enough to the next section that i'd skip the parenthetical personally

Suggested change

	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.
	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, the migration methods available for each, and where to find step-by-step guides for your scenario.

[shainaraskas]

when I read "configuration data" I assume things like users might be involved, but that looks like it's feature/component data. can we be more precise here?

[shainaraskas]

I am surprised there are so few "differences" here. it would really improve this tutorial to have an "ECH -> serverless" and "anything -> anything" pathway because there are so few differences. I think that the prerequisites could easily be generalized.

thinking harder about this, it just feels like there is one non-serverless step that needs to happen before the reindex call. could we just make this a tutorial with two major steps?

we could then turn the console step into a tabbed experience with one tab for serverless and one for everything else (if the API calls are different)

[shainaraskas]

switch to stack?

[shainaraskas]

could you update the admonition on line 19 to make it clearer that it's about deployment types? the title "basic migration" isn't very meaningful

[shainaraskas]

again, lower on this page, we only have 3 config options called out. I wonder how specific to ech/serverless this tutorial actually is, and how it could be generalized. feels like it wouldn't need much at all.

might be worth considering as our only link we are using on the migration overview page.

[shainaraskas]

consider hinting that some of these tutorials use specific deployment types as examples, but can be altered for your scenario (less shock/disorientation)