开发者已使用了第三方云服务，考虑到融云即时通讯云平台系统稳定、产品线丰富、功能高度可控可订制，希望迁移到融云平台，可详细阅读以下迁移方案。
一、迁移条件
第三方云服务支持并开通服务端消息路由功能(用户 A 给用户 B 发消息的过程中，服务器支持通过 Callback 或者 WebHook 的模式将消息转发给开发者提供的服务器 URL 地址)。
二、消息架构模型
实现即时通讯平台架构迁移的核心逻辑是实现新旧有即时通讯系统消息互通。假设旧 App 端为 A，新 App 端为 B，旧有即时通讯服务为 IM_Old，新即时通讯服务为 IM_New，那么 A 发给 B 的消息要先通过 IM_Old 服务发送给 IM_New，再由 IM_New 服务送达 B，反之亦然。
实际架构上，需要中间开发部署一个消息流转适配器负责 IM_Old 和 IM_New 之间的消息转发和适配。
消息收发流程
迁移过程中，新 App 同旧 App 之间的消息收发流程如下：
架构所需的 4 个接口:
1、旧有即时通讯平台的消息路由接口：用来将旧有系统中的消息发送到消息流转适配器中。
2、旧有即时通讯平台的消息发送接口：用来从消息流转适配器中发送来自融云系统的消息。
3、融云即时通讯平台的消息路由接口：用来将融云系统中的消息发送到消息流转适配器中，查看消息路由服务文档。
4、融云即时通讯平台的消息发送接口：用来从消息流转适配器中发送来自旧有系统的消息，查看消息发送服务文档。
三、迁移实施过程
1、新版 App 按照正常流程集成融云 SDK，服务端也接入融云的相关服务。
2、向旧有即时通讯云服务商申请开启消息路由服务（将消息实时同步到自己应用服务器的功能）。
3、在融云申请开启消息路由服务，详细可参见服务端实时消息路由开通方式。
4、开发者实现消息流转适配器服务，期间可以根据业务需要添加消息筛选或者转换逻辑。
5、开发者自己的服务器上部署消息流转适配器服务。
四、注意事项
用户系统
融云的用户系统采用增量激活的方式，所以您不用考虑一次性用户激活的问题，融云有能力承载您的业务上线时带来的用户激活压力。
好友关系
融云不保存客户的好友关系，所以不用考虑好友关系迁移事宜。
群组关系
为了实现群聊，需要向融云同步群组关系，上线前建议一次性调用融云服务端 API 进行一次初始化同步，上线后按照正常逻辑执行即可。详细请查看 Server 同步用户所属群组方法。
语音消息模型与编码
不同的即时通讯云服务可能采用不同的消息编码方案，在消息流转适配器中，需要将接收方和发送方的消息内容进行适当的转换。
查看融云的语音消息结构。
图片消息模型
不同的即时通讯云服务可能采用不同的消息编码方案，在消息流转适配器中，需要将接收方和发送方的消息内容进行适当的转换。
查看融云的图片消息结构。
Push 缺失用户信息的问题
因为融云侧没有旧有即时通讯平台的注册用户信息，所以当 B 用户(融云平台注册的)收到来自 A 用户(旧有即时通讯平台)发来的消息时，Push 信息中无法显示用户名。
应对方法是在消息流转适配器中调用融云发送消息代码时，自行组织 pushContent 字段，在 pushContent 字段中显示出用户信息，如：“小明：发送了一条消息。”，相关文档请参考发送单聊消息方法。
五、客户端升级
客户端升级逻辑
安装新版融云客户端后，需要 App 在第一次运行时，将原有第三方 IM 数据(会话+消息)导入到融云 IM SDK 内嵌数据库。
融云的工作
融云提供融云 SDK 内嵌数据库 Schema。
App 的工作
由 App 负责集成融云提供的数据库升级代码。
六、其他问题
可能存在 App 升级时未正常注销导致仍然推送消息不正确的情况(通过消息流转适配器服务记录用户迁移状态可以解决)。
通过消息流转适配器服务记录用户迁移状态，可以实现更节约资源的路由方案(有些用户已经迁移就不用再发消息了)。
