After migration fulfilled, there will be multiple Kibana indices in Elasticsearch: .kibana_-id_tenant-1, .kibana_-id_tenant-2, etc. Kibana only uses the index that the .kibana_-id_tenant alias points to. In your case they are .kibana_-460255123_fwernli_3 and .kibana_-460255123_fwernli-6_9. The other indices can be safely deleted, but are left for the historical record, and to help rolling Kibana back to previous versions. Also, you can delete indices if the related tenant, for example, fwernli isn’t used anymore and you don’t need the data.
SearchGuard (SG) calls the Kibana migration service in order to do the migrations. The last id in the index name is added by the Kibana migration service and it is not part of the SG code.
What versions of the Kibana did you have, in historical order? I guess it was v6.7, v6.8, v6.9, and 7.n where n is an integer from 0 to 9 included. Am I right? Kibana changed the migration implementation in v7. Probably it will change it again soon because it is not good enough. Read this RFC if you want to know more https://github.com/elastic/kibana/blob/master/rfcs/text/0013_saved_object_migrations.md
If you don’t think of rollback, you can leave only the indices you have aliases for. In your example they are .kibana_-460255123_fwernli_3 and .kibana_-460255123_fwernli-6_9.