# Mapping type issues regarding migration from 1.6.0 to 2.2.0

**URL:** <https://discuss.elastic.co/t/mapping-type-issues-regarding-migration-from-1-6-0-to-2-2-0/44689>\
**Category:** Elasticsearch\
**Created:** [March 17, 2016, 10:18am UTC](https://discuss.elastic.co/t/mapping-type-issues-regarding-migration-from-1-6-0-to-2-2-0/44689 "2016-03-17T10:18:26Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![cto](https://avatars.discourse-cdn.com/v4/letter/c/5daacb/32.png) [@cto](https://discuss.elastic.co/u/cto)\
**Post date:** [March 17, 2016, 10:18am UTC](https://discuss.elastic.co/t/mapping-type-issues-regarding-migration-from-1-6-0-to-2-2-0/44689/1 "2016-03-17T10:18:26Z")

</div>

Hi,

We have an application where we are storing various device data in Elasticsearch 1.6 for our production environment.

For our system, we have a different type for all the devices in the system. A sample of the mapping is as follows

**Sample 1:**  
{  
"device1": {  
"properties": {  
"attribute": {  
"properties": {  
"speed": {  
"type": "long"  
},  
//.......  
//......

**Sample 2:**  
{  
"device2": {  
"properties": {  
"attribute": {  
"properties": {  
"speed": {  
"type": "string"  
},  
//.......  
//......

Our system is very generic and we do not control the "attribute" type.  
But this is creating a huge issue for the migration as different type mapping is no longer allowed. We have huge production data and we are just not able to migrate those data.😞

Please suggest some way in which we can go ahead with the migration.  
Thanks in advance!

---

<div class="post-metadata">

**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\
**Post date:** [March 17, 2016, 10:38am UTC](https://discuss.elastic.co/t/mapping-type-issues-regarding-migration-from-1-6-0-to-2-2-0/44689/2 "2016-03-17T10:38:28Z")

</div>

Migrating to Elasticsearch 2.x will unfortunately require you to change this and reindex the data.

One way to allow flexible attributes without having mapping conflicts is to introduce a naming convention, which indicates the type of the field. This can e.g. be done through a suffix, e.g. 'speed\_i' is indexed as an integer and 'speed\_s' as an unanalysed string. This can naturally be extended into other data types. This relies on dynamic mappings and generally requires a default treatment, e.g. unanalysed string mapping, for all fields that do not follow the naming convention.

---

<div class="post-metadata">

**Author:** ![cto](https://avatars.discourse-cdn.com/v4/letter/c/5daacb/32.png) [@cto](https://discuss.elastic.co/u/cto)\
**Post date:** [March 17, 2016, 10:59am UTC](https://discuss.elastic.co/t/mapping-type-issues-regarding-migration-from-1-6-0-to-2-2-0/44689/3 "2016-03-17T10:59:03Z")

</div>

Thanks a lot for the reply 🙂

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 5, 2017, 11:07pm UTC](https://discuss.elastic.co/t/mapping-type-issues-regarding-migration-from-1-6-0-to-2-2-0/44689/4 "2017-07-05T23:07:36Z")

</div>


