6R 是什么
6R 是云迁移的策略分类模型：Rehost（原样搬迁）、Replatform（少量适配）、Repurchase（采购替代）、Refactor（重构）、Retire（退役）、Retain（保留）。它的作用是让迁移范围与投入产出对齐——把所有系统都按重构推进会让周期与预算失控，而忽略退役与保留则会把本不该搬的系统也搬上云，甚至把长期无访问的系统一起迁走。
基本信息
| 策略数量 | 6 种，从改动最小到改动最大依次递增 |
|---|---|
| 常见分布 | Rehost 占比通常最高，重构类占比最小 |
| 决策依据 | 业务价值、改造意愿、停机容忍、合规要求 |
| 输出 | 分批路线图、资源投入与批次划分 |
| 复盘节点 | 每批完成后再评估下一批系统的策略 |
典型使用场景
- 迁移立项时给每套系统定策略，避免一刀切
- 向管理层解释不同策略的周期与成本差异
- 识别应退役的系统，减少迁移工作量
- 识别有强硬件或合规依赖、需要暂缓的系统
- 为重构类系统单独规划预算与团队
6R 策略
| 策略 | 说明 | 典型动作 |
|---|---|---|
| Rehost | 原样搬迁 | 迁到云主机，基本不改动 |
| Replatform | 少量适配 | 换托管数据库或对象存储 |
| Repurchase | 采购替代 | 改用 SaaS 服务 |
| Refactor | 重构 | 云原生改造，周期较长 |
| Retire | 退役 | 下线无维护价值的系统 |
| Retain | 保留 | 暂不迁移，保持现状 |
决策维度
| 维度 | 影响什么 | 举例 |
|---|---|---|
| 业务价值 | 决定是否值得投入改造 | 核心交易系统优先考虑重构或再平台 |
| 技术债程度 | 决定改造成本 | 代码老旧且缺少测试的系统先原样搬迁 |
| 停机容忍度 | 决定搬迁方式 | 可停机业务用离线迁移，在线业务做热迁移 |
| 合规与数据驻留 | 决定必须保留的范围 | 数据出境受限的系统留在原地或私有化 |
| 改造成本 | 决定投入产出比 | 用户量小的系统优先考虑采购替代 |
分类口径示例
分类口径示例
Rehost：无源码或暂不改动的业务系统
Replatform：可改配置不改代码的中间件/数据库
Retire：长期无访问、无合规留存要求的系统
Retain：本地强依赖硬件或监管要求暂缓的系统6R 是分类框架而不是执行顺序：实践中通常先做一批 Rehost 快速见效，再对高价值系统投入 Replatform 与 Refactor，节奏要按团队产能安排。
Retire 需要业务与合规共同确认：只凭技术团队判断容易把仍在归档使用或受监管约束的系统下线，风险不可逆。