# Migrating from Elastic NEST v7 to .NET Elastic Client v8: Index alias search

**URL:** https://discuss.elastic.co/t/migrating-from-elastic-nest-v7-to-net-elastic-client-v8-index-alias-search/383574
**Category:** Elasticsearch
**Tags:** language-clients
**Created:** [November 21, 2025, 12:17am UTC](https://discuss.elastic.co/t/migrating-from-elastic-nest-v7-to-net-elastic-client-v8-index-alias-search/383574 "2025-11-21T00:17:42Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![zoey\_L](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/zoey_l/32/145829_2.png) [@zoey\_L](https://discuss.elastic.co/u/zoey_L)
#### Post date: [November 21, 2025, 12:17am UTC](https://discuss.elastic.co/t/migrating-from-elastic-nest-v7-to-net-elastic-client-v8-index-alias-search/383574/1 "2025-11-21T00:17:42Z")

</div>

while migrating .net package from NEST to Elastic.Clients.Elasticsearch. Observed one issue of double search indexes if they have the same alias.

We have a time rollover index created once a week. every week, there will be a new index created with new date. (new index is in hot phase and old index moves to cold phase staying for a week). but both index will have the same alias name.

When used the NEST package, the query always hit the latest index and return the proper count and aggregation buckets.  
after migrating to the new ES .net package, the same query returns double count. (old + new)  
Confirming it by manually deleting old index, the query returns correct match count).

Any suggestions for this issue?

---

<div class="post-metadata">

### Author: ![flobernd](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/flobernd/32/124877_2.png) [@flobernd](https://discuss.elastic.co/u/flobernd)
#### Post date: [November 21, 2025, 8:30am UTC](https://discuss.elastic.co/t/migrating-from-elastic-nest-v7-to-net-elastic-client-v8-index-alias-search/383574/2 "2025-11-21T08:30:38Z")

</div>

Hi @zoey_L , do you use `DefaultIndex` or type-to-index mappings with the new client?

I assume the issue happens with the `Search()` endpoint?

Could you please try to explicitly set `Indices("my_index")` for this call and test again?

---

<div class="post-metadata">

### Author: ![zoey\_L](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/zoey_l/32/145829_2.png) [@zoey\_L](https://discuss.elastic.co/u/zoey_L)
#### Post date: [November 21, 2025, 1:48pm UTC](https://discuss.elastic.co/t/migrating-from-elastic-nest-v7-to-net-elastic-client-v8-index-alias-search/383574/3 "2025-11-21T13:48:17Z")

</div>

hi @flobernd thank you for the reply! yes! I was using `DefaultIndex` in the client setting:  
```  
`var settings = new ElasticsearchClientSettings(new Uri(url))`  
` .DefaultIndex(defaultIndex)`  
` .EnableDebugMode()`  
` .Authentication(new BasicAuthentication(username, password));`  
```  
I tested with your suggestions by using .Indices() in the query and it works! can you explain the issue more? and is there any alternative way to use `DefaultIndex` config to fix the issue rather than explicitly passing index names in all queries?

---

<div class="post-metadata">

### Author: ![flobernd](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/flobernd/32/124877_2.png) [@flobernd](https://discuss.elastic.co/u/flobernd)
#### Post date: [November 21, 2025, 3:55pm UTC](https://discuss.elastic.co/t/migrating-from-elastic-nest-v7-to-net-elastic-client-v8-index-alias-search/383574/4 "2025-11-21T15:55:09Z")

</div>

Hi @zoey_L , yes this is tracked in this issue:

> <https://github.com/elastic/elasticsearch-net/issues/8215>
>
> \*\*Elastic.Clients.Elasticsearch version\*\*: 8.13.15
> 
> \*\*Elasticsearch version\*\*:… 8.13.2
> 
> \*\*.NET runtime version\*\*: .NET 6.0.28 and .NET Framework 4.8.9232.0
> 
> \*\*Operating system version\*\*: Windows 10 Pro
> 
> \*\*Description of the problem including expected versus actual behavior\*\*:
> 
> I set the DefaultIndex to "features" while configuring ElasticsearchClientSettings, but the request was sent without using this DefaultIndex.
> 
> searchResult.DebugInformation: \`Valid Elasticsearch response built from a successful (200) low-level call on POST: /\_search?typed\_keys=true\`.
> 
> similar to https://github.com/elastic/elasticsearch-net/issues/8151
> 
> \*\*Steps to reproduce\*\*:
> 
> \`\`\`
> var connectionSettings = new ElasticsearchClientSettings(settings.ReadonlyHost);
> connectionSettings.DefaultIndex("features");
> connectionSettings.RequestTimeout(TimeSpan.FromMinutes(1));
> connectionSettings.EnableHttpCompression();
> connectionSettings.Authentication(new BasicAuthentication(settings.Login, settings.Password));
>         
> var client = new ElasticsearchClient(connectionSettings);
>    
> var searchResult = await client.SearchAsync\<JsonElement\>(s =\> s
> .Aggregations(aggs =\> aggs.Add("ClassName", agg =\> agg.Terms(dh =\> dh.Field("ClassId").Size(100)))));
>             
> // or
> var searchRequest = new SearchRequest()
> {
> Size = 10,
> Query = new TermQuery(new Field("ClassId")) { Value = FieldValue.Long(75) }
> };
> 
> var searchResult2 = await client.SearchAsync\<JsonElement\>(searchRequest); 
> \`\`\`
> 
> \*\*Expected behavior\*\*
> I expect http request with index POST: \`features/\_search?typed\_keys=true\`

There was a breaking change in the behavior of APIs that accepts multiple indices. In NEST, `DefaultIndex` would override the default behavior (which is to query **all** indices) to just use the single `DefaultIndex`.

In the new client, this is no longer the case (only for APIs that accept a single index).

Since this seems to be confusing, I might revert that new behavior, but a final decision hasn’t been made so far.

---

<div class="post-metadata">

### Author: ![zoey\_L](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/zoey_l/32/145829_2.png) [@zoey\_L](https://discuss.elastic.co/u/zoey_L)
#### Post date: [November 21, 2025, 4:28pm UTC](https://discuss.elastic.co/t/migrating-from-elastic-nest-v7-to-net-elastic-client-v8-index-alias-search/383574/5 "2025-11-21T16:28:42Z")

</div>

Thanks for sharing this helpful info. It helps a lot. I believe the workaround for now is explicitly adding all index name in all queries. But if it can improve in the future, it helps a lot. I will let the teams know this breaking changes.
