Merge branch 'main' into update-synthetics-docker

Author: mdbirnstiehl

manage-data/ingest/transform-enrich/readable-maintainable-ingest-pipelines.md

@@ -1,4 +1,3 @@
-
 ---
 mapped_pages:
   - https://www.elastic.co/docs/manage-data/ingest/transform-enrich/common-mistakes.html

manage-data/migrate/migrate-data-between-elasticsearch-clusters-with-minimal-downtime.md

@@ -48,11 +48,11 @@ Tp complete the migration with minimal downtime, use incremental snapshots. Whil
 
 1. **09:00**: Take the initial full snapshot of the old cluster. You can also take the initial full snapshot the day before.
 2. **09:30**: Restore the snapshot to the new cluster.
-3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes.
+3. **09:55**: Take another snapshot of the old cluster and restore it to the new cluster. Repeat this process until the snapshot and restore operations take only a few seconds or minutes. Remember that when restoring indices that _already_ exist in the new cluster (for example, to pull in recently copied data), they first need to be [closed](/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md#considerations). Also, remember that the restore operation automatically opens indices, so you will likely need to close the actively written ones after restoring them.
 4. **10:15**: Perform the final cutover.
     1. In the old cluster, pause indexing or set indices to read-only. For details on setting indices to read-only to safely pause indexing during migration, check [Index lifecycle actions: Read-only](elasticsearch://reference/elasticsearch/index-lifecycle-actions/ilm-readonly.md).
     2. Take a final snapshot. 
-    3. Restore the snapshot to the new cluster. 
+    3. Restore the snapshot to the new cluster. Again, remember that to restore indices that already exist, they first need to be closed.
     4. Change ingestion and querying to the new cluster. 
     5. Open the indices in the new cluster. 
 

release-notes/elastic-cloud-serverless/known-issues.md

@@ -51,7 +51,7 @@ After you complete this step, risk scores should automatically begin to successf
 
 ## Resolved
 
-:::{dropdown} In {{sec-serverless}}, installing an {{elastic-defend}} integration or a new agent policy upgrades installed prebuilt rules, reverting user customizations and overwriting user-added actions and exceptions
+:::{dropdown} Installing the {{elastic-defend}} integration or a new agent policy in {{sec-serverless}} forces an upgrade of prebuilt rules
 
 On April 10, 2025, it was discovered that when you install a new {{elastic-defend}} integration or agent policy, the installed prebuilt detection rules upgrade to their latest versions (if any new versions are available). The upgraded rules lose any user-added rule actions, exceptions, and customizations.