在运行时之间迁移工作负载

将新启动发送到目标，同时让现有运行在来源端完成。本流程适用于独立的服务模式运行时。历史导出用于保存证据，不能传输由 Server 创建的活动运行。受支持的 embedded v2 导入只接受符合条件的 embedded 来源。

选择目标

迁移方向	目标准备
自托管 Server 到另一个自托管 Server	为目标部署独立的权威数据库、载荷存储和凭据。遵循部署指南。
自托管 Server 到 Cloud	配置目标命名空间，验证返回的运行时 URL、凭据和能力。遵循 Cloud 配置指南。
Cloud 到自托管 Server	更改应用流量前，准备好自托管目标及其 SDK worker。在来源运行完成之前，保留已配置的 Cloud 来源。

准备两个运行时

记录每个来源端点、命名空间、工作流实例 ID、运行 ID、任务队列、工作流与活动类型，以及载荷存储依赖。为自托管存储保留经过测试的恢复路径。从 Cloud 迁移不会授予数据库备份访问权限，也不会将 Cloud 凭据复制到目标。验证目标的实际版本和能力、角色凭据、worker 注册及其声明的类型。

按小组切换新启动

1. 在来源旁运行目标及其 worker。完成一个具有唯一标识的金丝雀运行，覆盖有代表性的活动与结果，并将其副作用与真实业务隔离。
2. 盘点所有启动来源：应用调用、计划、webhook/bridge 适配器和服务调用。为一个工作流系列选择切换点。协调暂停来源计划及在目标注册计划，避免两个运行时启动同一次计划触发。
3. 将该系列的新启动路由到目标。由应用记录接受每个工作流的端点和命名空间。在另一个运行时重用业务键不会提供跨运行时去重。
4. 继续将信号、审批、更新、查询、取消、结果及历史读取发送到拥有该运行的运行时。保留来源 worker、队列、定时器、凭据和载荷访问。更改客户端 URL 不会移动已接受的工作或其活动租约。
5. 迁移下一个系列前，检查结果和失败。如果传输问题导致启动结果不确定，应先在原运行时查明结果，再向其他运行时提交。永远不进入终态的长期运行尚未排空。

停用前保存证据

导出需要保留的历史，包括所有必需的延续运行、原始载荷字节和编解码器。使用兼容的消费端检查完整性与一致性，并保留准确的生成端身份。历史导出与重放指南说明了各项独立检查。审计导出不会使 Server 来源运行具备活动状态导入资格。

检查实际提供导出的生成端。仅发布 Core 2.11.4 并不能证明 Server、随附 CLI、SDK HTTP 或 Cloud 导出已通过验证。请跟进独立的 Server HTTP 生成端与镜像验证。旧的有损数据包仍然无效。不得修改数值或校验和来强行接受；必需证据不可用或无法验证时，不要销毁权威来源。

最后停用来源

检查所有相关命名空间及列表的全部页面，确认没有来源拥有的非终态运行。包括等待中的父子运行，以及剩余启动来源创建的运行。端点健康、第一页为空或指标不可用，都不能证明没有未完成工作。确认调用方、回调和 worker 不再依赖来源，且必需的归档可读。

之后才能停用自托管资源或解除 Cloud 运行时配置。只要 Cloud 仍处于已配置状态，容量费用就会继续，包括空闲和排空期间。解除配置会删除活动运行时数据和凭据，并非暂停后恢复。应使用现有套餐返回的计费条款；本流程不产生自动退款或计费例外。

回滚路由而不移动运行

仅将未来的新启动切回健康且兼容的来源。目标已经接受的运行仍归目标所有，在终态之前需要目标 worker 及命令路由。保留两边的归属记录并防止重复启动。不要用旧来源存储覆盖较新的已接受状态，也不要恢复同一运行的第二个活动副本。