3. 迁移策略与6R决策模型
6R模型是AWS迁移方法论中最核心的决策框架，它把"这个应用怎么上云"这个模糊问题，拆解为六条互斥且可执行的路径。理解6R的关键不在于背下六个英文单词，而在于掌握每条路径背后的改造代价、时间成本、业务收益三者之间的权衡关系。选错R，轻则多花几个月工期，重则让一个本可快速见效的系统陷入长期重构泥潭。
六条路径的本质差异
Rehost（重新托管，俗称"平移"）是把服务器原样搬到EC2，操作系统、中间件、应用代码一律不动。它的价值在于快：一台物理机或VMware虚拟机，用AWS Application Migration Service（MGN）做块级复制，通常几小时到几天就能完成割接。适用场景是那些"能跑就别碰"的遗留系统、厂商已停止支持但业务仍依赖的软件、以及迁移窗口极短的紧急上云。代价是无法享受云原生红利，EC2实例规格若照搬物理机配置，往往存在明显资源浪费。
Replatform（重新平台化，俗称"换引擎不换车"）保留应用主体，只把部分组件替换为托管服务。典型例子：把自建MySQL迁到Amazon RDS、把本地Nginx换成ALB、把文件服务器换成S3。它比Rehost多花一点改造时间，却能显著降低运维负担。判断是否值得Replatform，可以问一句：这个组件换成托管服务后，团队每月能省下多少运维工时？如果答案是"几乎不用管了"，那就值得做。
Repurchase（重新采购，即"换产品"）是放弃自建，直接采购SaaS替代。自建CRM换成Salesforce、自建邮件系统换成WorkMail、自建Git换成CodeCommit或第三方SaaS，都属于这一类。它的决策点不在技术，而在数据迁移成本和业务连续性——历史数据能否完整导出、员工是否需要重新培训、与现有系统的集成接口是否要重写。
Refactor（重构，也称Re-architect）是改动最大、收益也最大的一条路。把单体拆成微服务、把同步调用改成事件驱动、把有状态应用改成无状态，配合Lambda、ECS、DynamoDB等云原生服务。它适合业务增长快、当前架构已成为瓶颈、且团队具备云原生开发能力的系统。Refactor不应作为默认选项，因为它的工期和风险通常是Rehost的数倍。
Retire（退役）是直接关停。迁移前做资产盘点时，常会发现一批无人认领的应用——使用率极低、重复建设、或已被新系统替代。这类系统迁过去只是把技术债搬到云上，正确做法是走下线流程。
Retain（保留）是暂时不动。可能因为合规要求数据必须留在本地、可能因为系统刚完成改造不宜再动、也可能因为依赖关系复杂需要后续批次处理。Retain不是"遗忘"，而应明确记录保留原因和复审时间。
决策矩阵：从应用画像到路径选择
实际项目中，6R不是凭感觉选的，而是用一组可量化的问题逐层过滤。下面这张决策表可以直接用于迁移评估会，每个应用填一行，按顺序回答即可收敛到唯一路径。
| 判断顺序 | 关键问题 | 回答"是" | 回答"否" |
|---|---|---|---|
| 1 | 该应用是否仍被业务使用？ | 继续判断 | Retire（走下线流程） |
| 2 | 是否存在合规/技术约束必须留在本地？ | Retain（记录复审时间） | 继续判断 |
| 3 | 是否有成熟SaaS可完整替代？ | Repurchase（评估数据迁移） | 继续判断 |
| 4 | 当前架构是否已成为业务瓶颈？ | Refactor（需云原生团队） | 继续判断 |
| 5 | 是否有组件可换为托管服务且收益明显？ | Replatform | Rehost（默认兜底） |
这个顺序很重要：先排除"不该迁"的（Retire、Retain），再排除"不该自己建"的（Repurchase），最后才在"怎么迁"里做选择。很多团队一上来就讨论Rehost还是Refactor，结果把一批早该下线的系统也列进了迁移清单。
一个可落地的评估示例
假设某零售企业有四个待迁系统，我们用上面的矩阵走一遍。
系统A：门店POS后台，运行在Windows Server 2008上，厂商已停止支持，但门店每天仍在用。合规上无本地留存要求，无SaaS替代品，架构简单且非瓶颈，中间件可换RDS。判断路径：1是→2否→3否→4否→5是，结论Replatform，把数据库迁到RDS，应用层Rehost到EC2。
系统B：内部工单系统，自建、使用率低，已有Jira可用。判断路径：1是→2否→3是，结论Repurchase，采购Jira并迁移历史工单数据。
系统C：核心订单服务，单体Java应用，大促期间数据库连接池频繁打满，团队有Spring Cloud经验。判断路径：1是→2否→3否→4是，结论Refactor，拆分为订单、库存、支付三个服务，数据库按域拆分，引入SQS削峰。
系统D：财务归档系统，监管要求原始凭证数据必须存放在本地机房。判断路径：1是→2是，结论Retain，保留本地，但可把查询前端迁到云上，通过专线访问本地数据。
常见误判与规避
把Refactor当默认选项。重构听起来"更云原生"，但一个中等规模单体的重构周期常在6～12个月，期间业务需求仍在变化。除非当前架构确实卡住了业务，否则先用Rehost或Replatform快速上云、拿到云的基础收益，再择机重构，往往是更稳的节奏。
Rehost不等于"什么都不做"。平移后至少要做三件事：按实际负载重新选型实例规格（而非照搬物理机配置）、开启CloudWatch监控建立基线、配置备份与灾备策略。否则只是把本地的问题原样搬到了云上。
最后要强调，6R是按应用逐个决策的，不是按整个数据中心一刀切。同一个迁移批次里，完全可能同时存在Rehost、Replatform和Retire。把每个应用的选择理由、目标架构、负责团队记录在迁移评估表中，才是6R模型真正落地的方式。