求跨集群迁移数据的方案

现在在做集群拆分的工作，一个集群有几十个索引，想按部门按业务进行拆分。拆分的目的就是不希望一个业务线的失误影响其他业务线。
 
架构模型是这样：
 
业务线 -> 我的服务 -> es集群（2.2）
 
目前服务层是按照部门拆分了，但是集群还在用一个，毕竟机器资源太多了。
 
我之前想的方案虽然逻辑上可行，但是需要配合的人太多了。例如：
 
1.先搭建新集群，按照老集群的索引meta在新集群创建对应的索引。
2.把数据导出一份到新集群（scroll+bulkIndex）
3,写服务双写集群
4.维持大约一个星期后，部署新的服务指向新集群地址，让迁移走的索引的业务方修改服务地址到新的服务地址。
 
但是上述方案也存在一些问题和难以实施的点：
1索引用法各异，有的不关注数据一致性，有的又特别要求数据一致性。所以前期可能会小范围影响部分业务，后期需要联合诸多业务线补数据
2.后两步双写改造成本较高，服务有老接口有新接口，每个接口都要做成双写，这个还有，关键是双写不确定什么时候下掉合适，又需要部分业务线验证数据一致性，而且如果先切服务再下双写，担心间隙的修改无法同步，或出现错位老修改覆盖新修改等问题。
 
 
其实简单来说就是历史包袱比较重，而且这次升级如果想换新版本集群，又是一个成本，跨大版本意味着我服务api可能要有改造。
 
 
我有一个想法，就是通过扩容的方式把要迁移出去的索引分片拿到新的机器上，但是这些机器还在一个集群中，只是查询的时候只走新集群的分片所在机器，应该也是一种伪拆分的方案，毕竟这种方案是成本最低的，半个小时就处理好了。
 
不知道大佬们有什么建议吗。