diff --git a/.github/workflows/sync-main-to-jdk-branch.yml b/.github/workflows/sync-main-to-jdk-branch.yml
deleted file mode 100644
index 4e2dcfb0eed76..0000000000000
--- a/.github/workflows/sync-main-to-jdk-branch.yml
+++ /dev/null
@@ -1,21 +0,0 @@
-# Daily update of JDK update branch with changes from main
-name: "Merge main to openjdk23-bundle branch"
-on:
- schedule:
- - cron: "30 17 * * *"
- workflow_dispatch: {}
-
-jobs:
- merge-branch:
- if: github.repository == 'elastic/elasticsearch'
- runs-on: ubuntu-latest
- steps:
- - name: checkout
- uses: actions/checkout@master
-
- - name: merge
- uses: devmasx/merge-branch@1.4.0
- with:
- type: "now"
- target_branch: openjdk23-bundle
- github_token: ${{ secrets.ELASTICSEARCHMACHINE_TOKEN }}
diff --git a/build-tools-internal/src/main/java/org/elasticsearch/gradle/internal/test/rest/RestResourcesPlugin.java b/build-tools-internal/src/main/java/org/elasticsearch/gradle/internal/test/rest/RestResourcesPlugin.java
index 4724c576066f1..c62089a42b159 100644
--- a/build-tools-internal/src/main/java/org/elasticsearch/gradle/internal/test/rest/RestResourcesPlugin.java
+++ b/build-tools-internal/src/main/java/org/elasticsearch/gradle/internal/test/rest/RestResourcesPlugin.java
@@ -39,7 +39,7 @@
* }
* }
*
- * Will copy the entire core Rest API specifications (assuming the project has tests) and any of the the X-pack specs starting with enrich*.
+ * Will copy the entire core Rest API specifications (assuming the project has tests) and any of the X-pack specs starting with enrich*.
* It is recommended (but not required) to also explicitly declare which core specs your project depends on to help optimize the caching
* behavior.
* For example:
@@ -66,7 +66,7 @@
* }
* }
*
- * Will copy any of the the x-pack tests that start with graph, and will copy the X-pack graph specification, as well as the full core
+ * Will copy any of the x-pack tests that start with graph, and will copy the X-pack graph specification, as well as the full core
* Rest API specification.
*
* Additionally you can specify which sourceSetName resources should be copied to. The default is the yamlRestTest source set.
diff --git a/build.gradle b/build.gradle
index 746f964cb6158..2ef0511b2be88 100644
--- a/build.gradle
+++ b/build.gradle
@@ -409,6 +409,10 @@ gradle.projectsEvaluated {
}
}
+tasks.named("validateChangelogs") {
+ onlyIf { project.gradle.startParameter.taskNames.any { it.startsWith("checkPart") || it == 'functionalTests' } == false }
+}
+
tasks.named("precommit") {
dependsOn gradle.includedBuild('build-tools').task(':precommit')
dependsOn gradle.includedBuild('build-tools-internal').task(':precommit')
diff --git a/docs/changelog/115938.yaml b/docs/changelog/115938.yaml
new file mode 100644
index 0000000000000..e096d8821a1d7
--- /dev/null
+++ b/docs/changelog/115938.yaml
@@ -0,0 +1,9 @@
+pr: 115938
+summary: Wait for up to 2 seconds for yellow status before starting search
+area: Machine Learning
+type: bug
+issues:
+ - 107777
+ - 105955
+ - 107815
+ - 112191
diff --git a/docs/reference/connector/docs/connectors-hosted-tutorial-mongo.asciidoc b/docs/reference/connector/docs/connectors-hosted-tutorial-mongo.asciidoc
index a1f7048705555..12050ff17e279 100644
--- a/docs/reference/connector/docs/connectors-hosted-tutorial-mongo.asciidoc
+++ b/docs/reference/connector/docs/connectors-hosted-tutorial-mongo.asciidoc
@@ -90,7 +90,7 @@ Find this by https://www.mongodb.com/docs/atlas/tutorial/connect-to-your-cluster
In this example, we'll use the `sample_mflix` database.
* *Collection*: The name of the collection you want to sync.
In this example, we'll use the `comments` collection of the `sample_mflix` database.
-* *Username*: The username you created earlier, in the the setup phase.
+* *Username*: The username you created earlier, in the setup phase.
* *Password*: The password you created earlier.
Keep these details handy!
diff --git a/docs/reference/esql/esql-query-api.asciidoc b/docs/reference/esql/esql-query-api.asciidoc
index b1582721ad0e0..63b8738266132 100644
--- a/docs/reference/esql/esql-query-api.asciidoc
+++ b/docs/reference/esql/esql-query-api.asciidoc
@@ -46,7 +46,7 @@ supports this parameter for CSV responses.
`drop_null_columns`::
(Optional, boolean) Should columns that are entirely `null` be removed from
the `columns` and `values` portion of the results? Defaults to `false`. If
-`true` the the response will include an extra section under the name
+`true` the response will include an extra section under the name
`all_columns` which has the name of all columns.
`format`::
diff --git a/docs/reference/migration/index.asciidoc b/docs/reference/migration/index.asciidoc
index 719588cb4b0d0..11aca45b003fa 100644
--- a/docs/reference/migration/index.asciidoc
+++ b/docs/reference/migration/index.asciidoc
@@ -1,40 +1,6 @@
include::migration_intro.asciidoc[]
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
+* <>
-include::migrate_8_17.asciidoc[]
-include::migrate_8_16.asciidoc[]
-include::migrate_8_15.asciidoc[]
-include::migrate_8_14.asciidoc[]
-include::migrate_8_13.asciidoc[]
-include::migrate_8_12.asciidoc[]
-include::migrate_8_11.asciidoc[]
-include::migrate_8_10.asciidoc[]
-include::migrate_8_9.asciidoc[]
-include::migrate_8_8.asciidoc[]
-include::migrate_8_7.asciidoc[]
-include::migrate_8_6.asciidoc[]
-include::migrate_8_5.asciidoc[]
-include::migrate_8_4.asciidoc[]
-include::migrate_8_3.asciidoc[]
-include::migrate_8_2.asciidoc[]
-include::migrate_8_1.asciidoc[]
-include::migrate_8_0.asciidoc[]
+include::migrate_9_0.asciidoc[]
diff --git a/docs/reference/migration/migrate_8_0.asciidoc b/docs/reference/migration/migrate_8_0.asciidoc
deleted file mode 100644
index 09433904f2ea8..0000000000000
--- a/docs/reference/migration/migrate_8_0.asciidoc
+++ /dev/null
@@ -1,94 +0,0 @@
-[[migrating-8.0]]
-== Migrating to 8.0
-++++
-8.0
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.0.
-
-See also <> and <>.
-
-[discrete]
-[[breaking-changes-8.0]]
-=== Breaking changes
-
-The following changes in {es} 8.0 might affect your applications
-and prevent them from operating normally.
-Before upgrading to 8.0, review these changes and take the described steps
-to mitigate the impact.
-
-include::migrate_8_0/cluster-node-setting-changes.asciidoc[]
-include::migrate_8_0/command-line-tool-changes.asciidoc[]
-include::migrate_8_0/index-setting-changes.asciidoc[]
-include::migrate_8_0/java-api-changes.asciidoc[]
-include::migrate_8_0/jvm-option-changes.asciidoc[]
-include::migrate_8_0/logging-changes.asciidoc[]
-include::migrate_8_0/mapping-changes.asciidoc[]
-include::migrate_8_0/packaging-changes.asciidoc[]
-include::migrate_8_0/painless-changes.asciidoc[]
-include::migrate_8_0/plugin-changes.asciidoc[]
-include::migrate_8_0/rest-api-changes.asciidoc[]
-include::migrate_8_0/sql-jdbc-changes.asciidoc[]
-include::migrate_8_0/system-req-changes.asciidoc[]
-include::migrate_8_0/transform.asciidoc[]
-
-[discrete]
-[[deprecated-8.0]]
-=== Deprecations
-
-The following functionality has been deprecated in {es} 8.0
-and will be removed in a future version.
-While this won't have an immediate impact on your applications,
-we strongly encourage you take the described steps to update your code
-after upgrading to 8.0.
-
-To find out if you are using any deprecated functionality,
-enable <>.
-
-[discrete]
-[[breaking_80_cluster_node_setting_deprecations]]
-==== Cluster and node setting deprecations
-
-[[deprecate-transient-cluster-settings]]
-.We no longer recommend using transient cluster settings.
-[%collapsible]
-====
-*Details* +
-We no longer recommend using transient cluster settings. Use persistent cluster
-settings instead. If a cluster becomes unstable, transient settings can clear
-unexpectedly, resulting in an undesired cluster configuration.
-
-*Impact* +
-Transient cluster settings are not yet deprecated, but we plan to deprecate them
-in a future release. For migration steps, see the
-{ref}/transient-settings-migration-guide.html[Transient settings migration
-guide].
-====
-
-[discrete]
-[[breaking_80_command_line_tool_deprecations]]
-==== Command line tool deprecations
-
-TIP: {ess-skip-section}
-
-[[deprecate-elasticsearch-setup-passwords]]
-.The `elasticsearch-setup-passwords` tool is deprecated.
-[%collapsible]
-====
-*Details* +
-The `elasticsearch-setup-passwords` tool is deprecated in 8.0. To
-manually reset the password for built-in users (including the `elastic` user), use
-the {ref}/reset-password.html[`elasticsearch-reset-password`] tool, the {es}
-{ref}/security-api-change-password.html[change passwords API], or the
-User Management features in {kib}.
-`elasticsearch-setup-passwords` will be removed in a future release.
-
-*Impact* +
-Passwords are generated automatically for the `elastic` user when you start {es} for the first time. If you run `elasticsearch-setup-passwords` after
-starting {es}, it will fail because the `elastic`
-user password is already configured.
-====
-
-include::migrate_8_0/migrate_to_java_time.asciidoc[]
-include::transient-settings-migration-guide.asciidoc[]
diff --git a/docs/reference/migration/migrate_8_0/cluster-node-setting-changes.asciidoc b/docs/reference/migration/migrate_8_0/cluster-node-setting-changes.asciidoc
deleted file mode 100644
index bad4ab93676bb..0000000000000
--- a/docs/reference/migration/migrate_8_0/cluster-node-setting-changes.asciidoc
+++ /dev/null
@@ -1,931 +0,0 @@
-[discrete]
-[[breaking_80_cluster_node_setting_changes]]
-==== Cluster and node setting changes
-
-TIP: {ess-setting-change}
-
-.`action.destructive_requires_name` now defaults to `true`. {ess-icon}
-[%collapsible]
-====
-*Details* +
-The default for the `action.destructive_requires_name` setting changes from `false`
-to `true` in {es} 8.0.0.
-
-Previously, defaulting to `false` allowed users to use wildcard
-patterns to delete, close, or change index blocks on indices.
-To prevent the accidental deletion of indices that happen to match a
-wildcard pattern, we now default to requiring that destructive
-operations explicitly name the indices to be modified.
-
-*Impact* +
-To use wildcard patterns for destructive actions, set
-`action.destructive_requires_name` to `false` using the
-{ref}/cluster-update-settings.html[] cluster settings API].
-====
-
-.You can no longer set `xpack.searchable.snapshot.shared_cache.size` on non-frozen nodes.
-[%collapsible]
-====
-*Details* +
-You can no longer set
-{ref}/searchable-snapshots.html#searchable-snapshots-shared-cache[`xpack.searchable.snapshot.shared_cache.size`]
-on a node that doesn't have the `data_frozen` node role. This setting reserves
-disk space for the shared cache of partially mounted indices. {es} only
-allocates partially mounted indices to nodes with the `data_frozen` role.
-
-*Impact* +
-Remove `xpack.searchable.snapshot.shared_cache.size` from `elasticsearch.yml`
-for nodes that don't have the `data_frozen` role. Specifying the setting on a
-non-frozen node will result in an error on startup.
-====
-
-[[max_clause_count_change]]
-.`indices.query.bool.max_clause_count` is deprecated and has no effect.
-[%collapsible]
-====
-*Details* +
-Elasticsearch will now dynamically set the maximum number of allowed clauses
-in a query, using a heuristic based on the size of the search thread pool and
-the size of the heap allocated to the JVM. This limit has a minimum value of
-1024 and will in most cases be larger (for example, a node with 30Gb RAM and
-48 CPUs will have a maximum clause count of around 27,000). Larger heaps lead
-to higher values, and larger thread pools result in lower values.
-
-*Impact* +
-Queries with many clauses should be avoided whenever possible.
-If you previously bumped this setting to accommodate heavy queries,
-you might need to increase the amount of memory available to Elasticsearch,
-or to reduce the size of your search thread pool so that more memory is
-available to each concurrent search.
-
-In previous versions of Lucene you could get around this limit by nesting
-boolean queries within each other, but the limit is now based on the total
-number of leaf queries within the query as a whole and this workaround will
-no longer help.
-
-Specifying `indices.query.bool.max_clause_count` will have no effect
-but will generate deprecation warnings. To avoid these warnings, remove the
-setting from `elasticsearch.yml` during an upgrade or node restart.
-====
-
-[[ilm-poll-interval-limit]]
-.`indices.lifecycle.poll_interval` must be greater than `1s`.
-[%collapsible]
-====
-*Details* +
-Setting `indices.lifecycle.poll_interval` too low can cause
-excessive load on a cluster. The poll interval must now be at least `1s` (one second).
-
-*Impact* +
-Set `indices.lifecycle.poll_interval` setting to `1s` or
-greater in `elasticsearch.yml` or through the
-{ref}/cluster-update-settings.html[cluster update settings API].
-
-Setting `indices.lifecycle.poll_interval` to less than `1s` in
-`elasticsearch.yml` will result in an error on startup.
-{ref}/cluster-update-settings.html[Cluster update settings API] requests that
-set `indices.lifecycle.poll_interval` to less than `1s` will return an error.
-====
-
-.The file and native realms are now enabled unless explicitly disabled.
-[%collapsible]
-====
-*Details* +
-The file and native realms are now enabled unless explicitly disabled. If
-explicitly disabled, the file and native realms remain disabled at all times.
-
-Previously, the file and native realms had the following implicit behaviors:
-
-* If the file and native realms were not configured, they were implicitly disabled
-if any other realm was configured.
-
-* If no other realm was available because realms were either not configured,
-not permitted by license, or explicitly disabled, the file and native realms
-were enabled, even if explicitly disabled.
-
-*Impact* +
-To explicitly disable the file or native realm, set the respective
-`file..enabled` or `native..enabled` setting to `false`
-under the `xpack.security.authc.realms` namespace in `elasticsearch.yml`.
-
-The following configuration example disables the native realm and the file realm.
-
-[source,yaml]
-----
-xpack.security.authc.realms:
-
- native.realm1.enabled: false
- file.realm2.enabled: false
-
- ...
-----
-====
-
-.The realm `order` setting is now required.
-[%collapsible]
-====
-*Details* +
-The `xpack.security.authc.realms.{type}.{name}.order` setting is now required and must be
-specified for each explicitly configured realm. Each value must be unique.
-
-*Impact* +
-The cluster will fail to start if the requirements are not met.
-
-For example, the following configuration is invalid:
-[source,yaml]
---------------------------------------------------
-xpack.security.authc.realms.kerberos.kerb1:
- keytab.path: es.keytab
- remove_realm_name: false
---------------------------------------------------
-
-And must be configured as:
-[source,yaml]
---------------------------------------------------
-xpack.security.authc.realms.kerberos.kerb1:
- order: 0
- keytab.path: es.keytab
- remove_realm_name: false
---------------------------------------------------
-====
-
-[[breaking_80_allocation_change_include_relocations_removed]]
-.`cluster.routing.allocation.disk.include_relocations` has been removed.
-[%collapsible]
-====
-*Details* +
-{es} now always accounts for the sizes of relocating shards when making
-allocation decisions based on the disk usage of the nodes in the cluster. In
-earlier versions, you could disable this by setting `cluster.routing.allocation.disk.include_relocations` to `false`.
-That could result in poor allocation decisions that could overshoot watermarks and require significant
-extra work to correct. The `cluster.routing.allocation.disk.include_relocations` setting has been removed.
-
-*Impact* +
-Remove the `cluster.routing.allocation.disk.include_relocations`
-setting. Specifying this setting in `elasticsearch.yml` will result in an error
-on startup.
-====
-
-.`cluster.join.timeout` has been removed.
-[%collapsible]
-====
-*Details* +
-The `cluster.join.timeout` setting has been removed. Join attempts no longer
-time out.
-
-*Impact* +
-Remove `cluster.join.timeout` from `elasticsearch.yml`.
-====
-
-.`discovery.zen` settings have been removed.
-[%collapsible]
-====
-*Details* +
-All settings under the `discovery.zen` namespace are no longer supported. They existed only only for BWC reasons in 7.x. This includes:
-
-- `discovery.zen.minimum_master_nodes`
-- `discovery.zen.no_master_block`
-- `discovery.zen.hosts_provider`
-- `discovery.zen.publish_timeout`
-- `discovery.zen.commit_timeout`
-- `discovery.zen.publish_diff.enable`
-- `discovery.zen.ping.unicast.concurrent_connects`
-- `discovery.zen.ping.unicast.hosts.resolve_timeout`
-- `discovery.zen.ping.unicast.hosts`
-- `discovery.zen.ping_timeout`
-- `discovery.zen.unsafe_rolling_upgrades_enabled`
-- `discovery.zen.fd.connect_on_network_disconnect`
-- `discovery.zen.fd.ping_interval`
-- `discovery.zen.fd.ping_timeout`
-- `discovery.zen.fd.ping_retries`
-- `discovery.zen.fd.register_connection_listener`
-- `discovery.zen.join_retry_attempts`
-- `discovery.zen.join_retry_delay`
-- `discovery.zen.join_timeout`
-- `discovery.zen.max_pings_from_another_master`
-- `discovery.zen.send_leave_request`
-- `discovery.zen.master_election.wait_for_joins_timeout`
-- `discovery.zen.master_election.ignore_non_master_pings`
-- `discovery.zen.publish.max_pending_cluster_states`
-- `discovery.zen.bwc_ping_timeout`
-
-*Impact* +
-Remove the `discovery.zen` settings from `elasticsearch.yml`. Specifying these settings will result in an error on startup.
-====
-
-.`http.content_type.required` has been removed.
-[%collapsible]
-====
-*Details* +
-The `http.content_type.required` setting was deprecated in Elasticsearch 6.0
-and has been removed in Elasticsearch 8.0. The setting was introduced in
-Elasticsearch 5.3 to prepare users for Elasticsearch 6.0, where content type
-auto detection was removed for HTTP requests.
-
-*Impact* +
-Remove the `http.content_type.required` setting from `elasticsearch.yml`. Specifying this setting will result in an error on startup.
-====
-
-.`http.tcp_no_delay` has been removed.
-[%collapsible]
-====
-*Details* +
-The `http.tcp_no_delay` setting was deprecated in 7.x and has been removed in 8.0. Use `http.tcp.no_delay` instead.
-
-*Impact* +
-Replace the `http.tcp_no_delay` setting with `http.tcp.no_delay`.
-Specifying `http.tcp_no_delay` in `elasticsearch.yml` will
-result in an error on startup.
-====
-
-.`network.tcp.connect_timeout` has been removed.
-[%collapsible]
-====
-*Details* +
-The `network.tcp.connect_timeout` setting was deprecated in 7.x and has been removed in 8.0. This setting
-was a fallback setting for `transport.connect_timeout`.
-
-*Impact* +
-Remove the `network.tcp.connect_timeout` setting.
-Use the `transport.connect_timeout` setting to change the default connection
-timeout for client connections. Specifying
-`network.tcp.connect_timeout` in `elasticsearch.yml` will result in an
-error on startup.
-====
-
-.`node.max_local_storage_nodes` has been removed.
-[%collapsible]
-====
-*Details* +
-The `node.max_local_storage_nodes` setting was deprecated in 7.x and
-has been removed in 8.0. Nodes should be run on separate data paths
-to ensure that each node is consistently assigned to the same data path.
-
-*Impact* +
-Remove the `node.max_local_storage_nodes` setting. Specifying this
-setting in `elasticsearch.yml` will result in an error on startup.
-====
-
-[[accept-default-password-removed]]
-.The `accept_default_password` setting has been removed.
-[%collapsible]
-====
-*Details* +
-The `xpack.security.authc.accept_default_password` setting has not had any affect
-since the 6.0 release of {es} and is no longer allowed.
-
-*Impact* +
-Remove the `xpack.security.authc.accept_default_password` setting from `elasticsearch.yml`.
-Specifying this setting will result in an error on startup.
-====
-
-[[roles-index-cache-removed]]
-.The `roles.index.cache.*` settings have been removed.
-[%collapsible]
-====
-*Details* +
-The `xpack.security.authz.store.roles.index.cache.max_size` and
-`xpack.security.authz.store.roles.index.cache.ttl` settings have
-been removed. These settings have been redundant and deprecated
-since the 5.2 release of {es}.
-
-*Impact* +
-Remove the `xpack.security.authz.store.roles.index.cache.max_size`
-and `xpack.security.authz.store.roles.index.cache.ttl` settings from `elasticsearch.yml` .
-Specifying these settings will result in an error on startup.
-====
-
-[[separating-node-and-client-traffic]]
-.The `transport.profiles.*.xpack.security.type` setting has been removed.
-[%collapsible]
-====
-*Details* +
-The `transport.profiles.*.xpack.security.type` setting is no longer supported.
-The Transport Client has been removed and all client traffic now uses
-the HTTP transport. Transport profiles using this setting should be removed.
-
-*Impact* +
-Remove the `transport.profiles.*.xpack.security.type` setting from `elasticsearch.yml`.
-Specifying this setting in a transport profile will result in an error on startup.
-====
-
-[discrete]
-[[saml-realm-nameid-changes]]
-.The `nameid_format` SAML realm setting no longer has a default value.
-[%collapsible]
-====
-*Details* +
-In SAML, Identity Providers (IdPs) can either be explicitly configured to
-release a `NameID` with a specific format, or configured to attempt to conform
-with the requirements of a Service Provider (SP). The SP declares its
-requirements in the `NameIDPolicy` element of a SAML Authentication Request.
-In {es}, the `nameid_format` SAML realm setting controls the `NameIDPolicy`
-value.
-
-Previously, the default value for `nameid_format` was
-`urn:oasis:names:tc:SAML:2.0:nameid-format:transient`. This setting created
-authentication requests that required the IdP to release `NameID` with a
-`transient` format.
-
-The default value has been removed, which means that {es} will create SAML Authentication Requests by default that don't put this requirement on the
-IdP. If you want to retain the previous behavior, set `nameid_format` to
-`urn:oasis:names:tc:SAML:2.0:nameid-format:transient`.
-
-*Impact* +
-If you currently don't configure `nameid_format` explicitly, it's possible
-that your IdP will reject authentication requests from {es} because the requests
-do not specify a `NameID` format (and your IdP is configured to expect one).
-This mismatch can result in a broken SAML configuration. If you're unsure whether
-your IdP is explicitly configured to use a certain `NameID` format and you want to retain current behavior
-, try setting `nameid_format` to `urn:oasis:names:tc:SAML:2.0:nameid-format:transient` explicitly.
-====
-
-.The `xpack.security.transport.ssl.enabled` setting is now required to configure `xpack.security.transport.ssl` settings.
-[%collapsible]
-====
-*Details* +
-It is now an error to configure any SSL settings for
-`xpack.security.transport.ssl` without also configuring
-`xpack.security.transport.ssl.enabled`.
-
-*Impact* +
-If using other `xpack.security.transport.ssl` settings, you must explicitly
-specify the `xpack.security.transport.ssl.enabled` setting.
-
-If you do not want to enable SSL and are currently using other
-`xpack.security.transport.ssl` settings, do one of the following:
-
-* Explicitly specify `xpack.security.transport.ssl.enabled` as `false`
-* Discontinue use of other `xpack.security.transport.ssl` settings
-
-If you want to enable SSL, follow the instructions in
-{ref}/configuring-tls.html#tls-transport[Encrypting communications between nodes
-in a cluster]. As part of this configuration, explicitly specify
-`xpack.security.transport.ssl.enabled` as `true`.
-
-For example, the following configuration is invalid:
-[source,yaml]
---------------------------------------------------
-xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
-xpack.security.transport.ssl.truststore.path: elastic-certificates.p12
---------------------------------------------------
-
-And must be configured as:
-[source,yaml]
---------------------------------------------------
-xpack.security.transport.ssl.enabled: true <1>
-xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
-xpack.security.transport.ssl.truststore.path: elastic-certificates.p12
---------------------------------------------------
-<1> or `false`.
-====
-
-.The `xpack.security.http.ssl.enabled` setting is now required to configure `xpack.security.http.ssl` settings.
-[%collapsible]
-====
-*Details* +
-It is now an error to configure any SSL settings for
-`xpack.security.http.ssl` without also configuring
-`xpack.security.http.ssl.enabled`.
-
-*Impact* +
-If using other `xpack.security.http.ssl` settings, you must explicitly
-specify the `xpack.security.http.ssl.enabled` setting.
-
-If you do not want to enable SSL and are currently using other
-`xpack.security.http.ssl` settings, do one of the following:
-
-* Explicitly specify `xpack.security.http.ssl.enabled` as `false`
-* Discontinue use of other `xpack.security.http.ssl` settings
-
-If you want to enable SSL, follow the instructions in
-{ref}/security-basic-setup-https.html#encrypt-http-communication[Encrypting HTTP client communications]. As part
-of this configuration, explicitly specify `xpack.security.http.ssl.enabled`
-as `true`.
-
-For example, the following configuration is invalid:
-[source,yaml]
---------------------------------------------------
-xpack.security.http.ssl.certificate: elasticsearch.crt
-xpack.security.http.ssl.key: elasticsearch.key
-xpack.security.http.ssl.certificate_authorities: [ "corporate-ca.crt" ]
---------------------------------------------------
-
-And must be configured as either:
-[source,yaml]
---------------------------------------------------
-xpack.security.http.ssl.enabled: true <1>
-xpack.security.http.ssl.certificate: elasticsearch.crt
-xpack.security.http.ssl.key: elasticsearch.key
-xpack.security.http.ssl.certificate_authorities: [ "corporate-ca.crt" ]
---------------------------------------------------
-<1> or `false`.
-====
-
-.A `xpack.security.transport.ssl` certificate and key are now required to enable SSL for the transport interface.
-[%collapsible]
-====
-*Details* +
-It is now an error to enable SSL for the transport interface without also configuring
-a certificate and key through use of the `xpack.security.transport.ssl.keystore.path`
-setting or the `xpack.security.transport.ssl.certificate` and
-`xpack.security.transport.ssl.key` settings.
-
-*Impact* +
-If `xpack.security.transport.ssl.enabled` is set to `true`, provide a
-certificate and key using the `xpack.security.transport.ssl.keystore.path`
-setting or the `xpack.security.transport.ssl.certificate` and
-`xpack.security.transport.ssl.key` settings. If a certificate and key is not
-provided, {es} will return in an error on startup.
-====
-
-.A `xpack.security.http.ssl` certificate and key are now required to enable SSL for the HTTP server.
-[%collapsible]
-====
-*Details* +
-It is now an error to enable SSL for the HTTP (Rest) server without also configuring
-a certificate and key through use of the `xpack.security.http.ssl.keystore.path`
-setting or the `xpack.security.http.ssl.certificate` and
-`xpack.security.http.ssl.key` settings.
-
-*Impact* +
-If `xpack.security.http.ssl.enabled` is set to `true`, provide a certificate and
-key using the `xpack.security.http.ssl.keystore.path` setting or the
-`xpack.security.http.ssl.certificate` and `xpack.security.http.ssl.key`
-settings. If certificate and key is not provided, {es} will return in an error
-on startup.
-====
-
-.PKCS#11 keystores and trustores cannot be configured in `elasticsearch.yml`
-[%collapsible]
-====
-*Details* +
-The settings `*.ssl.keystore.type` and `*.ssl.truststore.type` no longer accept "PKCS11" as a valid type.
-This applies to all SSL settings in Elasticsearch, including
-
-- `xpack.security.http.keystore.type`
-- `xpack.security.transport.keystore.type`
-- `xpack.security.http.truststore.type`
-- `xpack.security.transport.truststore.type`
-
-As well as SSL settings for security realms, watcher and monitoring.
-
-Use of a PKCS#11 keystore or truststore as the JRE's default store is not affected.
-
-*Impact* +
-If you have a PKCS#11 keystore configured within your `elasticsearch.yml` file, you must remove that
-configuration and switch to a supported keystore type, or configure your PKCS#11 keystore as the
-JRE default store.
-====
-
-.The `kibana` user has been replaced by `kibana_system`.
-[%collapsible]
-====
-*Details* +
-The `kibana` user was historically used to authenticate {kib} to {es}.
-The name of this user was confusing, and was often mistakenly used to login to {kib}.
-This has been renamed to `kibana_system` in order to reduce confusion, and to better
-align with other built-in system accounts.
-
-*Impact* +
-Replace any use of the `kibana` user with the `kibana_system` user. Specifying
-the `kibana` user in `kibana.yml` will result in an error on startup.
-
-If your `kibana.yml` used to contain:
-[source,yaml]
---------------------------------------------------
-elasticsearch.username: kibana
---------------------------------------------------
-
-then you should update to use the new `kibana_system` user instead:
-[source,yaml]
---------------------------------------------------
-elasticsearch.username: kibana_system
---------------------------------------------------
-
-IMPORTANT: The new `kibana_system` user does not preserve the previous `kibana`
-user password. You must explicitly set a password for the `kibana_system` user.
-====
-
-[[search-remote-settings-removed]]
-.The `search.remote.*` settings have been removed.
-[%collapsible]
-====
-*Details* +
-In 6.5 these settings were deprecated in favor of `cluster.remote`. In 7.x we
-provided automatic upgrading of these settings to their `cluster.remote`
-counterparts. In 8.0.0, these settings have been removed. Elasticsearch will
-refuse to start if you have these settings in your configuration or cluster
-state.
-
-*Impact* +
-Use the replacement `cluster.remote` settings. Discontinue use of the
-`search.remote.*` settings. Specifying these settings in `elasticsearch.yml`
-will result in an error on startup.
-====
-
-[[remove-pidfile]]
-.The `pidfile` setting has been replaced by `node.pidfile`.
-[%collapsible]
-====
-*Details* +
-To ensure that all settings are in a proper namespace, the `pidfile` setting was
-previously deprecated in version 7.4.0 of Elasticsearch, and is removed in
-version 8.0.0. Instead, use `node.pidfile`.
-
-*Impact* +
-Use the `node.pidfile` setting. Discontinue use of the `pidfile` setting.
-Specifying the `pidfile` setting in `elasticsearch.yml` will result in an error
-on startup.
-====
-
-[[remove-processors]]
-.The `processors` setting has been replaced by `node.processors`.
-[%collapsible]
-====
-*Details* +
-To ensure that all settings are in a proper namespace, the `processors` setting
-was previously deprecated in version 7.4.0 of Elasticsearch, and is removed in
-version 8.0.0. Instead, use `node.processors`.
-
-*Impact* +
-Use the `node.processors` setting. Discontinue use of the `processors` setting.
-Specifying the `processors` setting in `elasticsearch.yml` will result in an
-error on startup.
-====
-
-.The `node.processors` setting can no longer exceed the available number of processors.
-[%collapsible]
-====
-*Details* +
-Previously it was possible to set the number of processors used to set the
-default sizes for the thread pools to be more than the number of available
-processors. As this leads to more context switches and more threads but without
-an increase in the number of physical CPUs on which to schedule these additional
-threads, the `node.processors` setting is now bounded by the number of available
-processors.
-
-*Impact* +
-If specified, ensure the value of `node.processors` setting does not exceed the
-number of available processors. Setting the `node.processors` value greater than
-the number of available processors in `elasticsearch.yml` will result in an
-error on startup.
-====
-
-.The `cluster.remote.connect` setting has been removed.
-[%collapsible]
-====
-*Details* +
-In Elasticsearch 7.7.0, the setting `cluster.remote.connect` was deprecated in
-favor of setting `node.remote_cluster_client`. In Elasticsearch 8.0.0, the
-setting `cluster.remote.connect` is removed.
-
-*Impact* +
-Use the `node.remote_cluster_client` setting. Discontinue use of the
-`cluster.remote.connect` setting. Specifying the `cluster.remote.connect`
-setting in `elasticsearch.yml` will result in an error on startup.
-====
-
-.The `node.local_storage` setting has been removed.
-[%collapsible]
-====
-*Details* +
-In Elasticsearch 7.8.0, the setting `node.local_storage` was deprecated and
-beginning in Elasticsearch 8.0.0 all nodes will require local storage. Therefore,
-the `node.local_storage` setting has been removed.
-
-*Impact* +
-Discontinue use of the `node.local_storage` setting. Specifying this setting in
-`elasticsearch.yml` will result in an error on startup.
-====
-
-.The `auth.password` setting for HTTP monitoring has been removed.
-[%collapsible]
-====
-*Details* +
-In Elasticsearch 7.7.0, the setting `xpack.monitoring.exporters..auth.password`
-was deprecated in favor of setting `xpack.monitoring.exporters..auth.secure_password`.
-In Elasticsearch 8.0.0, the setting `xpack.monitoring.exporters..auth.password` is
-removed.
-
-*Impact* +
-Use the `xpack.monitoring.exporters..auth.secure_password`
-setting. Discontinue use of the
-`xpack.monitoring.exporters..auth.password` setting. Specifying
-the `xpack.monitoring.exporters..auth.password` setting in
-`elasticsearch.yml` will result in an error on startup.
-====
-
-.Settings used to disable basic license features have been removed.
-[%collapsible]
-====
-*Details* +
-The following settings were deprecated in {es} 7.8.0 and have been removed
-in {es} 8.0.0:
-
-* `xpack.enrich.enabled`
-* `xpack.flattened.enabled`
-* `xpack.ilm.enabled`
-* `xpack.monitoring.enabled`
-* `xpack.rollup.enabled`
-* `xpack.slm.enabled`
-* `xpack.sql.enabled`
-* `xpack.transform.enabled`
-* `xpack.vectors.enabled`
-
-These basic license features are now always enabled.
-
-If you have disabled ILM so that you can use another tool to manage Watcher
-indices, the newly introduced `xpack.watcher.use_ilm_index_management` setting
-may be set to false.
-
-*Impact* +
-Discontinue use of the removed settings. Specifying these settings in
-`elasticsearch.yml` will result in an error on startup.
-====
-
-.Settings used to defer cluster recovery pending a certain number of master nodes have been removed.
-[%collapsible]
-====
-*Details* +
-The following cluster settings have been removed:
-
-* `gateway.expected_nodes`
-* `gateway.expected_master_nodes`
-* `gateway.recover_after_nodes`
-* `gateway.recover_after_master_nodes`
-
-It is safe to recover the cluster as soon as a majority of master-eligible
-nodes have joined so there is no benefit in waiting for any additional
-master-eligible nodes to start.
-
-*Impact* +
-Discontinue use of the removed settings. If needed, use
-`gateway.expected_data_nodes` or `gateway.recover_after_data_nodes` to defer
-cluster recovery pending a certain number of data nodes.
-====
-
-.Legacy role settings have been removed.
-[%collapsible]
-====
-*Details* +
-The legacy role settings:
-
-* `node.data`
-* `node.ingest`
-* `node.master`
-* `node.ml`
-* `node.remote_cluster_client`
-* `node.transform`
-* `node.voting_only`
-
-have been removed. Instead, use the `node.roles` setting. If you were previously
-using the legacy role settings on a 7.13 or later cluster, you will have a
-deprecation log message on each of your nodes indicating the exact replacement
-value for `node.roles`.
-
-*Impact* +
-Discontinue use of the removed settings. Specifying these settings in
-`elasticsearch.yml` will result in an error on startup.
-====
-
-[[system-call-filter-setting]]
-.The system call filter setting has been removed.
-[%collapsible]
-====
-*Details* +
-Elasticsearch uses system call filters to remove its ability to fork another
-process. This is useful to mitigate remote code exploits. These system call
-filters are enabled by default, and were previously controlled via the setting
-`bootstrap.system_call_filter`. Starting in Elasticsearch 8.0, system call
-filters will be required. As such, the setting `bootstrap.system_call_filter`
-was deprecated in Elasticsearch 7.13.0, and is removed as of Elasticsearch
-8.0.0.
-
-*Impact* +
-Discontinue use of the removed setting. Specifying this setting in Elasticsearch
-configuration will result in an error on startup.
-====
-
-[[tier-filter-setting]]
-.Tier filtering settings have been removed.
-[%collapsible]
-====
-*Details* +
-The cluster and index level settings ending in `._tier` used for filtering the allocation of a shard
-to a particular set of nodes have been removed. Instead, the
-{ref}/data-tier-shard-filtering.html#tier-preference-allocation-filter[tier
-preference setting], `index.routing.allocation.include._tier_preference` should
-be used. The removed settings are:
-
-Cluster level settings:
-
-- `cluster.routing.allocation.include._tier`
-- `cluster.routing.allocation.exclude._tier`
-- `cluster.routing.allocation.require._tier`
-
-Index settings:
-
-- `index.routing.allocation.include._tier`
-- `index.routing.allocation.exclude._tier`
-- `index.routing.allocation.require._tier`
-
-*Impact* +
-Discontinue use of the removed settings. Specifying any of these cluster settings in Elasticsearch
-configuration will result in an error on startup. Any indices using these settings will have the
-settings archived (and they will have no effect) when the index metadata is loaded.
-====
-
-[[shared-data-path-setting]]
-.Shared data path and per index data path settings are deprecated.
-[%collapsible]
-====
-*Details* +
-Elasticsearch uses the shared data path as the base path of per index data
-paths. This feature was previously used with shared replicas. Starting in
-7.13.0, these settings are deprecated. Starting in 8.0 only existing
-indices created in 7.x will be capable of using the shared data path and
-per index data path settings.
-
-*Impact* +
-Discontinue use of the deprecated settings.
-====
-
-[[single-data-node-watermark-setting]]
-.The single data node watermark setting is deprecated and now only accepts `true`.
-[%collapsible]
-====
-*Details* +
-In 7.14, setting `cluster.routing.allocation.disk.watermark.enable_for_single_data_node`
-to false was deprecated. Starting in 8.0, the only legal value will be
-true. In a future release, the setting will be removed completely, with same
-behavior as if the setting was `true`.
-
-If the old behavior is desired for a single data node cluster, disk based
-allocation can be disabled by setting
-`cluster.routing.allocation.disk.threshold_enabled: false`
-
-*Impact* +
-Discontinue use of the deprecated setting.
-====
-
-[[auto-import-dangling-indices-removed]]
-.The `gateway.auto_import_dangling_indices` setting has been removed.
-[%collapsible]
-====
-*Details* +
-The `gateway.auto_import_dangling_indices` cluster setting has been removed.
-Previously, you could use this setting to automatically import
-{ref}/modules-gateway.html#dangling-indices[dangling indices]. However,
-automatically importing dangling indices is unsafe. Use the
-{ref}/indices.html#dangling-indices-api[dangling indices APIs] to manage and
-import dangling indices instead.
-
-*Impact* +
-Discontinue use of the removed setting. Specifying the setting in
-`elasticsearch.yml` will result in an error on startup.
-====
-
-.The `listener` thread pool has been removed.
-[%collapsible]
-====
-*Details* +
-Previously, the transport client used the thread pool to ensure listeners aren't
-called back on network threads. The transport client has been removed
-in 8.0, and the thread pool is no longer needed.
-
-*Impact* +
-Remove `listener` thread pool settings from `elasticsearch.yml` for any nodes.
-Specifying `listener` thread pool settings in `elasticsearch.yml` will result in
-an error on startup.
-====
-
-.The `fixed_auto_queue_size` thread pool type has been removed.
-[%collapsible]
-====
-*Details* +
-The `fixed_auto_queue_size` thread pool type, previously marked as an
-experimental feature, was deprecated in 7.x and has been removed in 8.0.
-The `search` and `search_throttled` thread pools have the `fixed` type now.
-
-*Impact* +
-No action needed.
-====
-
-.Several `transport` settings have been replaced.
-[%collapsible]
-====
-*Details* +
-The following settings have been deprecated in 7.x and removed in 8.0. Each setting has a replacement
-setting that was introduced in 6.7.
-
-- `transport.tcp.port` replaced by `transport.port`
-- `transport.tcp.compress` replaced by `transport.compress`
-- `transport.tcp.connect_timeout` replaced by `transport.connect_timeout`
-- `transport.tcp_no_delay` replaced by `transport.tcp.no_delay`
-- `transport.profiles.profile_name.tcp_no_delay` replaced by `transport.profiles.profile_name.tcp.no_delay`
-- `transport.profiles.profile_name.tcp_keep_alive` replaced by `transport.profiles.profile_name.tcp.keep_alive`
-- `transport.profiles.profile_name.reuse_address` replaced by `transport.profiles.profile_name.tcp.reuse_address`
-- `transport.profiles.profile_name.send_buffer_size` replaced by `transport.profiles.profile_name.tcp.send_buffer_size`
-- `transport.profiles.profile_name.receive_buffer_size` replaced by `transport.profiles.profile_name.tcp.receive_buffer_size`
-
-*Impact* +
-Use the replacement settings. Discontinue use of the removed settings.
-Specifying the removed settings in `elasticsearch.yml` will result in an error
-on startup.
-====
-
-.Selective transport compression has been enabled by default.
-[%collapsible]
-====
-*Details* +
-Prior to 8.0, transport compression was disabled by default. Starting in 8.0,
-`transport.compress` defaults to `indexing_data`. This configuration means that
-the propagation of raw indexing data will be compressed between nodes.
-
-*Impact* +
-Inter-node transit will get reduced along the indexing path. In some scenarios,
-CPU usage could increase.
-====
-
-.Transport compression defaults to lz4.
-[%collapsible]
-====
-*Details* +
-Prior to 8.0, the `transport.compression_scheme` setting defaulted to `deflate`. Starting in
-8.0, `transport.compress_scheme` defaults to `lz4`.
-
-Prior to 8.0, the `cluster.remote..transport.compression_scheme`
-setting defaulted to `deflate` when `cluster.remote..transport.compress`
-was explicitly configured. Starting in 8.0,
-`cluster.remote..transport.compression_scheme` will fallback to
-`transport.compression_scheme` by default.
-
-*Impact* +
-This configuration means that transport compression will produce somewhat lower
-compression ratios in exchange for lower CPU load.
-====
-
-.The `repositories.fs.compress` node-level setting has been removed.
-[%collapsible]
-====
-*Details* +
-For shared file system repositories (`"type": "fs"`), the node level setting `repositories.fs.compress` could
-previously be used to enable compression for all shared file system repositories where `compress` was not specified.
-The `repositories.fs.compress` setting has been removed.
-
-*Impact* +
-Discontinue use of the `repositories.fs.compress` node-level setting. Use the
-repository-specific `compress` setting to enable compression instead. Refer to
-{ref}/snapshots-filesystem-repository.html#filesystem-repository-settings[Shared
-file system repository settings].
-====
-
-// This change is not notable because it should not have any impact on upgrades
-// However we document it here out of an abundance of caution
-[[fips-default-hash-changed]]
-.When FIPS mode is enabled the default password hash is now PBKDF2_STRETCH
-[%collapsible]
-====
-*Details* +
-If `xpack.security.fips_mode.enabled` is true (see <>),
-the value of `xpack.security.authc.password_hashing.algorithm` now defaults to
-`pbkdf2_stretch`.
-
-In earlier versions this setting would always default to `bcrypt` and a runtime
-check would prevent a node from starting unless the value was explicitly set to
-a "pbkdf2" variant.
-
-There is no change for clusters that do not enable FIPS 140 mode.
-
-*Impact* +
-This change should not have any impact on upgraded nodes.
-Any node with an explicitly configured value for the password hashing algorithm
-will continue to use that configured value.
-Any node that did not have an explicitly configured password hashing algorithm in
-{es} 6.x or {es} 7.x would have failed to start.
-====
-
-.The `xpack.monitoring.history.duration` will not delete indices created by metricbeat or elastic agent
-[%collapsible]
-====
-*Details* +
-
-Prior to 8.0, Elasticsearch would internally handle removal of all monitoring indices according to the
-`xpack.monitoring.history.duration` setting.
-
-When using metricbeat or elastic agent >= 8.0 to collect monitoring data, indices are managed via an ILM policy. If the setting is present, the policy will be created using the `xpack.monitoring.history.duration` as an initial retention period.
-
-If you need to customize retention settings for monitoring data collected with metricbeat, please update the `.monitoring-8-ilm-policy` ILM policy directly.
-
-The `xpack.monitoring.history.duration` setting will only apply to monitoring indices written using (legacy) internal
-collection, not indices created by metricbeat or agent.
-
-*Impact* +
-After upgrading, insure that the `.monitoring-8-ilm-policy` ILM policy aligns with your desired retention settings.
-
-If you only use
-metricbeat or agent to collect monitoring data, you can also remove any custom `xpack.monitoring.history.duration`
-settings.
-
-====
diff --git a/docs/reference/migration/migrate_8_0/command-line-tool-changes.asciidoc b/docs/reference/migration/migrate_8_0/command-line-tool-changes.asciidoc
deleted file mode 100644
index 7af28a1ae95cc..0000000000000
--- a/docs/reference/migration/migrate_8_0/command-line-tool-changes.asciidoc
+++ /dev/null
@@ -1,20 +0,0 @@
-[discrete]
-[[breaking_80_command_line_tool_changes]]
-==== Command line tool changes
-
-TIP: {ess-skip-section}
-
-[[migrate-tool-removed]]
-.The `elasticsearch-migrate` tool has been removed.
-[%collapsible]
-====
-*Details* +
-The `elasticsearch-migrate` tool provided a way to convert file
-realm users and roles into the native realm. It has been deprecated
-since {es} 7.2.0. Users and roles should now be created in the native
-realm directly.
-
-*Impact* +
-Discontinue use of the `elasticsearch-migrate` tool. Attempts to use the
-`elasticsearch-migrate` tool will result in an error.
-====
diff --git a/docs/reference/migration/migrate_8_0/index-setting-changes.asciidoc b/docs/reference/migration/migrate_8_0/index-setting-changes.asciidoc
deleted file mode 100644
index 60e5588a187a7..0000000000000
--- a/docs/reference/migration/migrate_8_0/index-setting-changes.asciidoc
+++ /dev/null
@@ -1,122 +0,0 @@
-[discrete]
-[[breaking_80_index_setting_changes]]
-==== Index setting changes
-
-[[deprecation-system-indices]]
-.Direct access to system indices is deprecated.
-[%collapsible]
-====
-*Details* +
-Directly accessing system indices is deprecated, and may be prevented in a
-future version. If you must access a system index, create a security role with
-an index permission that targets the specific index and set the
-`allow_restricted_indices` permission to `true`. Refer to
-{ref}/defining-roles.html#roles-indices-priv[indices privileges] for
-information on adding this permission to an index privilege.
-
-*Impact* +
-Accessing system indices directly results in warnings in the header of API
-responses. If available, use {kib} or the associated feature's {es} APIs to
-manage the data that you want to access.
-====
-
-[[deprecate-max-merge-at-once-explicit-setting]]
-.`index.merge.policy.max_merge_at_once_explicit` is deprecated and has no effect.
-[%collapsible]
-====
-*Details* +
-The `index.merge.policy.max_merge_at_once_explicit` index setting is deprecated
-and has no effect.
-
-Previously, you could specify `index.merge.policy.max_merge_at_once_explicit` to
-set the maximum number of segments to merge at the same time during a force
-merge or when expunging deleted documents. In 8.0, this number is unlimited,
-regardless of the setting.
-
-*Impact* +
-Specifying `index.merge.policy.max_merge_at_once_explicit` will have no effect
-but will generate deprecation warnings.
-
-To avoid these deprecation warnings, discontinue use of the setting. Don't
-specify the setting when creating new indices, and remove the setting from
-index and component templates.
-
-To remove the setting from an existing data stream or index, specify the
-setting's value as `null` using the update index settings API.
-
-[source,console]
-----
-PUT my-index-000001/_settings
-{
- "index.merge.policy.max_merge_at_once_explicit": null
-}
-----
-// TEST[setup:my_index]
-
-====
-
-[[index-max-adjacency-matrix-filters-removed]]
-.The `index.max_adjacency_matrix_filters` index setting has been removed.
-[%collapsible]
-====
-*Details* +
-The `index.max_adjacency_matrix_filters` index setting has been removed.
-Previously, you could use this setting to configure the maximum number of
-filters for the
-{ref}/search-aggregations-bucket-adjacency-matrix-aggregation.html[adjacency
-matrix aggregation]. The `indices.query.bool.max_clause_count` index setting now
-determines the maximum number of filters for the aggregation.
-
-*Impact* +
-Discontinue use of the `index.max_adjacency_matrix_filters` index setting.
-
-Requests that include the index setting will return an error. If you upgrade a
-cluster with a 7.x index that already contains the setting, {es} will
-{ref}/archived-settings.html#archived-index-settings[archive the setting].
-
-Remove the index setting from index and component templates. Attempts to use a
-template that contains the setting will fail and return an error. This includes
-automated operations, such the {ilm-init} rollover action.
-====
-
-.The `index.force_memory_term_dictionary` setting has been removed.
-[%collapsible]
-====
-*Details* +
-The `index.force_memory_term_dictionary` setting was introduced in 7.0 as a
-temporary measure to allow users to opt-out of the optimization that leaves the
-term dictionary on disk when appropriate. This optimization is now mandatory
-and the setting is removed.
-
-*Impact* +
-Discontinue use of the `index.force_memory_term_dictionary` index setting.
-Requests that include this setting will return an error.
-====
-
-.The `index.soft_deletes.enabled` setting has been removed.
-[%collapsible]
-====
-*Details* +
-Creating indices with soft deletes disabled was deprecated in 7.6 and
-is no longer supported in 8.0. The `index.soft_deletes.enabled` setting
-can no longer be set to `false`.
-
-*Impact* +
-Discontinue use of the `index.soft_deletes.enabled` index setting. Requests that
-set `index.soft_deletes.enabled` to `false` will return an error.
-====
-
-.The `index.translog.retention.age` and `index.translog.retention.size` settings have been removed.
-[%collapsible]
-====
-*Details* +
-Translog retention settings `index.translog.retention.age` and
-`index.translog.retention.size` were effectively ignored in 7.4, deprecated in
-7.7, and removed in 8.0 in favor of
-{ref}/index-modules-history-retention.html[soft deletes].
-
-*Impact* +
-Discontinue use of the `index.translog.retention.age` and
-`index.translog.retention.size` index settings. Requests that
-include these settings will return an error.
-====
diff --git a/docs/reference/migration/migrate_8_0/java-api-changes.asciidoc b/docs/reference/migration/migrate_8_0/java-api-changes.asciidoc
deleted file mode 100644
index 22e1caf1bf5e4..0000000000000
--- a/docs/reference/migration/migrate_8_0/java-api-changes.asciidoc
+++ /dev/null
@@ -1,50 +0,0 @@
-[discrete]
-[[breaking_80_java_api_changes]]
-==== Java API changes
-
-[[ilm-hlrc-rename]]
-.The `indexlifecycle` package has been renamed `ilm` in the Java High Level REST Client.
-[%collapsible]
-====
-*Details* +
-In the high level REST client, the `indexlifecycle` package has been
-renamed to `ilm` to match the package rename inside the {es} code.
-
-*Impact* +
-Update your workflow and applications to use the `ilm` package in place of
-`indexlifecycle`.
-====
-
-.Changes to `Fuzziness`.
-[%collapsible]
-====
-*Details* +
-To create `Fuzziness` instances, use the `fromString` and `fromEdits` method
-instead of the `build` method that used to accept both Strings and numeric
-values. Several fuzziness setters on query builders (e.g.
-MatchQueryBuilder#fuzziness) now accept only a `Fuzziness` instance instead of
-an Object.
-
-Fuzziness used to be lenient when it comes to parsing arbitrary numeric values
-while silently truncating them to one of the three allowed edit distances 0, 1
-or 2. This leniency is now removed and the class will throw errors when trying
-to construct an instance with another value (e.g. floats like 1.3 used to get
-accepted but truncated to 1).
-
-*Impact* +
-Use the available constants (e.g. `Fuzziness.ONE`, `Fuzziness.AUTO`) or build
-your own instance using the above mentioned factory methods. Use only allowed
-`Fuzziness` values.
-====
-
-.Changes to `Repository`.
-[%collapsible]
-====
-*Details* +
-Repository has no dependency on IndexShard anymore. The contract of restoreShard
-and snapshotShard has been reduced to Store and MappingService in order to improve
-testability.
-
-*Impact* +
-No action needed.
-====
diff --git a/docs/reference/migration/migrate_8_0/jvm-option-changes.asciidoc b/docs/reference/migration/migrate_8_0/jvm-option-changes.asciidoc
deleted file mode 100644
index bdcffe4667ca4..0000000000000
--- a/docs/reference/migration/migrate_8_0/jvm-option-changes.asciidoc
+++ /dev/null
@@ -1,54 +0,0 @@
-[discrete]
-[[breaking_80_jvm_option_changes]]
-==== JVM option changes
-
-TIP: {ess-skip-section}
-
-[[breaking_80_allocation_change_flood_stage_block_always_removed]]
-.`es.disk.auto_release_flood_stage_block` has been removed.
-[%collapsible]
-====
-*Details* +
-If a node exceeds the flood-stage disk watermark then we add a block to all of
-its indices to prevent further writes as a last-ditch attempt to prevent the
-node completely exhausting its disk space. By default, from 7.4 onwards the
-block is automatically removed when a node drops below the high watermark
-again, but this behaviour could be disabled by setting the system property
-`es.disk.auto_release_flood_stage_block` to `false`. This behaviour is no
-longer optional, and this system property must now not be set.
-
-*Impact* +
-Discontinue use of the `es.disk.auto_release_flood_stage_block` system property.
-Setting this system property will result in an error on startup.
-====
-
-.`es.rest.url_plus_as_space` has been removed.
-[%collapsible]
-====
-*Details* +
-Starting in version 7.4, a `+` in a URL will be encoded as `%2B` by all REST API functionality. Prior versions handled a `+` as a single space.
-In these previous versions, if your application required handling `+` as a single space, you could return to the old behaviour by setting the system property
-`es.rest.url_plus_as_space` to `true`. Note that this behaviour is deprecated and setting this system property to `true` will cease
-to be supported in version 8.
-
-*Impact* +
-Update your application or workflow to assume `+` in a URL is encoded as `%2B`.
-====
-
-.`es.unsafely_permit_handshake_from_incompatible_builds` has been removed.
-[%collapsible]
-====
-*Details* +
-{es} has a check that verifies that communicating pairs of nodes of the same
-version are running exactly the same build and therefore using the same wire
-format as each other. In previous versions this check can be bypassed by
-setting the system property
-`es.unsafely_permit_handshake_from_incompatible_builds` to `true`. The use of
-this system property is now forbidden.
-
-*Impact* +
-Discontinue use of the `es.unsafely_permit_handshake_from_incompatible_builds`
-system property, and ensure that all nodes of the same version are running
-exactly the same build. Setting this system property will result in an error
-on startup.
-====
diff --git a/docs/reference/migration/migrate_8_0/logging-changes.asciidoc b/docs/reference/migration/migrate_8_0/logging-changes.asciidoc
deleted file mode 100644
index 63c025746a64c..0000000000000
--- a/docs/reference/migration/migrate_8_0/logging-changes.asciidoc
+++ /dev/null
@@ -1,53 +0,0 @@
-[discrete]
-[[breaking_80_logging_changes]]
-==== Logging changes
-
-.{es} JSON logs now comply with ECS.
-[%collapsible]
-====
-*Details* +
-{es}'s {ref}/logging.html[JSON logs] now comply with the
-{ecs-ref}/index.html[Elastic Common Schema (ECS)]. Previously, {es}'s JSON logs
-used a custom schema.
-
-*Impact* +
-If your application parses {es}'s JSON logs, update it to support the new ECS
-format.
-====
-
-.{es} no longer emits deprecation logs or slow logs in plaintext.
-[%collapsible]
-====
-*Details* +
-{es} no longer emits a plaintext version of the following logs:
-
-* Deprecation logs
-* Indexing slow logs
-* Search slow logs
-
-These logs are now only available in JSON.
-
-Server logs are still available in both a JSON and plaintext format.
-
-*Impact* +
-If your application parses {es}'s plaintext logs, update it to use the new ECS
-JSON logs.
-====
-
-[[audit-logs-are-rolled-over-and-archived-by-size]]
-.Audit logs are rolled-over and archived by size.
-[%collapsible]
-====
-*Details* +
-In addition to the existing daily rollover, the security audit logs are
-now rolled-over by disk size limit as well. Moreover, the rolled-over logs
-are also gzip compressed.
-
-*Impact* +
-The names of rolled over audit log files (but not the name of the current log)
-have changed.
-If you've set up automated tools to consume these files, you must configure them
-to use the new names and to possibly account for `gzip` archives instead of
-plain text. The Docker build of {es} is not affected because it logs on `stdout`,
-where rollover is not performed.
-====
diff --git a/docs/reference/migration/migrate_8_0/mapping-changes.asciidoc b/docs/reference/migration/migrate_8_0/mapping-changes.asciidoc
deleted file mode 100644
index 7b3922cf0a5dd..0000000000000
--- a/docs/reference/migration/migrate_8_0/mapping-changes.asciidoc
+++ /dev/null
@@ -1,133 +0,0 @@
-[discrete]
-[[breaking_80_mapping_changes]]
-==== Mapping changes
-
-.Indices created in {es} 6.x and earlier versions are not supported.
-[%collapsible]
-====
-*Details* +
-Elasticsearch 8.0 can read indices created in version 7.0 or above. An
-Elasticsearch 8.0 node will not start in the presence of indices created in a
-version of Elasticsearch before 7.0.
-
-*Impact* +
-Reindex indices created in {es} 6.x or before with {es} 7.x if they need to be carried forward to {es} 8.x.
-====
-
-.Closed indices created in {es} 6.x and earlier versions are not supported.
-[%collapsible]
-====
-*Details* +
-In earlier versions a node would start up even if it had data from indices
-created in a version before the previous major version, as long as those
-indices were closed. {es} now ensures that it is compatible with every index,
-open or closed, at startup time.
-
-*Impact* +
-Reindex closed indices created in {es} 6.x or before with {es} 7.x if they need
-to be carried forward to {es} 8.x.
-====
-
-.The maximum number of completion contexts per field is now 10.
-[%collapsible]
-====
-*Details* +
-The number of completion contexts within a single completion field
-has been limited to 10.
-
-*Impact* +
-Use a maximum of 10 completion contexts in a completion field. Specifying more
-than 10 completion contexts will return an error.
-====
-
-.Multi-fields within multi-fields is no longer supported.
-[%collapsible]
-====
-*Details* +
-Previously, it was possible to define a multi-field within a multi-field.
-Defining chained multi-fields was deprecated in 7.3 and is now no longer
-supported.
-
-*Impact* +
-To migrate mappings, all instances of `fields` that occur within
-a `fields` block should be removed, either by flattening the chained `fields`
-blocks into a single level, or by switching to `copy_to` if appropriate.
-====
-
-[[fieldnames-enabling]]
-.The `_field_names` metadata field's `enabled` parameter has been removed.
-[%collapsible]
-====
-*Details* +
-The setting has been deprecated with 7.5 and is no longer supported on new indices.
-Mappings for older indices will continue to work but emit a deprecation warning.
-
-*Impact* +
-The `enabled` setting for `_field_names` should be removed from templates and mappings.
-Disabling _field_names is not necessary because it no longer carries a large index overhead.
-====
-
-[[mapping-boosts]]
-.The `boost` parameter on field mappings has been removed.
-[%collapsible]
-====
-*Details* +
-Index-time boosts have been deprecated since the 5x line, but it was still possible
-to declare field-specific boosts in the mappings. This is now removed completely.
-Indexes built in 7x that contain mapping boosts will emit warnings, and the boosts
-will have no effect in 8.0. New indexes will not permit boosts to be set in their
-mappings at all.
-
-*Impact* +
-The `boost` setting should be removed from templates and mappings. Use boosts
-directly on queries instead.
-====
-
-.Java-time date formats replace joda-time formats.
-[%collapsible]
-====
-*Details* +
-In 7.0, {es} switched from joda time to java time for date-related parsing,
-formatting, and calculations. Indices created in 7.0 and later versions are
-already required to use mappings with java-time date formats. However,
-earlier indices using joda-time formats must be reindexed to use
-mappings with java-time formats.
-
-*Impact* +
-For a detailed migration guide, see the {ref}/migrate-to-java-time.html[Java
-time migration guide].
-====
-
-[[geo-shape-strategy]]
-.Several `geo_shape` mapping parameters have been removed.
-[%collapsible]
-====
-*Details* +
-The following `geo_shape` mapping parameters were deprecated in 6.6:
-
-* `tree`
-* `tree_levels`
-* `strategy`
-* `distance_error_pct`
-
-These parameters have been removed in 8.0.0.
-
-*Impact* +
-In 8.0, you can no longer create mappings that include these parameters.
-However, 7.x indices that use these mapping parameters will continue to work.
-====
-
-.The `sparse_vector` field data type has been removed.
-[%collapsible]
-====
-*Details* +
-The `sparse_vector` field type was deprecated in 7.6 and is now removed in
-8.0. We have not seen much interest in this experimental field type, and don't
-see a clear use case as it's currently designed. If you have feedback or
-suggestions around sparse vector functionality, please let us know through
-GitHub or the 'discuss' forums.
-
-*Impact* +
-Discontinue use of the `sparse_vector` field data type. Requests containing
-a mapping for this field data type will return an error.
-====
diff --git a/docs/reference/migration/migrate_8_0/migrate_to_java_time.asciidoc b/docs/reference/migration/migrate_8_0/migrate_to_java_time.asciidoc
deleted file mode 100644
index c86eddc04c013..0000000000000
--- a/docs/reference/migration/migrate_8_0/migrate_to_java_time.asciidoc
+++ /dev/null
@@ -1,314 +0,0 @@
-[[migrate-to-java-time]]
-=== Java time migration guide
-
-With 7.0, {es} switched from joda time to java time for date-related parsing,
-formatting, and calculations. This guide is designed to help you determine
-if your cluster is impacted and, if so, prepare for the upgrade.
-
-
-[discrete]
-[[java-time-convert-date-formats]]
-==== Convert date formats
-
-To upgrade to {es} 8, you'll need to convert any joda-time date formats
-to their java-time equivalents.
-
-[discrete]
-[[java-time-migration-impacted-features]]
-=== Impacted features
-The switch to java time only impacts custom <> and
-<> formats.
-
-These formats are commonly used in:
-
-* <>
-* <>
-* <>
-
-If you don't use custom date formats, you can skip the rest of this guide.
-Most custom date formats are compatible. However, several require
-an update.
-
-To see if your date format is impacted, use the <>
-or the {kibana-ref-all}/{prev-major-last}/upgrade-assistant.html[Kibana Upgrade Assistant].
-
-[discrete]
-[[java-time-migration-incompatible-date-formats]]
-=== Incompatible date formats
-Custom date formats containing the following joda-time literals should be
-migrated.
-
-`Y` (Year of era)::
-+
---
-Replace with `y`.
-
-*Example:*
-`YYYY-MM-dd` should become `yyyy-MM-dd`.
-
-In java time, `Y` is used for
-https://docs.oracle.com/javase/8/docs/api/java/time/temporal/WeekFields.html[week-based year].
-Using `Y` in place of `y` could result in off-by-one errors in year calculation.
-
-For pattern `YYYY-ww` and date `2019-01-01T00:00:00.000Z` will give `2019-01`
-For pattern `YYYY-ww` and date `2018-12-31T00:00:00.000Z` will give `2019-01` (counter-intuitive) because there is >4 days of that week in 2019
---
-
-`y` (Year)::
-+
---
-Replace with `u`.
-
-*Example:*
-`yyyy-MM-dd` should become `uuuu-MM-dd`.
-
-In java time, `y` is used for year of era. `u` can contain non-positive
-values while `y` cannot. `y` can also be associated with an era field.
---
-
-
-`C` (Century of era)::
-+
---
-Century of era is not supported in java time.
-There is no replacement. Instead, we recommend you preprocess your input.
---
-
-`x` (Week year)::
-+
---
-Replace with `Y`.
-
-In java time, `x` means https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html[zone-offset].
-
-[WARNING]
-====
-Failure to properly convert `x` (Week year) to `Y` could result in data loss.
-====
---
-
-`Z` (Zone offset/id)::
-+
---
-Replace with multiple `X`'s.
-
-`Z` has a similar meaning in java time. However, java time expects different
-numbers of literals to parse different forms.
-
-Consider migrating to `X`, which gives you more control over how time is parsed.
-For example, the joda-time format `YYYY-MM-dd'T'hh:mm:ssZZ` accepts the following dates:
-
-```
-2010-01-01T01:02:03Z
-2010-01-01T01:02:03+01
-2010-01-01T01:02:03+01:02
-2010-01-01T01:02:03+01:02:03
-```
-
-In java time, you cannot parse all these dates using a single format
-Instead, you must specify 3 separate formats:
-
-```
-2010-01-01T01:02:03Z
-2010-01-01T01:02:03+01
-both parsed with yyyy-MM-dd'T'hh:mm:ssX
-
-2010-01-01T01:02:03+01:02
-yyyy-MM-dd'T'hh:mm:ssXXX
-
-2010-01-01T01:02:03+01:02:03
-yyyy-MM-dd'T'hh:mm:ssXXXXX
-```
-
-
-The formats must then be delimited using `||`:
-[source,txt]
---------------------------------------------------
-yyyy-MM-dd'T'hh:mm:ssX||yyyy-MM-dd'T'hh:mm:ssXXX||yyyy-MM-dd'T'hh:mm:ssXXXXX
---------------------------------------------------
-
-The same applies if you expect your pattern to occur without a colon (`:`):
-For example, the `YYYY-MM-dd'T'hh:mm:ssZ` format accepts the following date forms:
-```
-2010-01-01T01:02:03Z
-2010-01-01T01:02:03+01
-2010-01-01T01:02:03+0102
-2010-01-01T01:02:03+010203
-```
-To accept all these forms in java time, you must use the `||` delimiter:
-[source,txt]
---------------------------------------------------
-yyyy-MM-dd'T'hh:mm:ssX||yyyy-MM-dd'T'hh:mm:ssXX||yyyy-MM-dd'T'hh:mm:ssXXXX
---------------------------------------------------
---
-
-`d` (Day)::
-+
---
-In java time, `d` is still interpreted as "day" but is less flexible.
-
-For example, the joda-time date format `YYYY-MM-dd` accepts `2010-01-01` or
-`2010-01-1`.
-
-In java time, you must use the `||` delimiter to provide specify each format:
-
-[source,txt]
---------------------------------------------------
-yyyy-MM-dd||yyyy-MM-d
---------------------------------------------------
-
-In java time, `d` also does not accept more than 2 digits. To accept days with more
-than two digits, you must include a text literal in your java-time date format.
-For example, to parse `2010-01-00001`, you must use the following java-time date format:
-
-[source,txt]
---------------------------------------------------
-yyyy-MM-'000'dd
---------------------------------------------------
---
-
-`e` (Name of day)::
-+
---
-In java time, `e` is still interpreted as "name of day" but does not parse
-short- or full-text forms.
-
-For example, the joda-time date format `EEE YYYY-MM` accepts both
-`Wed 2020-01` and `Wednesday 2020-01`.
-
-To accept both of these dates in java time, you must specify each format using
-the `||` delimiter:
-
-[source,txt]
---------------------------------------------------
-cccc yyyy-MM||ccc yyyy-MM
---------------------------------------------------
-
-The joda-time literal `E` is interpreted as "day of week."
-The java-time literal `c` is interpreted as "localized day of week."
-`E` does not accept full-text day formats, such as `Wednesday`.
---
-
-`EEEE` and similar text forms::
-+
---
-Support for full-text forms depends on the locale data provided with your Java
-Development Kit (JDK) and other implementation details. We recommend you
-test formats containing these patterns carefully before upgrading.
---
-
-`z` (Time zone text)::
-+
---
-In java time, `z` outputs 'Z' for Zulu when given a UTC timezone.
---
-
-[discrete]
-[[java-time-migration-test]]
-=== Test with your data
-
-We strongly recommend you test any date format changes using real data before
-deploying in production.
-
-[discrete]
-[[java-time-migrate-update-mappings]]
-=== Update index mappings
-To update joda-time date formats in index mappings, you must create a new index
-with an updated mapping and reindex your data to it.
-
-The following `my-index-000001` index contains a mapping for the `datetime` field, a
-`date` field with a custom joda-time date format.
-////
-[source,console]
---------------------------------------------------
-PUT my-index-000001
-{
- "mappings": {
- "properties": {
- "datetime": {
- "type": "date",
- "format": "yyyy/MM/dd HH:mm:ss||yyyy/MM/dd||epoch_millis"
- }
- }
- }
-}
---------------------------------------------------
-////
-
-[source,console]
---------------------------------------------------
-GET my-index-000001/_mapping
---------------------------------------------------
-// TEST[continued]
-
-[source,console-result]
---------------------------------------------------
-{
- "my-index-000001" : {
- "mappings" : {
- "properties" : {
- "datetime": {
- "type": "date",
- "format": "yyyy/MM/dd HH:mm:ss||yyyy/MM/dd||epoch_millis"
- }
- }
- }
- }
-}
---------------------------------------------------
-
-
-To change the date format for the `datetime` field, create a separate index
-containing an updated mapping and date format.
-
-For example, the following `my-index-000002` index changes the `datetime` field's
-date format to `uuuu/MM/dd HH:mm:ss||uuuu/MM/dd||epoch_millis`.
-
-[source,console]
---------------------------------------------------
-PUT my-index-000002
-{
- "mappings": {
- "properties": {
- "datetime": {
- "type": "date",
- "format": "uuuu/MM/dd HH:mm:ss||uuuu/MM/dd||epoch_millis"
- }
- }
- }
-}
---------------------------------------------------
-// TEST[continued]
-
-Next, reindex data from the old index to the new index.
-
-The following <> API request reindexes data from
-`my-index-000001` to `my-index-000002`.
-
-[source,console]
---------------------------------------------------
-POST _reindex
-{
- "source": {
- "index": "my-index-000001"
- },
- "dest": {
- "index": "my-index-000002"
- }
-}
---------------------------------------------------
-// TEST[continued]
-
-If you use index aliases, update them to point to the new index.
-
-[source,console]
---------------------------------------------------
-POST /_aliases
-{
- "actions" : [
- { "remove" : { "index" : "my-index-000001", "alias" : "my-index" } },
- { "add" : { "index" : "my-index-000002", "alias" : "my-index" } }
- ]
-}
---------------------------------------------------
-// TEST[continued]
diff --git a/docs/reference/migration/migrate_8_0/packaging-changes.asciidoc b/docs/reference/migration/migrate_8_0/packaging-changes.asciidoc
deleted file mode 100644
index 7e0c2c72ee6d7..0000000000000
--- a/docs/reference/migration/migrate_8_0/packaging-changes.asciidoc
+++ /dev/null
@@ -1,60 +0,0 @@
-[discrete]
-[[breaking_80_packaging_changes]]
-==== Packaging changes
-
-TIP: {ess-skip-section}
-
-.The layout of the data folder has changed.
-[%collapsible]
-====
-*Details* +
-Each node's data is now stored directly in the data directory set by the
-`path.data` setting, rather than in `${path.data}/nodes/0`, because the removal
-of the `node.max_local_storage_nodes` setting means that nodes may no longer
-share a data path.
-
-*Impact* +
-At startup, {es} will automatically migrate the data path to the new layout.
-This automatic migration will not proceed if the data path contains data for
-more than one node. You should move to a configuration in which each node has
-its own data path before upgrading.
-
-If you try to upgrade a configuration in which there is data for more than one
-node in a data path then the automatic migration will fail and {es}
-will refuse to start. To resolve this you will need to perform the migration
-manually. The data for the extra nodes are stored in folders named
-`${path.data}/nodes/1`, `${path.data}/nodes/2` and so on, and you should move
-each of these folders to an appropriate location and then configure the
-corresponding node to use this location for its data path. If your nodes each
-have more than one data path in their `path.data` settings then you should move
-all the corresponding subfolders in parallel. Each node uses the same subfolder
-(e.g. `nodes/2`) across all its data paths.
-====
-
-.The default Maxmind geoip databases have been removed.
-[%collapsible]
-====
-*Details* +
-The default Maxmind geoip databases that shipped by default with Elasticsearch
-have been removed. These databases are out dated and stale and using these
-databases will likely result in incorrect geoip lookups.
-
-By default since 7.13, these pre-packaged geoip databases
-were used in case no database were specified in the config directory or before
-the geoip downloader downloaded the geoip databases. When the geoip database
-downloader completed downloading the new databases then these pre-packaged
-databases were no longer used.
-
-*Impact* +
-If the geoip downloader is disabled and no geoip databases are provided
-in the config directory of each ingest node then the geoip processor will
-no longer perform geoip lookups and tag these documents with the fact that
-the requested database is no longer available.
-
-After a cluster has been started and before the geoip downloader has completed
-downloading the most up to data databases, the geoip processor will not perform
-any geoip lookups and tag documents that the requested database is not available.
-After the geoip downloader has completed downloading the most up to data databases
-then the geoip processor will function as normal. The window of time that the
-geoip processor can't do geoip lookups after cluster startup should be very small.
-====
diff --git a/docs/reference/migration/migrate_8_0/painless-changes.asciidoc b/docs/reference/migration/migrate_8_0/painless-changes.asciidoc
deleted file mode 100644
index 601866cb8995d..0000000000000
--- a/docs/reference/migration/migrate_8_0/painless-changes.asciidoc
+++ /dev/null
@@ -1,42 +0,0 @@
-[discrete]
-[[breaking_80_painless_changes]]
-==== Painless changes
-
-.The `JodaCompatibleZonedDateTime` class has been removed.
-[%collapsible]
-====
-*Details* +
-As a transition from Joda datetime to Java datetime, scripting used
-an intermediate class called `JodaCompatibleZonedDateTime`. This class
-has been removed and is replaced by `ZonedDateTime`. Any use of casting
-to a `JodaCompatibleZonedDateTime` or use of method calls only available
-in `JodaCompatibleZonedDateTime` in a script will result in a compilation
-error, and may not allow the upgraded node to start.
-
-*Impact* +
-Before upgrading, replace `getDayOfWeek` with `getDayOfWeekEnum().value` in any
-scripts. Any use of `getDayOfWeek` expecting a return value of `int` will result
-in a compilation error or runtime error and may not allow the upgraded node to
-start.
-
-The following `JodaCompatibleZonedDateTime` methods must be replaced using
-`ZonedDateTime` methods prior to upgrade:
-
-* `getMillis()` -> `toInstant().toEpochMilli()`
-* `getCenturyOfEra()` -> `get(ChronoField.YEAR_OF_ERA) / 100`
-* `getEra()` -> `get(ChronoField.ERA)`
-* `getHourOfDay()` -> `getHour()`
-* `getMillisOfDay()` -> `get(ChronoField.MILLI_OF_DAY)`
-* `getMillisOfSecond()` -> `get(ChronoField.MILLI_OF_SECOND)`
-* `getMinuteOfDay()` -> `get(ChronoField.MINUTE_OF_DAY)`
-* `getMinuteOfHour()` -> `getMinute()`
-* `getMonthOfYear()` -> `getMonthValue()`
-* `getSecondOfDay()` -> `get(ChronoField.SECOND_OF_DAY)`
-* `getSecondOfMinute()` -> `getSecond()`
-* `getWeekOfWeekyear()` -> `get(IsoFields.WEEK_OF_WEEK_BASED_YEAR)`
-* `getWeekyear()` -> `get(IsoFields.WEEK_BASED_YEAR)`
-* `getYearOfCentury()` -> `get(ChronoField.YEAR_OF_ERA) % 100`
-* `getYearOfEra()` -> `get(ChronoField.YEAR_OF_ERA)`
-* `toString(String)` -> a DateTimeFormatter
-* `toString(String, Locale)` -> a DateTimeFormatter
-====
diff --git a/docs/reference/migration/migrate_8_0/plugin-changes.asciidoc b/docs/reference/migration/migrate_8_0/plugin-changes.asciidoc
deleted file mode 100644
index 42baf8f7f2a69..0000000000000
--- a/docs/reference/migration/migrate_8_0/plugin-changes.asciidoc
+++ /dev/null
@@ -1,64 +0,0 @@
-[discrete]
-[[breaking_80_plugin_changes]]
-==== Plugin changes
-
-TIP: {ess-skip-section}
-
-.The S3, GCS and Azure repository plugins are now included in Elasticsearch
-[%collapsible]
-====
-*Details* +
-In previous versions of {es}, in order to register a snapshot repository
-backed by Amazon S3, Google Cloud Storage (GCS) or Microsoft Azure Blob
-Storage, you first had to install the corresponding Elasticsearch plugin,
-for example `repository-s3`. These plugins are now included in {es} by
-default.
-
-*Impact* +
-You no longer need to install the following plugins, and not should attempt
-to do so.
-
-* `repository-azure`
-* `repository-gcs`
-* `repository-s3`
-
-{es} and the `elasticsearch-plugin` CLI tool have been changed to tolerate
-attempted installation and removal of these plugins in order to avoid
-breaking any existing automation. In the future, attempting to install
-these plugins will be an error.
-
-Specifically, the `elasticsearch-plugin` CLI tool will not fail if you
-attempt to install any of the above plugins, and will instead print a
-warning and skip the plugins. If any of these plugins are already
-installed, for example because you installed them when running an older
-version of {es}, then you can still remove them with
-`elasticsearch-plugin`. Attempting to remove them if they are not installed
-will succeed but print a warnings.
-
-If you run {es} using Docker and you are managing plugins using a
-{plugins}/manage-plugins-using-configuration-file.html[configuration file], then when
-{es} first starts after you upgrade it, it will remove the above plugins if
-they already installed. If any of these plugins are specified in your
-configuration file, {es} will ignore them and emit a warning log message.
-====
-
-.Third party plugins can no longer intercept REST requests (`RestHandlerWrapper`)
-[%collapsible]
-====
-*Details* +
-In previous versions of {es}, third-party plugins could implement the
-`getRestHandlerWrapper` method to intercept all REST requests to the node. A
-common use of this feature was to implement custom security plugins to replace
-the built-in {security-features}. This extension point is no longer available
-to third-party plugins.
-
-
-*Impact* +
-Some third-party plugins that were designed to work with earlier versions of
-{es} might not be compatible with {es} version 8.0 or later.
-
-If you depend on any plugins that are not produced and supported by Elastic,
-check with the plugin author and ensure that the plugin is available for your
-target version of {es} before upgrading.
-
-====
diff --git a/docs/reference/migration/migrate_8_0/rest-api-changes.asciidoc b/docs/reference/migration/migrate_8_0/rest-api-changes.asciidoc
deleted file mode 100644
index 99c09b9b05385..0000000000000
--- a/docs/reference/migration/migrate_8_0/rest-api-changes.asciidoc
+++ /dev/null
@@ -1,1138 +0,0 @@
-[discrete]
-[[breaking_80_rest_api_changes]]
-==== REST API changes
-
-.REST API endpoints containing `_xpack` have been removed.
-[%collapsible]
-====
-*Details* +
-In 7.0, we deprecated REST endpoints that contain `_xpack` in their path. These
-endpoints are now removed in 8.0. Each endpoint that was deprecated and removed
-is replaced with a new endpoint that does not contain `_xpack`. As an example,
-`/{index}/_xpack/graph/_explore` is replaced by `/{index}/_graph/explore`.
-
-*Impact* +
-Use the replacement REST API endpoints. Requests submitted to the `_xpack`
-API endpoints will return an error.
-
-*Compatibility* +
-When {ref}/rest-api-compatibility.html[rest-api-compatibility] is
-{ref}/rest-api-compatibility.html[requested], any requests that include
-the`_xpack` prefix are rerouted to the corresponding URL without the `_xpack`
-prefix.
-====
-
-[[remove-mapping-type-api-endpoints]]
-.REST API endpoints containing mapping types have been removed.
-[%collapsible]
-====
-*Details* +
-Mapping types have been removed. API endpoints that contain a mapping type have
-also been removed. Use a typeless endpoint instead.
-
-[options="header",cols="<1,<3,<1"]
-|====
-| API | Typed API endpoint | Typeless API endpoint
-
-| {ref}/docs-bulk.html[Bulk]
-| `//_bulk`
-| `/_bulk`
-
-| {ref}/search-count.html[Count]
-| `//_count`
-| `/_count`
-
-| {ref}/docs-delete.html[Delete]
-| `//<_id>`
-| `/_doc/<_id>`
-
-| {ref}/docs-delete-by-query.html[Delete by query]
-| `//_delete_by_query`
-| `/_delete_by_query`
-
-| {ref}/search-explain.html[Explain]
-| `//<_id>/_explain`
-| `/_explain/<_id>`
-
-| {ref}/docs-get.html[Get]
-| `//<_id>`
-| `/_doc/<_id>`
-
-|
-| `//<_id>/_source`
-| `/_source/<_id>`
-
-| {ref}/indices-get-field-mapping.html[Get field mapping]
-| `_mapping//field/`
-| `_mapping/field/`
-
-|
-| `/_mapping//field/`
-| `/_mapping/field/`
-
-| {ref}/indices-get-mapping.html[Get mapping]
-| `_mapping/`
-| `_mapping` or `/_mapping`
-
-|
-| `//_mapping`
-| `/_mapping`
-
-|
-| `/_mapping/`
-| `/_mapping`
-
-| {ref}/graph-explore-api.html[Graph explore]
-| `//_graph/explore`
-| `/_graph/explore`
-
-| {ref}/docs-index_.html[Index]
-| `//<_id>/_create`
-| `/_create/<_id>`
-
-|
-| `/`
-| `/_doc`
-
-|
-| `//<_id>`
-| `/_doc/<_id>`
-
-| {ref}/docs-multi-get.html[Multi get]
-| `//_mget`
-| `/_mget`
-
-| {ref}/search-multi-search.html[Multi search]
-| `//_msearch`
-| `/_msearch`
-
-| {ref}/multi-search-template.html[Multi search template]
-| `//_msearch/template`
-| `/_msearch/template`
-
-| {ref}/docs-multi-termvectors.html[Multi term vectors]
-| `//_mtermvectors`
-| `/_mtermvectors`
-
-| {ref}/rollup-search.html[Rollup search]
-| `//_rollup_search`
-| `/_rollup_search`
-
-| {ref}/search-search.html[Search]
-| `//_search`
-| `/_search`
-
-| {ref}/search-template-api.html[Search template]
-| `//_search/template`
-| `/_search/template`
-
-| {ref}/docs-termvectors.html[Term vectors]
-| `//<_id>/_termvectors`
-| `/_termvectors<_id>`
-
-|
-| `//_termvectors`
-| `/_termvectors`
-
-| {ref}/docs-update.html[Update]
-| `//<_id>/_update`
-| `/_update/<_id>`
-
-| {ref}/docs-update-by-query.html[Update by query]
-| `//_update_by_query`
-| `/_update_by_query`
-
-| {ref}/indices-put-mapping.html[Update mapping]
-| `//_mapping`
-| `/_mapping`
-
-|
-| `/_mapping/`
-| `/_mapping`
-
-|
-| `_mapping/`
-| `/_mapping`
-
-| {ref}/search-validate.html[Validate]
-| `//_validate/query`
-| `/_validate/query`
-
-|====
-
-*Impact* +
-Update your application to use typeless REST API endpoints. Requests to
-endpoints that contain a mapping type will return an error.
-
-*Compatibility* +
-When {ref}/rest-api-compatibility.html[rest-api-compatibility] is
-{ref}/rest-api-compatibility.html[requested], if a request includes a custom
-mapping type it is ignored. The request is rerouted to the corresponding
-typeless URL. Custom mapping types in request bodies and type related HTTP
-parameters are ignored, and responses, where warranted, include `_type` :
-`_doc`.
-
-====
-
-.{ccs-cap} ({ccs-init}) is now only backward-compatible with the previous minor version.
-[%collapsible]
-====
-*Details* +
-In 8.0+, Elastic supports searches from a local cluster to a remote cluster
-running:
-
-* The previous minor version.
-* The same version.
-* A newer minor version in the same major version.
-
-Elastic also supports searches from a local cluster running the last minor
-version of a major version to a remote cluster running any minor version in the
-following major version. For example, a local 7.17 cluster can search any
-remote 8.x cluster.
-
-include::{es-ref-dir}/search/search-your-data/ccs-version-compat-matrix.asciidoc[]
-
-IMPORTANT: For the {ref}/eql-search-api.html[EQL search API], the local and
-remote clusters must use the same {es} version if they have versions prior to 7.17.7 (included) or prior to 8.5.1 (included).
-
-For example, a local 8.0 cluster can search a remote 7.17 or any remote 8.x
-cluster. However, a search from a local 8.0 cluster to a remote 7.16 or 6.8
-cluster is not supported.
-
-Previously, we also supported searches on remote clusters running:
-
-* Any minor version of the local cluster's major version.
-* The last minor release of the previous major version.
-
-However, such searches can result in undefined behavior.
-
-*Impact* +
-If you only run cross-cluster searches on remote clusters using the same or a
-newer version, no changes are needed.
-
-If you previously searched remote clusters running an earlier version of {es},
-see {ref}/modules-cross-cluster-search.html#ensure-ccs-support[Ensure {ccs}
-support] for recommended solutions.
-
-A {ccs} using an unsupported configuration may still work. However, such
-searches aren't tested by Elastic, and their behavior isn't guaranteed.
-====
-
-[[remove-term-order-key]]
-.The `terms` aggregation no longer supports the `_term` order key.
-[%collapsible]
-====
-*Details* +
-The `terms` aggregation no longer supports the `_term` key in `order` values. To
-sort buckets by their term, use `_key` instead.
-
-*Impact* +
-Discontinue use of the `_term` order key. Requests that include a `_term` order
-key will return an error.
-
-*Compatibility* +
-When {ref}/rest-api-compatibility.html[rest-api-compatibility] is
-{ref}/rest-api-compatibility.html[requested], the `_term` order is ignored and
-`key` is used instead.
-====
-
-[[remove-time-order-key]]
-.The `date_histogram` aggregation no longer supports the `_time` order key.
-[%collapsible]
-====
-*Details* +
-The `date_histogram` aggregation no longer supports the `_time` key in `order`
-values. To sort buckets by their key, use `_key` instead.
-
-*Impact* +
-Discontinue use of the `_time` order key. Requests that include a `_time` order
-key will return an error.
-
-*Compatibility* +
-When {ref}/rest-api-compatibility.html[rest-api-compatibility] is
-{ref}/rest-api-compatibility.html[requested], the `_time` order is ignored and
-`_key` is used instead.
-====
-
-[[remove-moving-avg-agg]]
-.The `moving_avg` aggregation has been removed.
-[%collapsible]
-====
-*Details* +
-The `moving_avg` aggregation was deprecated in 6.4 and has been removed. To
-calculate moving averages, use the
-{ref}/search-aggregations-pipeline-movfn-aggregation.html[`moving_fn`
-aggregation] instead.
-
-*Impact* +
-Discontinue use of the `moving_avg` aggregation. Requests that include the
-`moving_avg` aggregation will return an error.
-
-
-====
-
-[[percentile-duplication]]
-.The `percentiles` aggregation's `percents` parameter no longer supports duplicate values.
-[%collapsible]
-====
-*Details* +
-If you specify the `percents` parameter with the
-{ref}/search-aggregations-metrics-percentile-aggregation.html[`percentiles` aggregation],
-its values must be unique. Otherwise, an exception occurs.
-
-*Impact* +
-Use unique values in the `percents` parameter of the `percentiles` aggregation.
-Requests containing duplicate values in the `percents` parameter will return
-an error.
-
-====
-
-[[date-histogram-interval]]
-.The `date_histogram` aggregation's `interval` parameter is no longer valid.
-[%collapsible]
-====
-*Details* +
-It is now an error to specify the `interval` parameter to the
-{ref}/search-aggregations-bucket-datehistogram-aggregation.html[`date_histogram`
-aggregation] or the
-{ref}/search-aggregations-bucket-composite-aggregation.html#_date_histogram[`composite
-date_histogram` source. Instead, please use either `calendar_interval` or
-`fixed_interval` as appropriate.
-
-*Impact* +
-Uses of the `interval` parameter in either the `date_histogram` aggregation or
-the `date_histogram` composite source will now generate an error. Instead
-please use the more specific `fixed_interval` or `calendar_interval`
-parameters.
-
-*Compatibility* +
-When {ref}/rest-api-compatibility.html[rest-api-compatibility] is
-{ref}/rest-api-compatibility.html[requested], the `interval` parameter is
-adapted to either a fixed or calendar interval.
-====
-
-[[ngram-edgengram-filter-names-removed]]
-.The `nGram` and `edgeNGram` token filter names have been removed.
-[%collapsible]
-====
-*Details* +
-The `nGram` and `edgeNGram` token filter names that have been deprecated since
-version 6.4 have been removed. Both token filters can only be used by their
-alternative names `ngram` and `edge_ngram` since version 7.0.
-
-*Impact* +
-Use the equivalent `ngram` and `edge_ngram` token filters. Requests containing
-the `nGram` and `edgeNGram` token filter names will return an error.
-====
-
-[[nGram-edgeNGram-tokenizer-dreprecation]]
-.The `nGram` and `edgeNGram` tokenizer names have been removed.
-[%collapsible]
-====
-*Details* +
-The `nGram` and `edgeNGram` tokenizer names haven been deprecated with 7.6 and are no longer
-supported on new indices. Mappings for indices created after 7.6 will continue to work but
-emit a deprecation warning. The tokenizer name should be changed to the fully equivalent
-`ngram` or `edge_ngram` names for new indices and in index templates.
-
-*Impact* +
-Use the `ngram` and `edge_ngram` tokenizers. Requests to create new indices
-using the `nGram` and `edgeNGram` tokenizer names will return an error.
-====
-
-.The `in_flight_requests` stat has been renamed `inflight_requests` in logs and diagnostic APIs.
-[%collapsible]
-====
-*Details* +
-The name of the in flight requests circuit breaker in log output and diagnostic APIs (such as the node stats API) changes from `in_flight_requests` to `inflight_requests` to align it with the name of the corresponding settings.
-
-*Impact* +
-Update your workflow and applications to use the `inflight_requests` stat in
-place of `in_flight_requests`.
-====
-
-.The voting configuration exclusions API endpoint has changed.
-[%collapsible]
-====
-*Details* +
-The `POST /_cluster/voting_config_exclusions/{node_filter}` API has been
-removed in favour of `POST /_cluster/voting_config_exclusions?node_names=...`
-and `POST /_cluster/voting_config_exclusions?node_ids=...` which allow you to
-specify the names or IDs of the nodes to exclude.
-
-*Impact* +
-Use `POST /_cluster/voting_config_exclusions?node_ids=...` and specify the nodes
-to exclude instead of using a node filter. Requests submitted to the
-`/_cluster/voting_config_exclusions/{node_filter}` endpoint will return an
-error.
-====
-
-.Remote system indices are not followed automatically if they match an auto-follow pattern.
-[%collapsible]
-====
-*Details* +
-Remote system indices matching an {ref}/ccr-auto-follow.html[auto-follow
-pattern] won't be configured as a follower index automatically.
-
-*Impact* +
-Explicitly {ref}/ccr-put-follow.html[create a follower index] to follow a remote
-system index if that's the wanted behaviour.
-====
-
-.The EQL `wildcard` function has been removed.
-[%collapsible]
-====
-*Details* +
-The `wildcard` function was deprecated in {es} 7.13.0 and has been removed.
-
-*Impact* +
-Use the `like` or `regex` {ref}/eql-syntax.html#eql-syntax-pattern-comparison-keywords[keywords] instead.
-====
-
-[[ilm-freeze-noop]]
-.The ILM `freeze` action is now a no-op.
-[%collapsible]
-====
-*Details* +
-The ILM freeze action is now a no-op and performs no action on the index, as the freeze API endpoint
-has been removed in 8.0.
-
-*Impact* +
-Update your ILM policies to remove the `freeze` action from the `cold` phase.
-====
-
-[[ilm-policy-validation]]
-.Additional validation for ILM policies.
-[%collapsible]
-====
-*Details* +
-Creating or updating an ILM policy now requires that any referenced snapshot repositories and SLM
-policies exist.
-
-*Impact* +
-Update your code or configuration management to ensure that repositories and SLM policies are created
-before any policies that reference them.
-====
-
-.The deprecated `_upgrade` API has been removed.
-[%collapsible]
-====
-*Details* +
-Previously, the `_upgrade` API upgraded indices from the previous major
-version to the current version. The `_reindex` API should be used
-instead for that purpose.
-
-*Impact* +
-Requests made to the old `_upgrade` API will return an error.
-====
-
-.The deprecated freeze index API has been removed.
-[%collapsible]
-====
-*Details* +
-The freeze index API (`POST //_freeze`) has been removed.
-https://www.elastic.co/blog/significantly-decrease-your-elasticsearch-heap-memory-usage[Improvements
-in heap memory usage] have eliminated the reason to freeze indices.
-You can still unfreeze existing frozen indices using the
-{ref}/unfreeze-index-api.html[unfreeze index API]. For some use cases, the
-frozen tier may be a suitable replacement for frozen indices. See
-{ref}/data-tiers.html[data tiers] for more information.
-
-*Impact* +
-Requests made to the old freeze index API will return an error.
-====
-
-.The force merge API's `max_num_segments` and `only_expunge_deletes` parameters cannot both be specified in the same request.
-[%collapsible]
-====
-*Details* +
-Previously, the force merge API allowed the parameters `only_expunge_deletes`
-and `max_num_segments` to be set to a non default value at the same time. But
-the `max_num_segments` was silently ignored when `only_expunge_deletes` is set
-to `true`, leaving the false impression that it has been applied.
-
-*Impact* +
-When using the {ref}/indices-forcemerge.html[force merge API], do not specify
-values for both the `max_num_segments` and `only_expunge_deletes` parameters.
-Requests that include values for both parameters will return an error.
-====
-
-.The create or update index template API's `template` parameter has been removed.
-[%collapsible]
-====
-*Details* +
-In 6.0, we deprecated the `template` parameter in create or update index
-template requests in favor of using `index_patterns`. Support for the `template`
-parameter is now removed in 8.0.
-
-*Impact* +
-Use the {ref}/indices-templates-v1.html[create or update index template API]'s
-`index_patterns` parameter. Requests that include the `template` parameter will
-return an error.
-
-*Compatibility* +
-When {ref}/rest-api-compatibility.html[rest-api-compatibility] is
-{ref}/rest-api-compatibility.html[requested], the `template` parameter is mapped
-to `index_patterns`.
-====
-
-.Synced flush has been removed.
-[%collapsible]
-====
-*Details* +
-Synced flush was deprecated in 7.6 and is removed in 8.0. Use a regular flush
-instead as it has the same effect as a synced flush in 7.6 and later.
-
-*Impact* +
-Use the {ref}/indices-flush.html[flush API]. Requests to the
-`//flush/synced` or `/flush/synced` endpoints will return an error.
-
-*Compatibility* +
-When {ref}/rest-api-compatibility.html[rest-api-compatibility] is
-{ref}/rest-api-compatibility.html[requested], the request to synced flush is
-routed to the equivalent non-synced flush URL.
-====
-
-.The default for the `?wait_for_active_shards` parameter on the close index API has changed.
-[%collapsible]
-====
-*Details* +
-When closing an index in earlier versions, by default {es} would not wait for
-the shards of the closed index to be properly assigned before returning. From
-version 8.0 onwards the default behaviour is to wait for shards to be assigned
-according to the
-{ref}/docs-index_.html#index-wait-for-active-shards[`index.write.wait_for_active_shards`
-index setting].
-
-*Impact* +
-Accept the new behaviour, or specify `?wait_for_active_shards=0` to preserve
-the old behaviour if needed.
-====
-
-.The index stats API's `types` query parameter has been removed.
-[%collapsible]
-====
-*Details* +
-The index stats API's `types` query parameter has been removed. Previously, you
-could combine `types` with the `indexing` query parameter to return indexing
-stats for specific mapping types. Mapping types have been removed in 8.0.
-
-*Impact* +
-Discontinue use of the `types` query parameter. Requests that include the
-parameter will return an error.
-
-*Compatibility* +
-When {ref}/rest-api-compatibility.html[rest-api-compatibility] is
-{ref}/rest-api-compatibility.html[requested], the `types` query parameter is
-ignored and stats are returned for the entire index.
-====
-
-.The `user_agent` ingest processor's `ecs` parameter has no effect.
-[%collapsible]
-====
-*Details* +
-In 7.2, we deprecated the `ecs` parameter for the `user_agent` ingest processor.
-In 8.x, the `user_agent` ingest processor will only return {ecs-ref}[Elastic
-Common Schema (ECS)] fields, regardless of the `ecs` value.
-
-*Impact* +
-To avoid deprecation warnings, remove the parameter from your ingest pipelines.
-If a pipeline specifies an `ecs` value, the value is ignored.
-====
-
-.The `include_type_name` query parameter has been removed.
-[%collapsible]
-====
-*Details* +
-The `include_type_name` query parameter has been removed from the index
-creation, index template, and mapping APIs. Previously, you could set
-`include_type_name` to `true` to indicate that requests and responses should
-include a mapping type name. Mapping types have been removed in 8.x.
-
-*Impact* +
-Discontinue use of the `include_type_name` query parameter. Requests that
-include the parameter will return an error.
-
-*Compatibility* +
-When {ref}/rest-api-compatibility.html[rest-api-compatibility] is
-{ref}/rest-api-compatibility.html[requested], the `include_type_name` query
-parameter is ignored and any custom mapping types in the request are removed.
-====
-
-.Reindex from remote now re-encodes URL-encoded index names.
-[%collapsible]
-====
-*Details* +
-Reindex from remote would previously allow URL-encoded index names and not
-re-encode them when generating the search request for the remote host. This
-leniency has been removed such that all index names are correctly encoded when
-reindex generates remote search requests.
-
-*Impact* +
-Specify unencoded index names for reindex from remote requests.
-====
-
-.In the reindex, delete by query, and update by query APIs, the `size` parameter has been renamed.
-[%collapsible]
-====
-*Details* +
-Previously, a `_reindex` request had two different size specifications in the body:
-
-- Outer level, determining the maximum number of documents to process
-- Inside the `source` element, determining the scroll/batch size.
-
-The outer level `size` parameter has now been renamed to `max_docs` to
-avoid confusion and clarify its semantics.
-
-Similarly, the `size` parameter has been renamed to `max_docs` for
-`_delete_by_query` and `_update_by_query` to keep the 3 interfaces consistent.
-
-*Impact* +
-Use the replacement parameters. Requests containing the `size` parameter will
-return an error.
-
-*Compatibility* +
-When {ref}/rest-api-compatibility.html[rest-api-compatibility] is
-{ref}/rest-api-compatibility.html[requested], the `size` parameter is mapped to
-the `max_docs` parameter.
-====
-
-.The update by query API now rejects unsupported `script` fields.
-[%collapsible]
-====
-*Details* +
-An update by query API request that includes an unsupported field in the
-`script` object now returns an error. Previously, the API would silently ignore
-these unsupported fields.
-
-*Impact* +
-To avoid errors, remove unsupported fields from the `script` object.
-====
-
-.The cat node API's `local` query parameter has been removed.
-[%collapsible]
-====
-*Details* +
-The `?local` parameter to the `GET _cat/nodes` API was deprecated in 7.x and is
-rejected in 8.0. This parameter caused the API to use the local cluster state
-to determine the nodes returned by the API rather than the cluster state from
-the master, but this API requests information from each selected node
-regardless of the `?local` parameter which means this API does not run in a
-fully node-local fashion.
-
-*Impact* +
-Discontinue use of the `?local` query parameter. {ref}/cat-nodes.html[cat node
-API] requests that include this parameter will return an error.
-====
-
-.The cat shard API's `local` query parameter has been removed.
-[%collapsible]
-====
-*Details* +
-The `?local` parameter to the `GET _cat/shards` API was deprecated in 7.x and is
-rejected in 8.0. This parameter caused the API to use the local cluster state
-to determine the nodes returned by the API rather than the cluster state from
-the master, but this API requests information from each selected node
-regardless of the `?local` parameter which means this API does not run in a
-fully node-local fashion.
-
-*Impact* +
-Discontinue use of the `?local` query parameter. {ref}/cat-shards.html[cat shards
-API] requests that include this parameter will return an error.
-====
-
-.The cat indices API's `local` query parameter has been removed.
-[%collapsible]
-====
-*Details* +
-The `?local` parameter to the `GET _cat/indices` API was deprecated in 7.x and is
-rejected in 8.0. This parameter caused the API to use the local cluster state
-to determine the nodes returned by the API rather than the cluster state from
-the master, but this API requests information from each selected node
-regardless of the `?local` parameter which means this API does not run in a
-fully node-local fashion.
-
-*Impact* +
-Discontinue use of the `?local` query parameter. {ref}/cat-indices.html[cat indices
-API] requests that include this parameter will return an error.
-====
-
-.The get field mapping API's `local` query parameter has been removed.
-[%collapsible]
-====
-*Details* +
-The `local` parameter for get field mapping API was deprecated in 7.8 and is
-removed in 8.0. This parameter is a no-op and field mappings are always retrieved
-locally.
-
-*Impact* +
-Discontinue use of the `local` query parameter.
-{ref}/indices-get-field-mapping.html[get field mapping API] requests that
-include this parameter will return an error.
-====
-
-.Post data to jobs API is deprecated.
-[%collapsible]
-====
-*Details* +
-The {ml} {ref}/ml-post-data.html[post data to jobs API] is deprecated starting in 7.11.0
-and will be removed in a future major version.
-
-*Impact* +
-Use {ref}/ml-ad-apis.html#ml-api-datafeed-endpoint[{dfeeds}] instead.
-====
-
-.The `job_id` property of the Update {dfeeds} API has been removed.
-[%collapsible]
-====
-*Details* +
-The ability to update a `job_id` in a {dfeed} was deprecated in 7.3.0. and is
-removed in 8.0.
-
-*Impact* +
-It is not possible to move {dfeeds} between {anomaly-jobs}.
-====
-
-.Create repository and delete repository API's return `409` status code when a repository is in use instead of `500`.
-[%collapsible]
-====
-*Details* +
-The {ref}/put-snapshot-repo-api.html[Create or update snapshot repository API] and
-{ref}/delete-snapshot-repo-api.html[Delete snapshot repository API] return `409`
-status code when the request is attempting to modify an existing repository that's in use instead of status code `500`.
-
-*Impact* +
-Update client code that handles creation and deletion of repositories to reflect this change.
-====
-
-.The `allow_no_datafeeds` property has been removed from {ml} APIs.
-[%collapsible]
-====
-*Details* +
-The `allow_no_datafeeds` property was deprecated in the
-{ref}/cat-datafeeds.html[cat {dfeeds}],
-{ref}/ml-get-datafeed.html[get {dfeeds}],
-{ref}/ml-get-datafeed-stats.html[get {dfeed} statistics], and
-{ref}/ml-stop-datafeed.html[stop {dfeeds}] APIs in 7.10.0.
-
-*Impact* +
-Use `allow_no_match` instead.
-====
-
-.The `allow_no_jobs` property has been removed from {ml} APIs.
-[%collapsible]
-====
-*Details* +
-The `allow_no_jobs` property was deprecated in the
-{ref}/cat-anomaly-detectors.html[cat anomaly detectors],
-{ref}/ml-close-job.html[close {anomaly-jobs}],
-{ref}/ml-get-job.html[get {anomaly-jobs}],
-{ref}/ml-get-job-stats.html[get {anomaly-job} statistics], and
-{ref}/ml-get-overall-buckets.html[get overall buckets] APIs in 7.10.0.
-
-*Impact* +
-Use `allow_no_match` instead.
-====
-
-.The StartRollupJob endpoint now returns a success status if a job has already started.
-[%collapsible]
-====
-*Details* +
-Previously, attempting to start an already-started rollup job would
-result in a `500 InternalServerError: Cannot start task for Rollup Job
-[job] because state was [STARTED]` exception.
-
-Now, attempting to start a job that is already started will just
-return a successful `200 OK: started` response.
-
-*Impact* +
-Update your workflow and applications to assume that a 200 status in response to
-attempting to start a rollup job means the job is in an actively started state.
-The request itself may have started the job, or it was previously running and so
-the request had no effect.
-====
-
-.Stored scripts no longer support empty scripts or search templates.
-[%collapsible]
-====
-*Details* +
-The {ref}/create-stored-script-api.html[create or update stored script API]'s
-`source` parameter cannot be empty.
-
-*Impact* +
-Before upgrading, use the {ref}/delete-stored-script-api.html[delete stored
-script API] to delete any empty stored scripts or search templates.
-In 8.0, {es} will drop any empty stored scripts or empty search templates from
-the cluster state. Requests to create a stored script or search template with
-an empty `source` will return an error.
-====
-
-.The create or update stored script API's `code` parameter has been removed.
-[%collapsible]
-====
-*Details* +
-The {ref}/create-stored-script-api.html[create or update stored script API]'s
-`code` parameter has been removed. Use the `source` parameter instead.
-
-*Impact* +
-Discontinue use of the `code` parameter. Requests that include the parameter
-will return an error.
-====
-
-[[_type-search-matches-no-docs]]
-.Searches on the `_type` field are no longer supported.
-[%collapsible]
-====
-*Details* +
-In 8.x, the `_type` metadata field has been removed. {es} now handles a search
-on the `_type` field as a search on a non-existent field. A search on a
-non-existent field matches no documents, regardless of the query string.
-
-In 7.x, a search for `_doc` in the `_type` field would match the same documents
-as a `match_all` query.
-
-*Impact* +
-Remove queries on the `_type` field from your search requests and search
-templates. Searches that include these queries may return no results.
-====
-
-[[msearch-empty-line-support]]
-.The multi search API now parses an empty first line as action metadata in text files.
-[%collapsible]
-====
-*Details* +
-The multi search API now parses an empty first line as empty action metadata
-when you provide a text file as the request body, such as when using curl's
-`--data-binary` flag.
-
-The API no longer supports text files that contain:
-
-* An empty first line followed by a line containing only `{}`.
-* An empty first line followed by another empty line.
-
-*Impact* +
-Don't provide an unsupported text file to the multi search API. Requests that
-include an unsupported file will return an error.
-====
-
-[[remove-unmapped-type-string]]
-.The `unmapped_type: string` sort option has been removed.
-[%collapsible]
-====
-*Details* +
-Search requests no longer support the `unmapped_type: string` sort option.
-Instead, use `unmapped_type: keyword` to handle an unmapped field as if it had
-the `keyword` field type but ignore its values for sorting.
-
-*Impact* +
-Discontinue use of `unmapped_type: string`. Search requests that include the
-`unmapped_type: string` sort option will return shard failures.
-====
-
-[[id-field-data]]
-.Aggregating and sorting on `_id` is disallowed by default.
-[%collapsible]
-====
-*Details* +
-Previously, it was possible to aggregate and sort on the built-in `_id` field
-by loading an expensive data structure called fielddata. This was deprecated
-in 7.6 and is now disallowed by default in 8.0.
-
-*Impact* +
-Aggregating and sorting on `_id` should be avoided. As an alternative, the
-`_id` field's contents can be duplicated into another field with docvalues
-enabled (note that this does not apply to auto-generated IDs).
-====
-
-.The `common` query has been removed.
-[%collapsible]
-====
-*Details* +
-The `common` query, deprecated in 7.x, has been removed in 8.0.
-The same functionality can be achieved by the `match` query if the total number of hits is not tracked.
-
-*Impact* +
-Discontinue use of the `common` query. Search requests containing a `common`
-query will return an error.
-====
-
-.The `cutoff_frequency` parameter has been removed from the `match` and `multi_match` query.
-[%collapsible]
-====
-*Details* +
-The `cutoff_frequency` parameter, deprecated in 7.x, has been removed in 8.0 from `match` and `multi_match` queries.
-The same functionality can be achieved without any configuration provided that the total number of hits is not tracked.
-
-*Impact* +
-Discontinue use of the `cutoff_frequency` parameter. Search requests containing
-this parameter in a `match` or `multi_match` query will return an error.
-====
-
-.The `nested_filter` and `nested_path` properties have been removed from the search API's `sort` request body parameter.
-[%collapsible]
-====
-*Details* +
-The `nested_filter` and `nested_path` options, deprecated in 6.x, have been removed in favor of the `nested` context.
-
-*Impact* +
-Discontinue use of the `sort` request body parameter's `nested_filter` and
-`nested_path` properties. Requests containing these properties will return an
-error.
-====
-
-.Search and get requests are now routed to shards using adaptive replica selection by default.
-[%collapsible]
-====
-*Details* +
-{es} will no longer prefer using shards in the same location (with the same awareness attribute values) to process
-`_search` and `_get` requests. Adaptive replica selection (activated by default in this version) will route requests
-more efficiently using the service time of prior inter-node communications.
-
-*Impact* +
-No action needed.
-====
-
-.Vector functions using `(query, doc['field'])` are no longer supported.
-[%collapsible]
-====
-*Details* +
-The vector functions of the form `function(query, doc['field'])` were
-deprecated in 7.6, and are now removed in 8.x. The form
-`function(query, 'field')` should be used instead. For example,
-`cosineSimilarity(query, doc['field'])` is replaced by
-`cosineSimilarity(query, 'field')`.
-
-*Impact* +
-Use the `function(query, 'field')` form. Discontinue use of the `function(query,
-doc['field'])` form. Requests containing the `function(query,
-doc['field'])` form will return an error.
-====
-
-.The search API's `indices_boost` request body parameter no longer accepts object values.
-[%collapsible]
-====
-*Details* +
-The `indices_boost` option in the search request used to accept the boosts
-both as an object and as an array. The object format has been deprecated since
-5.2 and is now removed in 8.0.
-
-*Impact* +
-Use only array values in the `indices_boost` parameter. Requests containing an
-object value in the `indices_boost` parameter will return an error.
-====
-
-.The search API's `use_field_mapping` request body parameter has been removed.
-[%collapsible]
-====
-*Details* +
-In 7.0, we began formatting `docvalue_fields` by default using each field's
-mapping definition. To ease the transition from 6.x, we added the format
-option `use_field_mapping`. This parameter was deprecated in 7.0, and is now
-removed in 8.0.
-
-*Impact* +
-Discontinue use of the `use_field_mapping` request body parameter. Requests
-containing this parameter will return an error.
-
-*Compatibility* +
-When {ref}/rest-api-compatibility.html[rest-api-compatibility] is
-{ref}/rest-api-compatibility.html[requested], the `use_field_mapping` parameter
-is ignored.
-====
-
-.The search API's `from` request body and url parameter cannot be negative.
-[%collapsible]
-====
-*Details* +
-Search request used to accept `-1` as a `from` in the search body and the url,
-treating it as the default value of 0. Other negative values got rejected with
-an error already. We now also reject `-1` as an invalid value.
-
-*Impact* +
-Change any use of `-1` as `from` parameter in request body or url parameters by either
-setting it to `0` or omitting it entirely. Requests containing negative values will
-return an error.
-====
-
-.Range queries on date fields treat numeric values alwas as milliseconds-since-epoch.
-[%collapsible]
-====
-*Details* +
-Range queries on date fields used to misinterpret small numbers (e.g. four digits like 1000)
-as a year when no additional format was set, but would interpret other numeric values as
-milliseconds since epoch. We now treat all numeric values in absence of a specific `format`
-parameter as milliseconds since epoch. If you want to query for years instead, with a missing
-`format` you now need to quote the input value (e.g. "1984").
-
-*Impact* +
-If you query date fields without a specified `format`, check if the values in your queries are
-actually meant to be milliseconds-since-epoch and use a numeric value in this case. If not, use
-a string value which gets parsed by either the date format set on the field in the mappings or
-by `strict_date_optional_time` by default.
-====
-
-.The `geo_bounding_box` query's `type` parameter has been removed.
-[%collapsible]
-====
-*Details* +
-The `geo_bounding_box` query's `type` parameter was deprecated in 7.14.0 and has
-been removed in 8.0.0. This parameter is a no-op and has no effect on the query.
-
-*Impact* +
-Discontinue use of the `type` parameter. `geo_bounding_box` queries that include
-this parameter will return an error.
-====
-
-.The `type` query has been removed.
-[%collapsible]
-====
-*Details* +
-The `type` query has been removed. Mapping types have been removed in 8.0.
-
-*Impact* +
-Discontinue use of the `type` query. Requests that include the `type` query
-will return an error.
-
-====
-
-.The `kibana_user` role has been renamed `kibana_admin`.
-[%collapsible]
-====
-*Details* +
-Users who were previously assigned the `kibana_user` role should instead be assigned
-the `kibana_admin` role. This role grants the same set of privileges as `kibana_user`, but has been
-renamed to better reflect its intended use.
-
-*Impact* +
-Assign users with the `kibana_user` role to the `kibana_admin` role.
-Discontinue use of the `kibana_user` role.
-====
-
-[[snapshot-resolve-system-indices]]
-.For snapshot and {slm-init} APIs, the `indices` parameter no longer resolves to system indices or system data streams.
-[%collapsible]
-====
-*Details* +
-For snapshot and {slm-init} APIs, the `indices` parameter no longer resolves to
-system indices or system data streams.
-{ref}/snapshot-restore.html#feature-state[Feature states] are now the only way
-to back up and restore system indices or system data streams from a snapshot.
-
-You can no longer use the `indices` parameter for the
-{ref}/slm-api-put-policy.html[create {slm-init} policy API] or the
-{ref}/create-snapshot-api.html[create snapshot API] to include a system index in
-a snapshot. To back up a system index, use the `include_global_state` and
-`feature_states` parameters to include the corresponding feature state instead.
-By default, the `include_global_state` and `feature_states` parameters include
-all system indices.
-
-Similarly, you can no longer use the {ref}/restore-snapshot-api.html[restore snapshot
-API]'s `indices` parameter to restore a system index from a snapshot. To restore
-a system index, use the `include_global_state` and `feature_states` parameters
-to restore the corresponding feature state instead. By default, the
-`include_global_state` and `feature_states` parameters don't restore any system
-indices.
-
-*Impact* +
-If you previously used the `indices` parameter to back up or restore system
-indices, update your {slm-init} policies and application to use the
-`include_global_state` and `feature_states` parameters instead.
-
-An {slm-init} policy that explicitly specifies a system index in the `indices`
-parameter will fail to create snapshots. Similarly, a create snapshot API or
-restore snapshot API request that explicitly specifies a system index in the
-`indices` parameter will fail and return an error. If the `indices` value
-includes a wildcard (`*`) pattern, the pattern will no longer match system
-indices.
-====
-
-.Snapshots compress metadata files by default.
-[%collapsible]
-====
-*Details* +
-Previously, the default value for `compress` was `false`. The default has been changed to `true`.
-
-This change will affect both newly created repositories and existing repositories where `compress=false` has not been
-explicitly specified.
-
-*Impact* +
-Update your workflow and applications to assume a default value of `true` for
-the `compress` parameter.
-====
-
-.S3 snapshot repositories now use a DNS-style access pattern by default.
-[%collapsible]
-====
-*Details* +
-Starting in version 7.4, `s3` snapshot repositories no longer use the
-now-deprecated path-style access pattern by default. In versions 7.0, 7.1, 7.2
-and 7.3 `s3` snapshot repositories always used the path-style access pattern.
-This is a breaking change for deployments that only support path-style access
-but which are recognized as supporting DNS-style access by the AWS SDK. This
-breaking change was made necessary by
-https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/[AWS's
-announcement] that the path-style access pattern is deprecated and will be
-unsupported on buckets created after September 30th 2020.
-
-*Impact* +
-If your deployment only supports path-style access and is affected by this
-change then you must configure the S3 client setting `path_style_access` to
-`true`.
-====
-
-.Restore requests no longer accept settings.
-[%collapsible]
-====
-*Details* +
-In earlier versions, you could pass both `settings` and `index_settings` in the
-body of a restore snapshot request, but the `settings` value was ignored. The
-restore snapshot API now rejects requests that include a `settings` value.
-
-*Impact* +
-Discontinue use of the `settings` parameter in restore
-snapshot request. Requests that include these parameters will return an error.
-====
-
-.The repository stats API has been removed.
-[%collapsible]
-====
-*Details* +
-The repository stats API has been removed. We deprecated this experimental API
-in 7.10.0.
-
-*Impact* +
-Use the {ref}/repositories-metering-apis.html[repositories metering APIs]
-instead.
-====
-
-.Watcher history now writes to a hidden data stream.
-[%collapsible]
-====
-*Details* +
-In 8.x, {es} writes Watcher history to a hidden
-`.watcher-history-` data stream. Previously, {es} wrote
-Watcher history to hidden
-`.watcher-history--` indices.
-
-*Impact* +
-Update your requests to target the Watcher history data stream. For example, use
-the `.watcher-history-*` wildcard expression. Requests that specifically target
-non-existent Watcher history indices may return an error.
-====
-
-.HTTP Status code has changed for the Cluster Health API in case of a server timeout.
-[%collapsible]
-====
-*Details* +
-The {ref}/cluster-health.html[cluster health API] includes options for waiting
-for certain health conditions to be satisfied. If the requested conditions are
-not satisfied within a timeout then {es} will send back a normal response
-including the field `"timed_out": true`. In earlier versions it would also use
-the HTTP response code `408 Request timeout` if the request timed out, and `200
-OK` otherwise. The `408 Request timeout` response code is not appropriate for
-this situation, so from version 8.0.0 {es} will use the response code `200 OK`
-for both cases.
-
-*Impact* +
-To detect a server timeout, check the `timed_out` field of the JSON response.
-====
diff --git a/docs/reference/migration/migrate_8_0/sql-jdbc-changes.asciidoc b/docs/reference/migration/migrate_8_0/sql-jdbc-changes.asciidoc
deleted file mode 100644
index 71efa21e032f5..0000000000000
--- a/docs/reference/migration/migrate_8_0/sql-jdbc-changes.asciidoc
+++ /dev/null
@@ -1,22 +0,0 @@
-[discrete]
-[[breaking_80_jdbc_changes]]
-==== SQL JDBC changes
-
-.JDBC driver returns geometry objects as well-known-text string instead of `org.elasticsearch.geo` objects.
-[%collapsible]
-====
-*Details* +
-To reduce the dependency of the JDBC driver onto Elasticsearch classes, the JDBC driver returns geometry data
-as strings using the WKT (well-known text) format instead of classes from the `org.elasticsearch.geometry`.
-Users can choose the geometry library desired to convert the string representation into a full-blown objects
-either such as the `elasticsearch-geo` library (which returned the object `org.elasticsearch.geo` as before),
-jts or spatial4j.
-
-*Impact* +
-Before upgrading, replace any `org.elasticsearch.geo` classes on the `ResultSet#getObject` or `ResultSet#setObject`
-Elasticsearch JDBC driver with their WKT representation by simply calling `toString` or
-`org.elasticsearch.geometry.utils.WellKnownText#toWKT/fromWKT` methods.
-
-This change does NOT impact users that do not use geometry classes.
-
-====
diff --git a/docs/reference/migration/migrate_8_0/system-req-changes.asciidoc b/docs/reference/migration/migrate_8_0/system-req-changes.asciidoc
deleted file mode 100644
index df698eaeb2dfd..0000000000000
--- a/docs/reference/migration/migrate_8_0/system-req-changes.asciidoc
+++ /dev/null
@@ -1,59 +0,0 @@
-[discrete]
-[[breaking_80_system_req_changes]]
-==== System requirement changes
-
-TIP: {ess-skip-section}
-
-.Several EOL operating systems are no longer supported.
-[%collapsible]
-====
-*Details* +
-The following operating systems have reached their end of life and are no longer
-supported by {es}:
-
-* Amazon Linux
-* CentOS 6
-* Debian 8
-* openSUSE Leap 42
-* Oracle Enterprise Linux 6
-* Ubuntu 16.04
-
-We've also removed support for `SysV init`. No supported operating systems use
-the `SysV init` process.
-
-*Details* +
-Ensure your nodes use a
-https://www.elastic.co/support/matrix#matrix_os[supported operating system].
-Running {es} on an unsupported operating system can result in unexpected errors
-or failures.
-====
-
-.Java 17 is required.
-[%collapsible]
-====
-*Details* +
-Java 17 or higher is now required to run {es} and any of its command
-line tools.
-
-*Impact* +
-Use Java 17 or higher. Attempts to run {es} 8.0 using earlier Java versions will
-fail.
-
-There is not yet a FIPS-certified security module for Java 17
-that you can use when running {es} 8.0 in FIPS 140-2 mode.
-If you run in FIPS 140-2 mode, you will either need to request an exception
-from your security organization to upgrade to {es} 8.0,
-or remain on {es} 7.x until Java 17 is certified.
-====
-
-.`JAVA_HOME` is no longer supported.
-[%collapsible]
-====
-*Details* +
-`JAVA_HOME` is no longer supported to set the path for the JDK. Instead, use
-the bundled JDK (preferable), or set `ES_JAVA_HOME`.
-
-*Impact* +
-Use the bundled JDK (preferable), or set `ES_JAVA_HOME`. `JAVA_HOME` will be
-ignored.
-====
diff --git a/docs/reference/migration/migrate_8_0/transform.asciidoc b/docs/reference/migration/migrate_8_0/transform.asciidoc
deleted file mode 100644
index aa47e28d83750..0000000000000
--- a/docs/reference/migration/migrate_8_0/transform.asciidoc
+++ /dev/null
@@ -1,16 +0,0 @@
-[discrete]
-[[breaking_80_transform_changes]]
-==== Transform changes
-
-.{transforms-cap} created in 7.4 or earlier versions must be upgraded.
-[%collapsible]
-====
-*Details* +
-Early beta versions of {transforms} had configuration information in a format
-that is no longer supported.
-
-
-*Impact* +
-Use the {ref}/upgrade-transforms.html[upgrade {transforms} API] to fix your
-{transforms}. This upgrade does not affect the source or destination indices.
-====
diff --git a/docs/reference/migration/migrate_8_1.asciidoc b/docs/reference/migration/migrate_8_1.asciidoc
deleted file mode 100644
index 692559205f735..0000000000000
--- a/docs/reference/migration/migrate_8_1.asciidoc
+++ /dev/null
@@ -1,109 +0,0 @@
-[[migrating-8.1]]
-== Migrating to 8.1
-++++
-8.1
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.1.
-
-See also <> and <>.
-
-
-[discrete]
-[[breaking-changes-8.1]]
-=== Breaking changes
-
-The following changes in {es} 8.1 might affect your applications
-and prevent them from operating normally.
-Before upgrading to 8.1, review these changes and take the described steps
-to mitigate the impact.
-
-[discrete]
-[[breaking_81_rest_api_changes]]
-==== REST API changes
-
-[[search_apis_fields_parameter_normalizes_geometry_objects_cross_international_dateline]]
-.The search API's `fields` parameter now normalizes geometry objects that cross the international dateline
-[%collapsible]
-====
-*Details* +
-The search API's `fields` parameter now normalizes `geo_shape` objects that
-cross the international dateline (+/-180° longitude). For example, if a polygon
-crosses the dateline, the `fields` parameter returns it as two polygons. You can
-still retrieve original, unnormalized geometry objects from `_source`.
-
-*Impact* +
-If your application requires unnormalized geometry objects, retrieve them from
-`_source` rather than using the `fields` parameter.
-====
-
-
-[discrete]
-[[deprecated-8.1]]
-=== Deprecations
-
-The following functionality has been deprecated in {es} 8.1
-and will be removed in a future version.
-While this won't have an immediate impact on your applications,
-we strongly encourage you take the described steps to update your code
-after upgrading to 8.1.
-
-To find out if you are using any deprecated functionality,
-enable <>.
-
-[discrete]
-[[deprecations_81_cluster_and_node_setting]]
-==== Cluster and node setting deprecations
-
-[[legacy_values_for_discovery_type_setting_are_deprecated]]
-.Legacy values for the `discovery.type` setting are deprecated
-[%collapsible]
-====
-*Details* +
-Legacy values for the `discovery.type` setting are deprecated and will be
-forbidden in a future version.
-
-*Impact* +
-Do not set `discovery.type` to any value except `single-node` or `multi-node`.
-All other values are equivalent to the default discovery type which is
-`multi-node`. Where possible, omit this setting so that {es} uses the default
-discovery type.
-====
-
-[discrete]
-[[deprecations_81_rest_api]]
-==== REST API deprecations
-
-[[lenient_parsing_of_bulk_actions_deprecated]]
-.Lenient parsing of bulk actions is deprecated
-[%collapsible]
-====
-*Details* +
-Older versions of {es} parse the action lines of bulk requests very permissively
-and would silently ignore invalid or malformed actions. This lenience is
-deprecated and a future version will reject bulk requests containing invalid
-actions.
-
-*Impact* +
-Ensure that bulk actions are well-formed JSON objects containing a single entry
-with the correct key.
-====
-
-[[deprecate_index_include_frozen_request_parameter_in_sql_api]]
-.Deprecate `index_include_frozen` request parameter in `_sql` API
-[%collapsible]
-====
-*Details* +
-Following the deprecation of frozen indices, the `index_include_frozen`
-parameter and `FROZEN` syntax is now also deprecated.
-
-*Impact* +
-You should unfreeze frozen indices using the
-{ref}/unfreeze-index-api.html[unfreeze index API] and stop using the
-`index_include_frozen` parameter or the `FROZEN` keyword in SQL
-queries. For some use cases, the frozen tier may be a suitable
-replacement for frozen indices. See {ref}/data-tiers.html[data tiers]
-for more information.
-====
-
diff --git a/docs/reference/migration/migrate_8_10.asciidoc b/docs/reference/migration/migrate_8_10.asciidoc
deleted file mode 100644
index a1d132812ad03..0000000000000
--- a/docs/reference/migration/migrate_8_10.asciidoc
+++ /dev/null
@@ -1,89 +0,0 @@
-[[migrating-8.10]]
-== Migrating to 8.10
-++++
-8.10
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.10.
-
-See also <> and <>.
-
-[discrete]
-[[breaking-changes-8.10]]
-=== Breaking changes
-
-The following changes in {es} 8.10 might affect your applications
-and prevent them from operating normally.
-Before upgrading to 8.10, review these changes and take the described steps
-to mitigate the impact.
-
-
-There are no notable breaking changes in {es} 8.10.
-But there are some less critical breaking changes.
-
-[discrete]
-[[breaking_810_cluster_and_node_setting_changes]]
-==== Cluster and node setting changes
-
-[[remove_unused_executor_builder_for_vector_tile_plugin]]
-.Remove the unused executor builder for vector tile plugin
-[%collapsible]
-====
-*Details* +
-The threadpool called `vectortile` is a left over from the original development of the vector tile search end point and it is used nowhere. It can still be a breaking change if it is configured on the elasticsearch yml file, for example by changing the threadpool size `thread_pool.vectortile.size=8`'
-
-*Impact* +
-In the case the threadpool appears on the yaml file, Elasticsearch will not start until those lines are removed.
-====
-
-[discrete]
-[[breaking_810_java_api_changes]]
-==== Java API changes
-
-[[change_pre_configured_cached_analyzer_components_to_use_indexversion_instead_of_version-highlight]]
-.Change pre-configured and cached analyzer components to use IndexVersion instead of Version
-[%collapsible]
-====
-*Details* +
-This PR changes the types used to obtain pre-configured components from Version to IndexVersion,
-with corresponding changes to method names.
-
-Prior to 8.10, there is a one-to-one mapping between node version and index version, with corresponding constants
-in the IndexVersion class.
-Starting in 8.10, IndexVersion is versioned independently of node version, and will be a simple incrementing number.
-For more information on how to use IndexVersion and other version types, please see the contributing guide.
-
-*Impact* +
-Analysis components now take IndexVersion instead of Version
-====
-
-
-[discrete]
-[[deprecated-8.10]]
-=== Deprecations
-
-The following functionality has been deprecated in {es} 8.10
-and will be removed in a future version.
-While this won't have an immediate impact on your applications,
-we strongly encourage you to take the described steps to update your code
-after upgrading to 8.10.
-
-To find out if you are using any deprecated functionality,
-enable <>.
-
-[discrete]
-[[deprecations_810_authorization]]
-==== Authorization deprecations
-
-[[mark_apm_user_for_removal_in_future_major_release]]
-.Mark `apm_user` for removal in a future major release
-[%collapsible]
-====
-*Details* +
-The `apm_user` role has been deprecated and will be removed in a future major release. Users should migrate to `editor` and `viewer` roles
-
-*Impact* +
-Users will have to migrate to `editor` and `viewer` roles
-====
-
diff --git a/docs/reference/migration/migrate_8_11.asciidoc b/docs/reference/migration/migrate_8_11.asciidoc
deleted file mode 100644
index 098456e1aca42..0000000000000
--- a/docs/reference/migration/migrate_8_11.asciidoc
+++ /dev/null
@@ -1,69 +0,0 @@
-[[migrating-8.11]]
-== Migrating to 8.11
-++++
-8.11
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.11.
-
-See also <> and <>.
-
-
-[discrete]
-[[breaking-changes-8.11]]
-=== Breaking changes
-
-The following changes in {es} 8.11 might affect your applications
-and prevent them from operating normally.
-Before upgrading to 8.11, review these changes and take the described steps
-to mitigate the impact.
-
-
-There are no notable breaking changes in {es} 8.11.
-But there are some less critical breaking changes.
-
-[discrete]
-[[breaking_811_rest_api_changes]]
-==== REST API changes
-
-[[remove_transport_versions_from_cluster_state_api]]
-.Remove `transport_versions` from cluster state API
-[%collapsible]
-====
-*Details* +
-The `transport_versions` subobject of the response to `GET _cluster/state` has been replaced by the `nodes_versions` subobject.
-
-*Impact* +
-If needed, retrieve the per-node transport versions from the `nodes_versions` subobject.
-====
-
-
-[discrete]
-[[deprecated-8.11]]
-=== Deprecations
-
-The following functionality has been deprecated in {es} 8.11
-and will be removed in a future version.
-While this won't have an immediate impact on your applications,
-we strongly encourage you to take the described steps to update your code
-after upgrading to 8.11.
-
-To find out if you are using any deprecated functionality,
-enable <>.
-
-[discrete]
-[[deprecations_811_rollup]]
-==== Rollup deprecations
-
-[[rollup_functionality_deprecated]]
-.Rollup functionality is now deprecated
-[%collapsible]
-====
-*Details* +
-<> has been deprecated and will be removed in a future release. Previously, rollups were available in technical preview.
-
-*Impact* +
-Use <> to reduce storage costs for time series data by storing it at reduced granularity.
-====
-
diff --git a/docs/reference/migration/migrate_8_12.asciidoc b/docs/reference/migration/migrate_8_12.asciidoc
deleted file mode 100644
index c7f4aa8728693..0000000000000
--- a/docs/reference/migration/migrate_8_12.asciidoc
+++ /dev/null
@@ -1,74 +0,0 @@
-[[migrating-8.12]]
-== Migrating to 8.12
-++++
-8.12
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.12.
-
-See also <> and <>.
-
-[discrete]
-[[breaking-changes-8.12]]
-=== Breaking changes
-
-There are no breaking changes in 8.12
-
-[discrete]
-[[notable-changes-8.12]]
-=== Notable changes
-
-There are notable changes in 8.12 that you need to be aware of, items that we may consider as notable changes are
-
-* Changes to features that are in Technical Preview.
-* Changes to log formats.
-* Changes to non public APIs.
-* Behaviour changes that repair critical bugs.
-
-
-[discrete]
-[[breaking_812_authorization_changes]]
-==== Authorization changes
-
-[[fixed_jwt_principal_from_claims]]
-.Fixed JWT principal from claims
-[%collapsible]
-====
-*Details* +
-This changes the format of a JWT's principal before the JWT is actually validated by any JWT realm. The JWT's principal is a convenient way to refer to a JWT that has not yet been verified by a JWT realm. The JWT's principal is printed in the audit and regular logs (notably for auditing authn failures) as well as the smart realm chain reordering optimization. The JWT principal is NOT required to be identical to the JWT-authenticated user's principal, but in general, they should be similar. Previously, the JWT's principal was built by individual realms in the same way the realms built the authenticated user's principal. This had the advantage that, in simpler JWT realms configurations (e.g. a single JWT realm in the chain), the JWT principal and the authenticated user's principal are very similar. However the drawback is that, in general, the JWT principal and the user principal can be very different (i.e. in the case where one JWT realm builds the JWT principal and a different one builds the user principal). Another downside is that the (unauthenticated) JWT principal depended on realm ordering, which makes identifying the JWT from its principal dependent on the ES authn realm configuration. This PR implements a consistent fixed logic to build the JWT principal, which only depends on the JWT's claims and no ES configuration.
-
-*Impact* +
-Users will observe changed format and values for the `user.name` attribute of `authentication_failed` audit log events, in the JWT (failed) authn case.
-====
-
-[discrete]
-[[breaking_812_java_api_changes]]
-==== Java API changes
-
-[[plugin_createcomponents_method_has_been_refactored_to_take_single_pluginservices_object]]
-.Plugin.createComponents method has been refactored to take a single PluginServices object
-[%collapsible]
-====
-*Details* +
-Plugin.createComponents currently takes several different service arguments. The signature of this method changes every time a new service is added. The method has now been modified to take a single interface object that new services are added to. This will reduce API incompatibility issues when a new service is introduced in the future.
-
-*Impact* +
-Plugins that override createComponents will need to be refactored to override the new method on ES 8.12+
-====
-
-[discrete]
-[[breaking_812_rest_api_changes]]
-==== REST API changes
-
-[[es_ql_pow_function_always_returns_double]]
-.[ES|QL] pow function always returns double
-[%collapsible]
-====
-*Details* +
-This corrects an earlier mistake in the ES|QL language design. Initially we had thought to have pow return the same type as its inputs, but in practice even for integer inputs this quickly grows out of the representable range, and we returned null much of the time. This also created a lot of edge cases around casting to/from doubles (which the underlying java function uses). The version in this PR follows the java spec, by always casting its inputs to doubles, and returning a double. Doing it this way also allows for a rather significant reduction in lines of code.
-
-*Impact* +
-low. Most queries should continue to function with the change.
-====
-
diff --git a/docs/reference/migration/migrate_8_13.asciidoc b/docs/reference/migration/migrate_8_13.asciidoc
deleted file mode 100644
index dca10671e57bc..0000000000000
--- a/docs/reference/migration/migrate_8_13.asciidoc
+++ /dev/null
@@ -1,137 +0,0 @@
-[[migrating-8.13]]
-== Migrating to 8.13
-++++
-8.13
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.13.
-
-See also <> and <>.
-
-coming::[8.13.0]
-
-
-[discrete]
-[[breaking-changes-8.13]]
-=== Breaking changes
-
-There are no breaking changes in 8.13.
-
-[discrete]
-[[migrate-notable-changes-8.13]]
-=== Notable changes
-The following are notable, non-breaking updates to be aware of:
-
-* Changes to features that are in Technical Preview.
-* Changes to log formats.
-* Changes to non-public APIs.
-* Behaviour changes that repair critical bugs.
-
-[discrete]
-[[breaking_813_index_setting_changes]]
-==== Index setting changes
-
-[[change_index_look_ahead_time_index_settings_default_value_from_2_hours_to_30_minutes]]
-.Change `index.look_ahead_time` index setting's default value from 2 hours to 30 minutes.
-[%collapsible]
-====
-*Details* +
-Lower the `index.look_ahead_time` index setting's max value from 2 hours to 30 minutes.
-
-*Impact* +
-Documents with @timestamp of 30 minutes or more in the future will be rejected. Before documents with @timestamp of 2 hours or more in the future were rejected. If the previous behaviour should be kept, then update the `index.look_ahead_time` setting to two hours before performing the upgrade.
-====
-
-[[lower_look_ahead_time_index_settings_max_value]]
-.Lower the `look_ahead_time` index setting's max value
-[%collapsible]
-====
-*Details* +
-Lower the `look_ahead_time` index setting's max value from 7 days to 2 hours.
-
-*Impact* +
-Any value between 2 hours and 7 days will be as a look ahead time of 2 hours is defined
-====
-
-[discrete]
-[[breaking_813_rest_api_changes]]
-==== REST API changes
-
-[[esql_grammar_from_metadata_no_longer_requires]]
-.ESQL: Grammar - FROM METADATA no longer requires []
-[%collapsible]
-====
-*Details* +
-Remove [ ] for METADATA option inside FROM command statements
-
-*Impact* +
-Previously to return metadata fields, one had to use square brackets: (eg. 'FROM index [METADATA _index]'). This is no longer needed: the [ ] are dropped and do not have to be specified, thus simplifying the command above to:'FROM index METADATA _index'.
-====
-
-[[es_ql_remove_project_keyword_from_grammar]]
-.ES|QL: remove PROJECT keyword from the grammar
-[%collapsible]
-====
-*Details* +
-Removes the PROJECT keyword (an alias for KEEP) from ES|QL grammar
-
-*Impact* +
-Before this change, users could use PROJECT as an alias for KEEP in ESQL queries, (eg. 'FROM idx | PROJECT name, surname') the parser replaced PROJECT with KEEP, emitted a warning: 'PROJECT command is no longer supported, please use KEEP instead' and the query was executed normally. With this change, PROJECT command is no longer recognized by the query parser; queries using PROJECT command now return a parsing exception.
-====
-
-[[esql_remove_nan_finite_infinite]]
-.[ESQL] Remove is_nan, is_finite, and `is_infinite`
-[%collapsible]
-====
-*Details* +
-Removes the functions `is_nan`, `is_finite`, and `is_infinite`.
-
-*Impact* +
-Attempting to use the above functions will now be a planner time error. These functions are no longer supported.
-====
-
-
-[discrete]
-[[deprecated-8.13]]
-=== Deprecations
-
-The following functionality has been deprecated in {es} 8.13
-and will be removed in a future version.
-While this won't have an immediate impact on your applications,
-we strongly encourage you to take the described steps to update your code
-after upgrading to 8.13.
-
-To find out if you are using any deprecated functionality,
-enable <>.
-
-[discrete]
-[[deprecations_813_cluster_and_node_setting]]
-==== Cluster and node setting deprecations
-
-[[deprecate_client_type]]
-.Deprecate `client.type`
-[%collapsible]
-====
-*Details* +
-The node setting `client.type` has been ignored since the node client was removed in 8.0. The setting is now deprecated and will be removed in a future release.
-
-*Impact* +
-Remove the `client.type` setting from `elasticsearch.yml`
-====
-
-[discrete]
-[[deprecations_813_rest_api]]
-==== REST API deprecations
-
-[[desirednode_deprecate_node_version_field_make_it_optional_for_current_version]]
-.`DesiredNode:` deprecate `node_version` field and make it optional for the current version
-[%collapsible]
-====
-*Details* +
-The desired_node API includes a `node_version` field to perform validation on the new node version required. This kind of check is too broad, and it's better done by external logic, so it has been removed, making the `node_version` field not necessary. The field will be removed in a later version.
-
-*Impact* +
-Users should update their usages of `desired_node` to not include the `node_version` field anymore.
-====
-
diff --git a/docs/reference/migration/migrate_8_14.asciidoc b/docs/reference/migration/migrate_8_14.asciidoc
deleted file mode 100644
index 2e6cd439ebed0..0000000000000
--- a/docs/reference/migration/migrate_8_14.asciidoc
+++ /dev/null
@@ -1,90 +0,0 @@
-[[migrating-8.14]]
-== Migrating to 8.14
-++++
-8.14
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.14.
-
-See also <> and <>.
-
-coming::[8.14.0]
-
-
-[discrete]
-[[breaking-changes-8.14]]
-=== Breaking changes
-
-The following changes in {es} 8.14 might affect your applications
-and prevent them from operating normally.
-Before upgrading to 8.14, review these changes and take the described steps
-to mitigate the impact.
-
-
-There are no notable breaking changes in {es} 8.14.
-But there are some less critical breaking changes.
-
-[discrete]
-[[breaking_814_rest_api_changes]]
-==== REST API changes
-
-[[prevent_dls_fls_if_replication_assigned]]
-.Prevent DLS/FLS if `replication` is assigned
-[%collapsible]
-====
-*Details* +
-For cross-cluster API keys, {es} no longer allows specifying document-level security (DLS) or field-level security (FLS) in the `search` field, if `replication` is also specified. {es} likewise blocks the use of any existing cross-cluster API keys that meet this condition.
-
-*Impact* +
-Remove any document-level security (DLS) or field-level security (FLS) definitions from the `search` field for cross-cluster API keys that also have a `replication` field, or create two separate cross-cluster API keys, one for search and one for replication.
-====
-
-
-[discrete]
-[[breaking_814_dls_changes]]
-==== Stricter Document Level Security (DLS)
-
-[[stricter_dls_814]]
-.Document Level Security (DLS) applies stricter checks for the validate query API and for terms aggregations when min_doc_count is set to 0.
-
-[%collapsible]
-====
-*Details* +
-When Document Level Security (DLS) is applied to terms aggregations and min_doc_count is set to 0, stricter security rules apply.
-
-When Document Level Security (DLS) is applied to the validate query API with the rewrite parameter, stricter security rules apply.
-
-*Impact* +
-If needed, test workflows with DLS enabled to ensure that the stricter security rules do not impact your application.
-====
-
-
-[discrete]
-[[deprecated-8.14]]
-=== Deprecations
-
-The following functionality has been deprecated in {es} 8.14
-and will be removed in a future version.
-While this won't have an immediate impact on your applications,
-we strongly encourage you to take the described steps to update your code
-after upgrading to 8.14.
-
-To find out if you are using any deprecated functionality,
-enable <>.
-
-[discrete]
-[[deprecations_814_mapping]]
-==== Mapping deprecations
-
-[[deprecate_allowing_fields_in_scenarios_where_it_ignored]]
-.Deprecate allowing `fields` in scenarios where it is ignored
-[%collapsible]
-====
-*Details* +
-The following mapped types have always ignored `fields` when using multi-fields. This deprecation makes this clearer and we will completely disallow `fields` for these mapped types in the future.
-
-*Impact* +
-In the future, `join`, `aggregate_metric_double`, and `constant_keyword`, will all disallow supplying `fields` as a parameter in the mapping.
-====
-
diff --git a/docs/reference/migration/migrate_8_15.asciidoc b/docs/reference/migration/migrate_8_15.asciidoc
deleted file mode 100644
index 1961230da1bbf..0000000000000
--- a/docs/reference/migration/migrate_8_15.asciidoc
+++ /dev/null
@@ -1,140 +0,0 @@
-[[migrating-8.15]]
-== Migrating to 8.15
-++++
-8.15
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.15.
-
-See also <> and <>.
-
-coming::[8.15.0]
-
-
-[discrete]
-[[breaking-changes-8.15]]
-=== Breaking changes
-
-The following changes in {es} 8.15 might affect your applications
-and prevent them from operating normally.
-Before upgrading to 8.15, review these changes and take the described steps
-to mitigate the impact.
-
-[discrete]
-[[breaking_815_cluster_and_node_setting_changes]]
-==== Cluster and node setting changes
-
-[[change_skip_unavailable_remote_cluster_setting_default_value_to_true]]
-.Change `skip_unavailable` remote cluster setting default value to true
-[%collapsible]
-====
-*Details* +
-The default value of the `skip_unavailable` setting is now set to true. All existing and future remote clusters that do not define this setting will use the new default. This setting only affects cross-cluster searches using the _search or _async_search API.
-
-*Impact* +
-Unavailable remote clusters in a cross-cluster search will no longer cause the search to fail unless skip_unavailable is configured to be `false` in elasticsearch.yml or via the `_cluster/settings` API. Unavailable clusters with `skip_unavailable`=`true` (either explicitly or by using the new default) are marked as SKIPPED in the search response metadata section and do not fail the entire search. If users want to ensure that a search returns a failure when a particular remote cluster is not available, `skip_unavailable` must be now be set explicitly.
-====
-
-[discrete]
-[[breaking_815_rollup_changes]]
-==== Rollup changes
-
-[[disallow_new_rollup_jobs_in_clusters_with_no_rollup_usage]]
-.Disallow new rollup jobs in clusters with no rollup usage
-[%collapsible]
-====
-*Details* +
-The put rollup API will fail with an error when a rollup job is created in a cluster with no rollup usage
-
-*Impact* +
-Clusters with no rollup usage (either no rollup job or index) can not create new rollup jobs
-====
-
-[discrete]
-[[breaking_815_rest_api_changes]]
-==== REST API changes
-
-[[interpret_timeout_1_as_infinite_ack_timeout]]
-.Interpret `?timeout=-1` as infinite ack timeout
-[%collapsible]
-====
-*Details* +
-Today {es} accepts the parameter `?timeout=-1` in many APIs, but interprets
-this to mean the same as `?timeout=0`. From 8.15 onwards `?timeout=-1` will
-mean to wait indefinitely, aligning the behaviour of this parameter with
-other similar parameters such as `?master_timeout`.
-
-*Impact* +
-Use `?timeout=0` to force relevant operations to time out immediately
-instead of `?timeout=-1`
-====
-
-[[replace_model_id_with_inference_id]]
-.Replace `model_id` with `inference_id` in GET inference API
-[%collapsible]
-====
-*Details* +
-From 8.15 onwards the <> response will return an
-`inference_id` field instead of a `model_id`.
-
-*Impact* +
-If your application uses the `model_id` in a GET inference API response,
-switch it to use `inference_id` instead.
-====
-
-
-[discrete]
-[[deprecated-8.15]]
-=== Deprecations
-
-The following functionality has been deprecated in {es} 8.15
-and will be removed in a future version.
-While this won't have an immediate impact on your applications,
-we strongly encourage you to take the described steps to update your code
-after upgrading to 8.15.
-
-To find out if you are using any deprecated functionality,
-enable <>.
-
-[discrete]
-[[deprecations_815_cluster_and_node_setting]]
-==== Cluster and node setting deprecations
-
-[[deprecate_absolute_size_values_for_indices_breaker_total_limit_setting]]
-.Deprecate absolute size values for `indices.breaker.total.limit` setting
-[%collapsible]
-====
-*Details* +
-Previously, the value of `indices.breaker.total.limit` could be specified as an absolute size in bytes. This setting controls the overal amount of memory the server is allowed to use before taking remedial actions. Setting this to a specific number of bytes led to strange behaviour when the node maximum heap size changed because the circut breaker limit would remain unchanged. This would either leave the value too low, causing part of the heap to remain unused; or it would leave the value too high, causing the circuit breaker to be ineffective at preventing OOM errors. The only reasonable behaviour for this setting is that it scales with the size of the heap, and so absolute byte limits are now deprecated.
-
-*Impact* +
-Users must change their configuration to specify a percentage instead of an absolute number of bytes for `indices.breaker.total.limit`, or else accept the default, which is already specified as a percentage.
-====
-
-[discrete]
-[[deprecations_815_rest_api]]
-==== REST API deprecations
-
-[[deprecate_text_expansion_weighted_tokens_queries]]
-.Deprecate `text_expansion` and `weighted_tokens` queries
-[%collapsible]
-====
-*Details* +
-The `text_expansion` and `weighted_tokens` queries have been replaced by `sparse_vector`.
-
-*Impact* +
-Please update your existing `text_expansion` and `weighted_tokens` queries to use `sparse_vector.`
-====
-
-[[deprecate_using_slm_privileges_to_access_ilm]]
-.Deprecate using slm privileges to access ilm
-[%collapsible]
-====
-*Details* +
-The `read_slm` privilege can get the ILM status, and the `manage_slm` privilege can start and stop ILM. Access to these APIs should be granted using the `read_ilm` and `manage_ilm` privileges instead. Access to ILM APIs will be removed from SLM privileges in a future major release, and is now deprecated.
-
-*Impact* +
-Users that need access to the ILM status API should now use the `read_ilm` privilege. Users that need to start and stop ILM, should use the `manage_ilm` privilege.
-====
-
diff --git a/docs/reference/migration/migrate_8_16.asciidoc b/docs/reference/migration/migrate_8_16.asciidoc
deleted file mode 100644
index 950b8f7ec3964..0000000000000
--- a/docs/reference/migration/migrate_8_16.asciidoc
+++ /dev/null
@@ -1,37 +0,0 @@
-[[migrating-8.16]]
-== Migrating to 8.16
-++++
-8.16
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.16.
-
-See also <> and <>.
-
-coming::[8.16.0]
-
-
-[discrete]
-[[breaking-changes-8.16]]
-=== Breaking changes
-
-The following changes in {es} 8.16 might affect your applications
-and prevent them from operating normally.
-Before upgrading to 8.16, review these changes and take the described steps
-to mitigate the impact.
-
-[discrete]
-[[breaking_816_locale_change]]
-==== JDK locale database change
-
-{es} 8.16 changes the version of the JDK that is included from version 22 to version 23. This changes
-the locale database that is used by Elasticsearch from the _COMPAT_ database to the _CLDR_ database.
-This can result in significant changes to custom textual date field formats,
-and calculations for custom week-date date fields.
-
-For more information see <>.
-
-If you run {es} 8.16 on JDK version 22 or below, it will use the _COMPAT_ locale database
-to match the behavior of 8.15. However, please note that starting with {es} 9.0,
-{es} will use the _CLDR_ database regardless of JDK version it is run on.
diff --git a/docs/reference/migration/migrate_8_17.asciidoc b/docs/reference/migration/migrate_8_17.asciidoc
deleted file mode 100644
index 15bc6431c60ba..0000000000000
--- a/docs/reference/migration/migrate_8_17.asciidoc
+++ /dev/null
@@ -1,20 +0,0 @@
-[[migrating-8.17]]
-== Migrating to 8.17
-++++
-8.17
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.17.
-
-See also <> and <>.
-
-coming::[8.17.0]
-
-
-[discrete]
-[[breaking-changes-8.17]]
-=== Breaking changes
-
-There are no breaking changes in {es} 8.17.
-
diff --git a/docs/reference/migration/migrate_8_2.asciidoc b/docs/reference/migration/migrate_8_2.asciidoc
deleted file mode 100644
index 3630456aed6fd..0000000000000
--- a/docs/reference/migration/migrate_8_2.asciidoc
+++ /dev/null
@@ -1,16 +0,0 @@
-[[migrating-8.2]]
-== Migrating to 8.2
-++++
-8.2
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.2.
-
-See also <> and <>.
-
-[discrete]
-[[breaking-changes-8.2]]
-=== Breaking changes
-
-There are no breaking changes in {es} 8.2.
diff --git a/docs/reference/migration/migrate_8_3.asciidoc b/docs/reference/migration/migrate_8_3.asciidoc
deleted file mode 100644
index 1dfc2d1b8cd23..0000000000000
--- a/docs/reference/migration/migrate_8_3.asciidoc
+++ /dev/null
@@ -1,61 +0,0 @@
-[[migrating-8.3]]
-== Migrating to 8.3
-++++
-8.3
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.3.
-
-See also <> and <>.
-
-
-[discrete]
-[[breaking-changes-8.3]]
-=== Breaking changes
-
-There are no breaking changes in {es} 8.3.
-
-
-
-[discrete]
-[[deprecated-8.3]]
-=== Deprecations
-
-The following functionality has been deprecated in {es} 8.3
-and will be removed in a future version.
-While this won't have an immediate impact on your applications,
-we strongly encourage you take the described steps to update your code
-after upgrading to 8.3.
-
-To find out if you are using any deprecated functionality,
-enable <>.
-
-
-[discrete]
-[[deprecations_83_cluster_and_node_setting]]
-==== Cluster and node setting deprecations
-
-[[configuring_bind_dn_in_an_ldap_or_active_directory_ad_realm_without_corresponding_bind_password_deprecated]]
-.Configuring a bind DN in an LDAP or Active Directory (AD) realm without a corresponding bind password is deprecated
-[%collapsible]
-====
-*Details* +
-For LDAP or AD authentication realms, setting a bind DN (via the
-`xpack.security.authc.realms.ldap.*.bind_dn` realm setting) without a
-bind password is a misconfiguration that may prevent successful
-authentication to the node. In the next major release, nodes will fail
-to start if a bind DN is specified without a password.
-
-*Impact* +
-If you have a bind DN configured for an LDAP or AD authentication
-realm, set a bind password for {ref}/ldap-realm.html#ldap-realm-configuration[LDAP]
-or {ref}/active-directory-realm.html#ad-realm-configuration[Active Directory].
-Configuring a bind DN without a password generates a warning in the
-deprecation logs.
-
-*Note:* This deprecation only applies if your current LDAP or AD
-configuration specifies a bind DN without a password. This scenario is
-unlikely, but might impact a small subset of users.
-====
-
diff --git a/docs/reference/migration/migrate_8_4.asciidoc b/docs/reference/migration/migrate_8_4.asciidoc
deleted file mode 100644
index d9aab317d70f7..0000000000000
--- a/docs/reference/migration/migrate_8_4.asciidoc
+++ /dev/null
@@ -1,46 +0,0 @@
-[[migrating-8.4]]
-== Migrating to 8.4
-++++
-8.4
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.4.
-
-See also <> and <>.
-
-[discrete]
-[[breaking-changes-8.4]]
-=== Breaking changes
-
-There are no breaking changes in {es} 8.4.
-
-[discrete]
-[[deprecated-8.4]]
-=== Deprecations
-
-The following functionality has been deprecated in {es} 8.4
-and will be removed in a future version.
-While this won't have an immediate impact on your applications,
-we strongly encourage you to take the described steps to update your code
-after upgrading to 8.4.
-
-To find out if you are using any deprecated functionality,
-enable <>.
-
-
-[discrete]
-[[deprecations_84_rest_api]]
-==== REST API deprecations
-
-[[deprecate_knn_search_endpoint]]
-.Deprecate the `_knn_search` endpoint
-[%collapsible]
-====
-*Details* +
--| The kNN search API is deprecated in favor of the new 'knn' option inside the search API. The 'knn' option is now the recommended way of running ANN search.
-
-*Impact* +
-Users should switch from `_knn_search` to the search `knn` option.
-====
-
diff --git a/docs/reference/migration/migrate_8_5.asciidoc b/docs/reference/migration/migrate_8_5.asciidoc
deleted file mode 100644
index 1f040946670e1..0000000000000
--- a/docs/reference/migration/migrate_8_5.asciidoc
+++ /dev/null
@@ -1,101 +0,0 @@
-[[migrating-8.5]]
-== Migrating to 8.5
-++++
-8.5
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.5.
-
-See also <> and <>.
-
-[discrete]
-[[breaking-changes-8.5]]
-=== Breaking changes
-
-The following changes in {es} 8.5 might affect your applications and prevent
-them from operating normally. Before upgrading to 8.5, review these changes and
-take the described steps to mitigate the impact.
-
-[discrete]
-[[breaking_85_rest_api_changes]]
-==== REST API changes
-
-[[breaking_85_bulk_action_stricter]]
-.The bulk API now rejects requests containing unrecognized actions
-[%collapsible]
-====
-*Details* +
-Requests to the bulk API comprise a sequence of items, each of which starts with
-a JSON object describing the item. This object includes the type of action to
-perform with the item which should be one of `create`, `update`, `index`, or
-`delete`. Earlier versions of {es} had a bug that caused them to ignore items
-with an unrecognized type, skipping the next line in the request, but this
-lenient behaviour meant that there is no way for the client to associate the
-items in the response with the items in the request, and in some cases it would
-cause the remainder of the request to be parsed incorrectly.
-
-From version 8.5 onwards, requests to the bulk API must comprise only items
-with recognized types. {es} will reject requests containing any items with an
-unrecognized type with a `400 Bad Request` error response.
-
-We consider this change to be a bugfix but list it here as a breaking change
-since it may affect the behaviour of applications which rely on being able to
-send unrecognized actions to {es}.
-
-*Impact* +
-Ensure your application only sends items with type `create`, `update`, `index`
-or `delete` to the bulk API.
-====
-
-[discrete]
-[[deprecated-8.5]]
-=== Deprecations
-
-The following functionality has been deprecated in {es} 8.5
-and will be removed in a future version.
-While this won't have an immediate impact on your applications,
-we strongly encourage you to take the described steps to update your code
-after upgrading to 8.5.
-
-To find out if you are using any deprecated functionality,
-enable <>.
-
-
-[discrete]
-[[deprecations_85_plugins]]
-==== Plugin API deprecations
-
-[[network_plugins_deprecated]]
-Plugins that extend the NetworkPlugin interface are deprecated.
-[%collapsible]
-====
-*Details* +
-Plugins may override funcionality that controls how nodes connect
-with other nodes over TCP/IP. These plugins extend the NetworkPlugin
-interface. In the next major release, these plugins will fail
-to install.
-
-*Impact* +
-Discontinue using any plugins which extend NetworkPlugin. You can
-see if any plugins use deprecated functionality by checking
-the Elasticsearch deprecation log.
-====
-
-[[discoveryplugin_joinvalidator_and_election_strategies_deprecated]]
-.Extending DiscoveryPlugin to override join validators or election strategies is deprecated
-[%collapsible]
-====
-*Details* +
-Plugins that extend DiscoveryPlugin may override getJoinValidator and
-getElectionStrategies. These methods are implementation details of the
-clustering mechanism within Elasticsearch. They should not be overriden.
-In the next major release, plugins overriding getJoinValidator or
-getElectionStrategies will fail to install.
-
-*Impact* +
-Discontinue using any plugins that override getJoinValidator or
-getElectionStrategies in DiscoveryPlugin. You can see if any plugins
-use deprecated functionality by checking the Elasticsearch deprecation log.
-====
-
diff --git a/docs/reference/migration/migrate_8_6.asciidoc b/docs/reference/migration/migrate_8_6.asciidoc
deleted file mode 100644
index 80c0ece8c1e37..0000000000000
--- a/docs/reference/migration/migrate_8_6.asciidoc
+++ /dev/null
@@ -1,92 +0,0 @@
-[[migrating-8.6]]
-== Migrating to 8.6
-++++
-8.6
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.6.
-
-See also <> and <>.
-
-[discrete]
-[[breaking-changes-8.6]]
-=== Breaking changes
-
-There are no breaking changes in {es} 8.6.
-
-[discrete]
-[[deprecated-8.6]]
-=== Deprecations
-
-The following functionality has been deprecated in {es} 8.6
-and will be removed in a future version.
-While this won't have an immediate impact on your applications,
-we strongly encourage you to take the described steps to update your code
-after upgrading to 8.6.
-
-To find out if you are using any deprecated functionality,
-enable <>.
-
-
-[discrete]
-[[deprecations_86_crud]]
-==== CRUD deprecations
-
-[[deprecate_remove_binary_default_of_false_for_ingest_attachment_processor]]
-.Deprecate 'remove_binary' default of false for ingest attachment processor
-[%collapsible]
-====
-*Details* +
-The default "remove_binary" option for the attachment processor will be changed from false to true in a later Elasticsearch release. This means that the binary file sent to Elasticsearch will not be retained.
-
-*Impact* +
-Users should update the "remove_binary" option to be explicitly true or false, instead of relying on the default value, so that no default value changes will affect Elasticsearch.
-====
-
-[discrete]
-[[deprecations_86_cluster_and_node_setting]]
-==== Cluster and node setting deprecations
-
-[[ensure_balance_threshold_at_least_1]]
-.Ensure balance threshold is at least 1
-[%collapsible]
-====
-*Details* +
-Values for `cluster.routing.allocation.balance.threshold` smaller than `1` are now ignored. Support for values less than `1` for this setting is deprecated and will be forbidden in a future version.
-
-*Impact* +
-Set `cluster.routing.allocation.balance.threshold` to be at least `1`.
-====
-
-[discrete]
-[[deprecations_86_mapping]]
-==== Mapping deprecations
-
-[[deprecate_silently_ignoring_type_fields_copy_to_boost_in_metadata_field_definition]]
-.Deprecate silently ignoring type, fields, copy_to and boost in metadata field definition
-[%collapsible]
-====
-*Details* +
-Unsupported parameters like type, fields, copy_to and boost are silently ignored when provided as part of the configuration of a metadata field in the index mappings. They will cause a deprecation warning when used in the mappings for indices that are created from 8.6 onwards.
-
-*Impact* +
-To resolve the deprecation warning, remove the mention of type, fields, copy_to or boost from any metadata field definition as part of index mappings. They take no effect so removing them won't have any impact besides resolving the deprecation warning.
-====
-
-[discrete]
-[[deprecations_86_rest_api]]
-==== REST API deprecations
-
-[[state_field_deprecated_in_cluster_reroute_response]]
-.state field is deprecated in /_cluster/reroute response
-[%collapsible]
-====
-*Details* +
-`state` field is deprecated in `/_cluster/reroute` response. Cluster state does not provide meaningful information
-about the result of reroute/commands execution. There are no guarantees that this exact state would be applied.
-
-*Impact* +
-Reroute API users should not rely on `state` field and instead use `explain` to request result of commands execution.
-====
-
diff --git a/docs/reference/migration/migrate_8_7.asciidoc b/docs/reference/migration/migrate_8_7.asciidoc
deleted file mode 100644
index 2061743e1be4a..0000000000000
--- a/docs/reference/migration/migrate_8_7.asciidoc
+++ /dev/null
@@ -1,43 +0,0 @@
-[[migrating-8.7]]
-== Migrating to 8.7
-++++
-8.7
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.7.
-
-See also <> and <>.
-
-[discrete]
-[[breaking-changes-8.7]]
-=== Breaking changes
-
-The following changes in {es} 8.7 might affect your applications
-and prevent them from operating normally.
-Before upgrading to 8.7, review these changes and take the described steps
-to mitigate the impact.
-
-There are no notable breaking changes in {es} 8.7.
-But there are some less critical breaking changes.
-
-[discrete]
-[[breaking_87_ingest_changes]]
-==== Ingest changes
-
-[[making_jsonprocessor_stricter_so_it_does_not_silently_drop_data]]
-.Making `JsonProcessor` stricter so that it does not silently drop data
-[%collapsible]
-====
-*Details* +
-The ingest node's `json` processor was previously lenient. It would accept invalid JSON data if it started with valid JSON data.
-Anything after the valid part would be silently discarded. From 8.7 onwards, the default behavior is to reject invalid JSON data with
-an exception so that data is not silently lost. The old behavior can be reproduced by passing `false` as the value of the new
-`strict_json_parsing` processor parameter.
-We consider this change to be a bugfix but list it here as a breaking change since it may affect the behavior of applications which
-were sending invalid JSON data to the `json` processor.
-
-*Impact* +
-Ensure your application only sends valid JSON data to the `json` processor, or modify the `json` processors in your pipelines to set
-the `strict_json_parsing` parameter to `false`.
-====
diff --git a/docs/reference/migration/migrate_8_8.asciidoc b/docs/reference/migration/migrate_8_8.asciidoc
deleted file mode 100644
index 22c5ae2a33750..0000000000000
--- a/docs/reference/migration/migrate_8_8.asciidoc
+++ /dev/null
@@ -1,47 +0,0 @@
-[[migrating-8.8]]
-== Migrating to 8.8
-++++
-8.8
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.8.
-
-See also <> and <>.
-
-
-[discrete]
-[[breaking-changes-8.8]]
-=== Breaking changes
-
-There are no breaking changes in {es} 8.8.
-
-[discrete]
-[[deprecated-8.8]]
-=== Deprecations
-
-The following functionality has been deprecated in {es} 8.8
-and will be removed in a future version.
-While this won't have an immediate impact on your applications,
-we strongly encourage you to take the described steps to update your code
-after upgrading to 8.8.
-
-To find out if you are using any deprecated functionality,
-enable <>.
-
-
-[discrete]
-[[deprecations_88_cluster_and_node_setting]]
-==== Cluster and node setting deprecations
-
-[[deprecate_cluster_routing_allocation_type]]
-.Deprecate `cluster.routing.allocation.type`
-[%collapsible]
-====
-*Details* +
-The `cluster.routing.allocation.type` setting is deprecated and will be removed in a future version.
-
-*Impact* +
-Discontinue use of the `cluster.routing.allocation.type` setting.
-====
-
diff --git a/docs/reference/migration/migrate_8_9.asciidoc b/docs/reference/migration/migrate_8_9.asciidoc
deleted file mode 100644
index e2f54dc58bfe5..0000000000000
--- a/docs/reference/migration/migrate_8_9.asciidoc
+++ /dev/null
@@ -1,35 +0,0 @@
-[[migrating-8.9]]
-== Migrating to 8.9
-++++
-8.9
-++++
-
-This section discusses the changes that you need to be aware of when migrating
-your application to {es} 8.9.
-
-See also <> and <>.
-
-[discrete]
-[[breaking-changes-8.9]]
-=== Breaking changes
-
-The following changes in {es} 8.9 might affect your applications
-and prevent them from operating normally.
-Before upgrading to 8.9, review these changes and take the described steps
-to mitigate the impact.
-
-[discrete]
-[[breaking_89_rest_api_changes]]
-==== REST API changes
-
-[[switch_tdigeststate_to_use_hybriddigest_by_default]]
-.Switch TDigestState to use `HybridDigest` by default
-[%collapsible]
-====
-*Details* +
-The default implementation for TDigest in percentile calculations switches to a new internal implementation offering superior performance (2x-10x speedup), at a very small accuracy penalty for very large sample populations.
-
-*Impact* +
-This change leads to generating slightly different results in percentile calculations. If the highest possible accuracy is desired, or it's crucial to produce exactly the same results as in previous versions, one can either set `execution_hint` to `high_accuracy` in the `tdigest` spec of a given percentile calculation, or set `search.aggs.tdigest_execution_hint` to `high_accuracy` in cluster settings to apply to all percentile queries.
-====
-
diff --git a/docs/reference/migration/migrate_9_0.asciidoc b/docs/reference/migration/migrate_9_0.asciidoc
new file mode 100644
index 0000000000000..6569647fd993e
--- /dev/null
+++ b/docs/reference/migration/migrate_9_0.asciidoc
@@ -0,0 +1,319 @@
+// THIS IS A GENERATED FILE. DO NOT EDIT DIRECTLY.
+// The content generated here are is not correct and most has been manually commented out until it can be fixed.
+// See ES-9931 for more details.
+[[migrating-9.0]]
+== Migrating to 9.0
+++++
+9.0
+++++
+
+This section discusses the changes that you need to be aware of when migrating
+your application to {es} 9.0.
+
+See also <> and <>.
+
+coming::[9.0.0]
+
+
+[discrete]
+[[breaking-changes-9.0]]
+=== Breaking changes
+
+The following changes in {es} 9.0 might affect your applications
+and prevent them from operating normally.
+Before upgrading to 9.0, review these changes and take the described steps
+to mitigate the impact.
+//
+// [discrete]
+// [[breaking_90_analysis_changes]]
+// ==== Analysis changes
+//
+// [[set_lenient_to_true_by_default_when_using_updateable_synonyms]]
+// .Set lenient to true by default when using updateable synonyms
+// [%collapsible]
+// ====
+// *Details* +
+// When a `synonym` or `synonym_graph` token filter is configured with `updateable: true`, the default `lenient`
+// value will now be `true`.
+//
+// *Impact* +
+// `synonym` or `synonym_graph` token filters configured with `updateable: true` will ignore invalid synonyms by
+// default. This prevents shard initialization errors on invalid synonyms.
+// ====
+//
+// [discrete]
+// [[breaking_90_mapping_changes]]
+// ==== Mapping changes
+//
+// [[jdk_locale_database_change]]
+// .JDK locale database change
+// [%collapsible]
+// ====
+// *Details* +
+// {es} 8.16 changes the version of the JDK that is included from version 22 to version 23. This changes the locale database that is used by Elasticsearch from the COMPAT database to the CLDR database. This change can cause significant differences to the textual date formats accepted by Elasticsearch, and to calculated week-dates.
+//
+// If you run {es} 8.16 on JDK version 22 or below, it will use the COMPAT locale database to match the behavior of 8.15. However, starting with {es} 9.0, {es} will use the CLDR database regardless of JDK version it is run on.
+//
+// *Impact* +
+// This affects you if you use custom date formats using textual or week-date field specifiers. If you use date fields or calculated week-dates that change between the COMPAT and CLDR databases, then this change will cause Elasticsearch to reject previously valid date fields as invalid data. You might need to modify your ingest or output integration code to account for the differences between these two JDK versions.
+//
+// Starting in version 8.15.2, Elasticsearch will log deprecation warnings if you are using date format specifiers that might change on upgrading to JDK 23. These warnings are visible in Kibana.
+//
+// For detailed guidance, refer to <> and the https://ela.st/jdk-23-locales[Elastic blog].
+// ====
+//
+// [discrete]
+// [[breaking_90_analysis_changes]]
+// ==== Analysis changes
+//
+// [[snowball_stemmers_have_been_upgraded]]
+// .Snowball stemmers have been upgraded
+// [%collapsible]
+// ====
+// *Details* +
+// Lucene 10 ships with an upgrade of its Snowball stemmers. For details see https://github.com/apache/lucene/issues/13209. Users using Snowball stemmers that are experiencing changes in search behaviour on existing data are advised to reindex.
+//
+// *Impact* +
+// The upgrade should generally provide improved stemming results. Small changes in token analysis can lead to mismatches with previously index data, so existing indices using Snowball stemmers as part of their analysis chain should be reindexed.
+// ====
+//
+// [[german2_snowball_stemmer_an_alias_for_german_stemmer]]
+// .The "german2" snowball stemmer is now an alias for the "german" stemmer
+// [%collapsible]
+// ====
+// *Details* +
+// Lucene 10 has merged the improved "german2" snowball language stemmer with the "german" stemmer. For Elasticsearch, "german2" is now a deprecated alias for "german". This may results in slightly different tokens being generated for terms with umlaut substitution (like "ue" for "ü" etc...)
+//
+// *Impact* +
+// Replace usages of "german2" with "german" in analysis configuration. Old indices that use the "german" stemmer should be reindexed if possible.
+// ====
+//
+// [[persian_analyzer_has_stemmer_by_default]]
+// .The 'persian' analyzer has stemmer by default
+// [%collapsible]
+// ====
+// *Details* +
+// Lucene 10 has added a final stemming step to its PersianAnalyzer that Elasticsearch exposes as 'persian' analyzer. Existing indices will keep the old non-stemming behaviour while new indices will see the updated behaviour with added stemming. Users that wish to maintain the non-stemming behaviour need to define their own analyzer as outlined in https://www.elastic.co/guide/en/elasticsearch/reference/8.15/analysis-lang-analyzer.html#persian-analyzer. Users that wish to use the new stemming behaviour for existing indices will have to reindex their data.
+//
+// *Impact* +
+// Indexing with the 'persian' analyzer will produce slightly different tokens. Users should check if this impacts their search results. If they wish to maintain the legacy non-stemming behaviour they can define their own analyzer equivalent as explained in https://www.elastic.co/guide/en/elasticsearch/reference/8.15/analysis-lang-analyzer.html#persian-analyzer.
+// ====
+//
+// [[korean_dictionary_for_nori_has_been_updated]]
+// .The Korean dictionary for Nori has been updated
+// [%collapsible]
+// ====
+// *Details* +
+// Lucene 10 ships with an updated Korean dictionary (mecab-ko-dic-2.1.1). For details see https://github.com/apache/lucene/issues/11452. Users experiencing changes in search behaviour on existing data are advised to reindex.
+//
+// *Impact* +
+// The change is small and should generally provide better analysis results. Existing indices for full-text use cases should be reindexed though.
+// ====
+//
+// [discrete]
+// [[breaking_90_cluster_and_node_setting_changes]]
+// ==== Cluster and node setting changes
+//
+// [[remove_unsupported_legacy_value_for_discovery_type]]
+// .Remove unsupported legacy value for `discovery.type`
+// [%collapsible]
+// ====
+// *Details* +
+// Earlier versions of {es} had a `discovery.type` setting which permitted values that referred to legacy discovery types. From v9.0.0 onwards, the only supported values for this setting are `multi-node` (the default) and `single-node`.
+//
+// *Impact* +
+// Remove any value for `discovery.type` from your `elasticsearch.yml` configuration file.
+// ====
+//
+// [discrete]
+// [[breaking_90_es_ql_changes]]
+// ==== ES|QL changes
+//
+// [[esql_entirely_remove_meta_functions]]
+// .ESQL: Entirely remove META FUNCTIONS
+// [%collapsible]
+// ====
+// *Details* +
+// Removes an undocumented syntax from ESQL: META FUNCTION. This was never
+// reliable or really useful. Consult the documentation instead.
+//
+// *Impact* +
+// Removes an undocumented syntax from ESQL: META FUNCTION
+// ====
+//
+// [discrete]
+// [[breaking_90_rest_api_changes]]
+// ==== REST API changes
+//
+// [[remove_cluster_state_from_cluster_reroute_response]]
+// .Remove cluster state from `/_cluster/reroute` response
+// [%collapsible]
+// ====
+// *Details* +
+// The `POST /_cluster/reroute` API no longer returns the cluster state in its response. The `?metric` query parameter to this API now has no effect and its use will be forbidden in a future version.
+//
+// *Impact* +
+// Cease usage of the `?metric` query parameter when calling the `POST /_cluster/reroute` API.
+// ====
+//
+// [[remove_deprecated_local_attribute_from_alias_apis]]
+// .Remove deprecated local attribute from alias APIs
+// [%collapsible]
+// ====
+// *Details* +
+// The following APIs no longer accept the `?local` query parameter: `GET /_alias`, `GET /_aliases`, `GET /_alias/{name}`, `HEAD /_alias/{name}`, `GET /{index}/_alias`, `HEAD /{index}/_alias`, `GET /{index}/_alias/{name}`, `HEAD /{index}/_alias/{name}`, `GET /_cat/aliases`, and `GET /_cat/aliases/{alias}`. This parameter has been deprecated and ignored since version 8.12.
+//
+// *Impact* +
+// Cease usage of the `?local` query parameter when calling the listed APIs.
+// ====
+//
+// [[reworking_rrf_retriever_to_be_evaluated_during_rewrite_phase]]
+// .Reworking RRF retriever to be evaluated during rewrite phase
+// [%collapsible]
+// ====
+// *Details* +
+// In this release (8.16), we have introduced major changes to the retrievers framework
+// and how they can be evaluated, focusing mainly on compound retrievers
+// like `rrf` and `text_similarity_reranker`, which allowed us to support full
+// composability (i.e. any retriever can be nested under any compound retriever),
+// as well as supporting additional search features like collapsing, explaining,
+// aggregations, and highlighting.
+//
+// To ensure consistency, and given that this rework is not available until 8.16,
+// `rrf` and `text_similarity_reranker` retriever queries would now
+// throw an exception in a mixed cluster scenario, where there are nodes
+// both in current or later (i.e. >= 8.16) and previous ( <= 8.15) versions.
+//
+// As part of the rework, we have also removed the `_rank` property from
+// the responses of an `rrf` retriever.
+//
+// *Impact* +
+// - Users will not be able to use the `rrf` and `text_similarity_reranker` retrievers in a mixed cluster scenario
+// with previous releases (i.e. prior to 8.16), and the request will throw an `IllegalArgumentException`.
+// - `_rank` has now been removed from the output of the `rrf` retrievers so trying to directly parse the field
+// will throw an exception
+// ====
+//
+// [[update_data_stream_lifecycle_telemetry_to_track_global_retention]]
+// .Update data stream lifecycle telemetry to track global retention
+// [%collapsible]
+// ====
+// *Details* +
+// In this release we introduced global retention settings that fulfil the following criteria:
+//
+// - a data stream managed by the data stream lifecycle,
+// - a data stream that is not an internal data stream.
+//
+// As a result, we defined different types of retention:
+//
+// - **data retention**: the retention configured on data stream level by the data stream user or owner
+// - **default global retention:** the retention configured by an admin on a cluster level and applied to any
+// data stream that doesn't have data retention and fulfils the criteria.
+// - **max global retention:** the retention configured by an admin to guard against having long retention periods.
+// Any data stream that fulfills the criteria will adhere to the data retention unless it exceeds the max retention,
+// in which case the max global retention applies.
+// - **effective retention:** the retention that applies on the data stream that fulfill the criteria at a given moment
+// in time. It takes into consideration all the retention above and resolves it to the retention that will take effect.
+//
+// Considering the above changes, having a field named `retention` in the usage API was confusing. For this reason, we
+// renamed it to `data_retention` and added telemetry about the other configurations too.
+//
+// *Impact* +
+// Users that use the field `data_lifecycle.retention` should use the `data_lifecycle.data_retention`
+// ====
+
+
+[discrete]
+[[deprecated-9.0]]
+=== Deprecations
+
+The following functionality has been deprecated in {es} 9.0
+and will be removed in a future version.
+While this won't have an immediate impact on your applications,
+we strongly encourage you to take the described steps to update your code
+after upgrading to 9.0.
+
+To find out if you are using any deprecated functionality,
+enable <>.
+//
+// [discrete]
+// [[deprecations_90_analysis]]
+// ==== Analysis deprecations
+//
+// [[deprecate_dutch_kp_lovins_stemmer_as_they_are_removed_in_lucene_10]]
+// .Deprecate dutch_kp and lovins stemmer as they are removed in Lucene 10
+// [%collapsible]
+// ====
+// *Details* +
+// kp, dutch_kp, dutchKp and lovins stemmers are deprecated and will be removed.
+//
+// *Impact* +
+// These stemmers will be removed and will be no longer supported.
+// ====
+//
+// [[deprecate_edge_ngram_side_parameter]]
+// .deprecate `edge_ngram` side parameter
+// [%collapsible]
+// ====
+// *Details* +
+// edge_ngram will no longer accept the side parameter.
+//
+// *Impact* +
+// Users will need to update any usage of edge_ngram token filter that utilizes `side`. If the `back` value was used, they can achieve the same behavior by using the `reverse` token filter.
+// ====
+//
+// [discrete]
+// [[deprecations_90_crud]]
+// ==== CRUD deprecations
+//
+// [[deprecate_dot_prefixed_indices_composable_template_index_patterns]]
+// .Deprecate dot-prefixed indices and composable template index patterns
+// [%collapsible]
+// ====
+// *Details* +
+// Indices beginning with a dot '.' are reserved for system and internal indices, and should not be used by and end-user. Additionally, composable index templates that contain patterns for dot-prefixed indices should also be avoided, as these patterns are meant for internal use only. In a future Elasticsearch version, creation of these dot-prefixed indices will no longer be allowed.
+//
+// *Impact* +
+// Requests performing an action that would create an index beginning with a dot (indexing a document, manual creation, reindex), or creating an index template with index patterns beginning with a dot, will contain a deprecation header warning about dot-prefixed indices in the response.
+// ====
+//
+// [discrete]
+// [[deprecations_90_rest_api]]
+// ==== REST API deprecations
+//
+// [[adding_deprecation_warnings_for_rrf_using_rank_sub_searches]]
+// .Adding deprecation warnings for rrf using rank and `sub_searches`
+// [%collapsible]
+// ====
+// *Details* +
+// Search API parameter `sub_searches` will no longer be a supported and will be removed in future releases. Similarly, `rrf` can only be used through the specified `retriever` and no longer though the `rank` parameter
+//
+// *Impact* +
+// Requests specifying rrf through `rank` and/or `sub_searches` elements will be disallowed in a future version. Users should instead utilize the new `retriever` parameter.
+// ====
+//
+// [[deprecate_legacy_params_from_range_query]]
+// .Deprecate legacy params from range query
+// [%collapsible]
+// ====
+// *Details* +
+// Range query will not longer accept `to`, `from`, `include_lower`, and `include_upper` parameters.
+//
+// *Impact* +
+// Instead use `gt`, `gte`, `lt` and `lte` parameters.
+// ====
+//
+// [[inference_api_deprecate_elser_service]]
+// .[Inference API] Deprecate elser service
+// [%collapsible]
+// ====
+// *Details* +
+// The `elser` service of the inference API will be removed in an upcoming release. Please use the elasticsearch service instead.
+//
+// *Impact* +
+// In the current version there is no impact. In a future version, users of the `elser` service will no longer be able to use it, and will be required to use the `elasticsearch` service to access elser through the inference API.
+// ====
+
+// BELOW WAS MANUALLY ADDED TO FIX THE BUILD
+include::migrate_9_0/transient-settings-migration-guide.asciidoc[]
+//include::migrate_9_0/rest-api-changes.asciidoc[] //see ES-9932
diff --git a/docs/reference/migration/migrate_9_0/rest-api-changes.asciidoc b/docs/reference/migration/migrate_9_0/rest-api-changes.asciidoc
new file mode 100644
index 0000000000000..fc6fc7c011a22
--- /dev/null
+++ b/docs/reference/migration/migrate_9_0/rest-api-changes.asciidoc
@@ -0,0 +1,5 @@
+[discrete]
+[[migrate_rest_api_changes]]
+=== REST API changes
+
+//See https://www.elastic.co/guide/en/elasticsearch/reference/8.0/migrating-8.0.html#breaking_80_rest_api_changes for formatting examples
diff --git a/docs/reference/migration/transient-settings-migration-guide.asciidoc b/docs/reference/migration/migrate_9_0/transient-settings-migration-guide.asciidoc
similarity index 100%
rename from docs/reference/migration/transient-settings-migration-guide.asciidoc
rename to docs/reference/migration/migrate_9_0/transient-settings-migration-guide.asciidoc
diff --git a/docs/reference/ml/anomaly-detection/apis/get-job.asciidoc b/docs/reference/ml/anomaly-detection/apis/get-job.asciidoc
index 4ee6c429ce730..33692fd182fa7 100644
--- a/docs/reference/ml/anomaly-detection/apis/get-job.asciidoc
+++ b/docs/reference/ml/anomaly-detection/apis/get-job.asciidoc
@@ -209,7 +209,7 @@ value.
(string) Reserved for future use, currently set to `anomaly_detector`.
`job_version`::
-(string) The {ml} configuration version number at which the the job was created.
+(string) The {ml} configuration version number at which the job was created.
NOTE: From {es} 8.10.0, a new version number is used to
track the configuration and state changes in the {ml} plugin. This new
diff --git a/docs/reference/release-notes.asciidoc b/docs/reference/release-notes.asciidoc
index c912b0e62b94d..615e7135365cd 100644
--- a/docs/reference/release-notes.asciidoc
+++ b/docs/reference/release-notes.asciidoc
@@ -6,135 +6,9 @@
This section summarizes the changes in each release.
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <>
-* <