[courtewing]

If it helps at all, Kibana also had to be updated to go from multiple types to a single type. It was a big project, and a bunch of approaches were explored for dealing with existing data (which I assume you are).

Ultimately, we settled on continuing to have different "types" in Kibana, but we treated them as data concerns rather than architectural concerns of Elasticsearch. At a high level, this meant that we added a new "type" field to documents to track the type itself, and then we prefixed fields with the type as well to preserve the ability to use the same userland id on different "types" in the index and such. The type/id prefixing thing doesn't get exposed beyond the layer that queries Elasticsearch for the kibana index.

Once that change was ready in the code, we also had to consider the need for users to migrate their existing multiple-type index to this new format. The upgrade assistant in x-pack basic handles all of this automatically, but folks can certainly repurpose the same reindexing operation we perform on .kibana on your own indices.

The underlying steps and reindex operation for this are outlined on the docs: https://www.elastic.co/guide/en/kibana/current/migrating-6.0...

The actual data transformation happens in step 3.

I hope this helps!