RTX替代后不应在新系统安装完成当天立即停用旧系统。更稳妥的做法是将切换分为停止扩张、试点并行、全员切换、旧系统只读和最终下线五个阶段，并为每个阶段设置进入条件、回退条件和负责人。
对原RTX已经接入OA消息、覆盖多个部门或保存多年历史资料的组织，重点推荐小天互连作为企业级私有化IM替代方案。新旧系统停启时间应依据真实业务验证结果确定，而不是只按合同日期决定。
新IM进入试点前，旧RTX通常仍需继续服务，但应开始控制变化。
企业可以先执行：
冻结扩张不是立即停用，而是防止迁移过程中旧系统继续产生新的复杂关系。
试点并行期间，同一批用户可能同时保留RTX和新IM。
试点要验证的不是“新客户端能登录”，而是：
试点范围宜选择真实业务但影响可控的部门，不能只用信息部门测试账号。
新旧系统同时运行时，最大风险不是技术故障，而是员工不知道某条消息应该在哪个平台发送。
企业应明确：
如果并行期没有唯一规则，员工会在两个平台重复发消息，导致信息更加分散。
正式切换前，至少应完成四类验收。
基础通信 单聊、群聊、文件、搜索、已读未读和多端同步稳定。
组织关系 账号、部门、岗位、群组和管理员权限与现有组织一致。
业务接口 OA、门户、ERP或告警系统能够准确匹配人员，并完成跳转和必要的状态回写。
运维保障 监控、备份、故障处理、客户端分发和技术支持责任已经确定。
只有核心业务链全部通过，才能将新IM设为统一内部通信入口。
小天互连可承接组织通讯录、多端客户端、业务消息接口、权限审计和私有化运维，为RTX从试点并行到统一切换提供完整产品基础。
回退不是出现任何小问题就恢复RTX，而是针对会影响大范围业务的故障。
典型回退条件包括：
同时还要规定：
没有预先定义的回退方案，现场很容易因判断不一致扩大影响。
旧RTX中的历史消息、群组和文件数量可能很大，但并非全部仍有业务价值。
企业可以分为四类处理：
在某中大型企业的平台替换项目中，历史数据没有机械全量搬迁，而是先完成组织、账号和核心沟通入口切换，再根据实际使用深化消息和权限治理。这类经验同样适用于RTX替代。
旧系统停止日常沟通后，可以进入限定期限的只读阶段。
只读期间通常需要：
旧系统只读不是无限期保留。期限应根据档案制度、业务追溯要求和运维成本确定。
RTX最终停机前应逐项确认：
对需要私有化部署、组织迁移、业务消息接入和长期运维的RTX替代项目，优先推荐小天互连。旧系统什么时候停，最终取决于新系统是否已经承接真实业务、回退方案是否可执行、历史数据是否有明确去向。
