3. 迁移策略与6R框架
6R框架是Google Cloud迁移方法论中用于“为每个应用选择迁移方式”的核心决策工具。它把迁移策略分为六类：Rehost（重新托管）、Replatform（平台重构）、Refactor（重构/重新架构）、Repurchase（重新采购）、Retire（退役）、Retain（保留）。理解6R的关键不是背定义，而是知道在什么条件下选哪一个，以及选择之后对成本、工期、风险和后续现代化空间意味着什么。
六个策略的本质差异
Rehost（重新托管，常称“平移”）：把应用原样搬到云端虚拟机，操作系统、中间件、应用代码基本不变。典型做法是用Migrate to Virtual Machines把VMware虚拟机直接复制到Compute Engine。优点是快、风险低、适合大规模批量迁移；缺点是只拿到基础设施弹性，拿不到云原生红利，长期运维成本可能偏高。适用场景：数据中心租约到期、需要快速退出机房、应用即将被替换但短期不能停、缺乏源码或原厂支持的老系统。
Replatform（平台重构，常称“平移并优化”）：保留应用核心代码，但把部分组件换成托管服务。例如把自建MySQL换成Cloud SQL，把自建Redis换成Memorystore，把本地文件存储换成Cloud Storage，把Tomcat集群换成Cloud Run。它不重写业务逻辑，只替换“运行底座”。收益是减少运维、提升可用性；代价是需要做兼容性验证和连接串、驱动、备份策略的调整。适用场景：应用仍要长期使用、团队运维负担重、数据库或中间件是主要痛点。
Refactor（重构/重新架构）：为云环境重新设计应用，通常涉及拆分单体、容器化、改为微服务、使用Pub/Sub做异步解耦、用BigQuery替换自建数据仓库。收益最大，能获得弹性伸缩、按需付费、快速迭代；但工期最长、成本最高、风险最大。适用场景：业务增长快、单体已成为瓶颈、需要高频发布、有明确现代化路线图且团队具备云原生能力。
Repurchase（重新采购）：放弃自建，改用SaaS替代，例如把自建CRM换成Salesforce，把自建邮件系统换成Google Workspace。它本质是“换产品”而非“搬系统”。适用场景：自建系统维护成本高、SaaS功能已覆盖需求、数据迁移和集成可控。
Retire（退役）：确认无人使用或功能已被替代，直接下线。迁移前做应用盘点时，常能发现10%～20%的“僵尸应用”。退役是最省钱、最省事的策略，但必须先确认无业务依赖、无合规留存要求。
Retain（保留）：暂时不迁，留在原环境或留在本地。原因可能是强依赖专用硬件、数据主权限制、刚完成重大升级、或迁移收益不明显。保留不是失败，而是有意识的暂缓，通常需要设定复查时间点。
决策方法：从应用画像到策略落点
实际项目中，6R不是凭感觉选，而是按一套可复用的判断顺序推进。建议按以下四步走。
第一步：先做应用盘点，建立应用画像。对每个应用记录：业务负责人、用户量、月活、SLA要求、技术栈、依赖的中间件和数据库、是否有源码、是否有原厂支持、合规与数据驻留要求、最近一次重大升级时间。这些字段直接决定后续判断。例如“无源码、无原厂支持、用户量低”往往指向Retire或Retain；“有源码、单体、数据库是瓶颈”往往指向Replatform。
第二步：先排除Retire和Retain。这两类不消耗迁移资源，却常被忽略。判断Retire的条件是：无活跃用户、功能已被其他系统覆盖、无合规留存要求。判断Retain的条件是：强依赖专用硬件、数据主权不允许出境、刚完成重大升级、迁移收益低于成本。把这两类先摘出去，能显著缩小需要真正迁移的应用范围。
第三步：在Rehost、Replatform、Refactor、Repurchase之间做取舍。核心看三个维度：改造意愿、改造能力、时间窗口。时间窗口紧、团队云经验少，优先Rehost；数据库或中间件是主要痛点、团队能做兼容性验证，优先Replatform；业务增长快、单体已成瓶颈、有明确现代化路线图，才考虑Refactor；自建系统维护成本高且SaaS已覆盖需求，考虑Repurchase。
第四步：为每个应用设定目标与复查点。策略不是一次定终身。Rehost的应用可以在迁移后6～12个月再评估是否Replatform；Retain的应用应设定复查时间，例如每半年重新评估一次。把策略、负责人、目标时间、复查时间写进迁移台账，才能让6R从概念变成可执行计划。
一个可参考的决策示例
假设某零售企业有四个应用需要处理，示例参数如下（属于教学假设，非实测数据）：
| 应用 | 关键特征 | 推荐策略 | 理由 |
|---|---|---|---|
| 门店POS后台 | 无源码、原厂已停止支持、用户量低 | Retire | 功能已被新POS覆盖，无留存要求 |
| 核心订单系统 | 单体Java、自建MySQL、月活高、有源码 | Replatform | 数据库是瓶颈，先换Cloud SQL降低运维 |
| 内部报表平台 | 自建数据仓库、查询慢、增长快 | Refactor | 改用BigQuery，重构数据链路 |
| 自建邮件系统 | 维护成本高、功能通用 | Repurchase | 改用Google Workspace |
| 生产控制网关 | 依赖专用硬件、数据不出厂 | Retain | 暂留本地，半年后复查 |
策略选择与后续现代化的衔接
6R不是终点，而是现代化路径的起点。Rehost之后可以逐步Replatform，Replatform之后可以针对核心模块Refactor。建议在迁移台账中为每个应用记录“当前策略”和“目标策略”，例如：订单系统当前Replatform，目标12个月后对促销模块Refactor。这样迁移就不是一次性项目，而是持续现代化的第一步。
最后，6R的落地依赖两个动作：一是把每个应用都明确归入某一类，不允许“待定”长期存在；二是为每类策略定义验收标准。Rehost的验收是应用在Compute Engine上可正常访问、备份与监控就绪；Replatform的验收是托管服务连接正常、性能不低于原环境；Refactor的验收是新架构通过功能与压力测试；Repurchase的验收是数据迁移完整、用户可正常使用；Retire的验收是数据已归档、依赖已解除；Retain的验收是复查时间已登记。把策略和验收标准绑定，6R才真正可执行、可追踪。