· 部署插件
Istio部署插件需要根据需要的场景，考虑采用的插件完整性，例如prometheus，kiali，是否开启TLS等，具体安装选项可以参考https://preliminary.istio.io/zh/docs/reference/config/installation-options/。
· 跨集群部署
依据容器环境考虑是否需要支持Isito的跨集群部署方案.
6. 服务注入
服务注入用于将容器化的服务接入到Service Mesh的平台中，目前主要有两种方式。以Isito为例说明，主要包括自动注入和手动入住。选择手动注入的目的在于可以根据企业内部上线流程，对服务接入进行人为控制。而自动注入则能够更加快捷，方便。到此实际上已经完成服务迁移工作。
7. 服务管理控制台
由于Service Mesh目前而言，多是基于声明式的配置文件，达到服务治理的效果，因此无法实时传递执行结果。基于这种原因，需要一个独立的Service Mesh的管理控制台，一方面能够查看各个服务的运行状态以及策略执行情况，另外一方面能够支持服务运行过程中策略的动态配置管理。目前而言，可以在Isito安装过程中选择kiali作为一个控制台实现，当然未来也会有大量的企业提供专门的服务。
通过以上七个步骤，能够在一定程度上帮助企业应用，从Spring Cloud迁移到Service Mesh上，但迁移过程中必然存在不断踩坑的过程，需要根据应用特点，事前做好评估规划。
三、迁移优缺点分析
Spring Cloud迁移到Service Mesh是不是百利而无一害呢？
首先，从容器化的环境出发，后续Knative，Kubernetes，Service Mesh必然会构建出一套相对完整的容器化PaaS解决方案，从而完成容器化PaaS支撑平台的构建。Service Mesh将为容器运行态提供保驾护航的作用。
其次，就目前Service Mesh的落地实现而言，对于一些特定需求的监测粒度有所欠缺，例如调用线程栈的监测（当然，从网络层考虑，或者不在Service Mesh的考虑范围之内），但是恰恰在很多服务治理场景的要求范围之中。我们也需要针对这种情况，考虑实现方案。
最后，大家一直诟病的性能和安全问题。目前已经有所加强，但是依然被吐槽。
整体而言，Spring Cloud是微服务实现服务治理平台的现状，而Service Mesh却是未来，当然也不能完全取而代之，毕竟设计思路和侧重点不同，是否迁移需要根据业务场景而定。