add explicit headers

Author: Blargian

docs/use-cases/observability/clickstack/migration/elastic/migrating-data.md

@@ -1,5 +1,5 @@
 
-## Parallel operation strategy 
+## Parallel operation strategy {#parallel-operation-strategy}
 
 When migrating from Elastic to ClickStack for observability use cases, we recommend a **parallel operation** approach rather than attempting to migrate historical data. This strategy offers several advantages:
 
@@ -11,7 +11,7 @@ When migrating from Elastic to ClickStack for observability use cases, we recomm
 We demonstrate an approach for migrating essential data from Elasticsearch to ClickHouse in the section ["Migrating data"](#migrating-data). This should not be used for larger datasets as it is rarely performant - limited by the ability for Elasticsearch to export efficiently, with only JSON format supported.
 :::
 
-### Implementation steps 
+### Implementation steps {#implementation-steps}
 
 1. **Configure Dual Ingestion**
 <br/>
@@ -35,27 +35,27 @@ Configure Elastic's TTL settings to match your desired retention period. Set up
 - As data naturally expires from Elastic, users will increasingly rely on ClickStack
 - Once confidence in ClickStack is established, you can begin redirecting queries and dashboards
 
-### Long-term retention 
+### Long-term retention {#long-term-retention}
 
 For organizations requiring longer retention periods:
 
 - Continue running both systems in parallel until all data has expired from Elastic
 - ClickStack [tiered storage](/engines/table-engines/mergetree-family/mergetree#table_engine-mergetree-multiple-volumes) capabilities can help manage long-term data efficiently.
 - Consider using [materialized views](/materialized-view/incremental-materialized-view) to maintain aggregated or filtered historical data while allowing raw data to expire.
 
-### Migration timeline 
+### Migration timeline {#migration-timeline}
 
 The migration timeline will depend on your data retention requirements:
 
 - **30-day retention**: Migration can be completed within a month.
 - **Longer retention**: Continue parallel operation until data expires from Elastic.
 - **Historical data**: If absolutely necessary, consider using [Migrating data](#migrating-data) to import specific historical data.
 
-## Migrating settings 
+## Migrating settings {#migration-settings}
 
 When migrating from Elastic to ClickStack, your indexing and storage settings will need to be adapted to fit ClickHouse's architecture. While Elasticsearch relies on horizontal scaling and sharding for performance and fault tolerance and thus has multiple shards by default, ClickHouse is optimized for vertical scaling and typically performs best with fewer shards.
 
-### Recommended settings  
+### Recommended settings {#recommended-settings}
 
 We recommend starting with a **single shard** and scaling vertically. This configuration is suitable for most observability workloads and simplifies both management and query performance tuning.
 
@@ -67,7 +67,7 @@ We recommend starting with a **single shard** and scaling vertically. This confi
   - Using [`ReplicatedMergeTree`](/engines/table-engines/mergetree-family/replication) if high availability is required
   - For fault tolerance, [1 replica of your shard](/engines/table-engines/mergetree-family/replication) is typically sufficient in Observability workloads.
 
-### When to shard 
+### When to shard {#when-to-shard}
 
 Sharding may be necessary if:
 
@@ -77,7 +77,7 @@ Sharding may be necessary if:
 
 If you do need to shard, refer to [Horizontal scaling](/architecture/horizontal-scaling) for guidance on shard keys and distributed table setup.
 
-### Retention and TTL 
+### Retention and TTL {#retention-and-ttl}
 
 ClickHouse uses [TTL clauses](/use-cases/observability/clickstack/production#configure-ttl) on MergeTree tables to manage data expiration. TTL policies can:
 
@@ -87,7 +87,7 @@ ClickHouse uses [TTL clauses](/use-cases/observability/clickstack/production#con
 
 We recommend aligning your ClickHouse TTL configuration with your existing Elastic retention policies to maintain a consistent data lifecycle during the migration. For examples, see [ClickStack production TTL setup](/use-cases/observability/clickstack/production#configure-ttl).
 
-## Migrating data 
+## Migrating data {#migrating-data}
 
 While we recommend parallel operation for most observability data, there are specific cases where direct data migration from Elasticsearch to ClickHouse may be necessary:
 
@@ -101,7 +101,7 @@ The following steps allow the migration of a single Elasticsearch index from Cli
 
 <VerticalStepper headerLevel="h3">
 
-### Migrate schema 
+### Migrate schema {#migrate-scheme}
 
 Create a table in ClickHouse for the index being migrated from Elasticsearch. Users can map [Elasticsearch types to their ClickHouse](/use-cases/observability/clickstack/migration/elastic/types) equivalent. Alternatively, users can simply rely on the JSON data type in ClickHouse, which will dynamically create columns of the appropriate type as data is inserted.
 
@@ -556,11 +556,11 @@ npm install elasticdump -g
 
 Where possible, we recommend running both ClickHouse, Elasticsearch, and `elastic dump` in the same availability zone or data center to minimize network egress and maximize throughput.
 
-### Install ClickHouse client 
+### Install ClickHouse client {#install-clickhouse-client}
 
 Ensure ClickHouse is [installed on the server](/install) on which `elasticdump` is located. **Do not start a ClickHouse server** - these steps only require the client.
 
-### Stream data 
+### Stream data {#stream-data}
 
 To stream data between Elasticsearch and ClickHouse, use the `elasticdump` command - piping the output directly to the ClickHouse client. The following inserts the data into our well structured table `logs_system_syslog`.
 
@@ -610,7 +610,7 @@ clickhouse-client --host ${CLICKHOUSE_HOST} --secure --password ${CLICKHOUSE_PAS
 See ["Reading JSON as an object"](/integrations/data-formats/json/other-formats#reading-json-as-an-object) for further details.
 :::
 
-### Transform data (optional) 
+### Transform data (optional) {#transform-data}
 
 The above commands assume a 1:1 mapping of Elasticsearch fields to ClickHouse columns. Users often need to filter and transform Elasticsearch data before insertion into ClickHouse.