4、上云策略制定：Rehost、Replatform、Refactor、Retire、Retain 策略选择
上云策略的制定，说白了就是回答一个问题：「我手里这堆系统，到底该怎么搬上云？」
很多团队一上来就想着「全量迁移」，结果要么成本失控，要么业务中断。我见过最夸张的一个案例，某银行把一套老旧的核心账务系统直接 Rehost 到云上，结果因为底层架构不兼容，跑了一个月就回退了。嗯，这里要注意——策略选错了，后面全是坑。
今天我们就来拆解这五个策略：Rehost、Replatform、Refactor、Retire、Retain。我个人习惯把这五个词记成「5R」，好记又好用。
核心原则：没有「最好」的策略，只有「最合适」的策略。每个系统都要单独评估，别搞一刀切。
4.1 Rehost（直接迁移）——「原样搬，先跑起来再说」
Rehost 也叫「直接迁移」或「Lift & Shift」。说白了就是把现有的系统，包括操作系统、中间件、数据库，原封不动地搬到云上。不做任何架构改动，最多改改网络配置。
适用场景：
- 系统架构老旧，但业务不能停
- 迁移窗口期短，比如只有周末两天
- 团队对云还不熟悉，先搬上去再慢慢优化
优点：快、风险低、不需要改代码。
缺点：没有利用云原生特性，比如弹性伸缩、自动容灾。说白了就是「披着云外衣的物理机」。
我的经验：我曾经帮一家城商行迁移一套信贷审批系统，客户要求「周末必须上线」。我们直接用了 AWS 的 VM Import/Export 工具，把整个虚拟机镜像搬上去，再改一下网络路由。周六晚上开始，周日早上就验证通过了。虽然事后又花了两周做优化，但业务一天都没断。
4.2 Replatform（平台优化）——「小改怡情，性价比最高」
Replatform 也叫「平台优化」或「Lift, Tinker and Shift」。意思是搬的时候顺手做一点优化，比如把自建数据库换成云数据库 RDS，或者把 Web 服务器换成负载均衡 + 弹性伸缩组。
适用场景：
- 系统架构基本合理，但某些组件可以云化
- 想降低运维成本，比如不想自己维护数据库
- 迁移后希望获得一些云原生能力，比如自动备份
优点：改动小、收益明显、风险可控。
缺点：需要一定的改造工作，不能完全「无感」迁移。
避坑指南：我曾经遇到一个项目，客户把 Oracle 数据库直接 Replatform 到云上的 RDS for Oracle。结果因为云 RDS 不支持某些高级特性（比如高级压缩），应用跑起来性能下降 30%。后来我们不得不回退到自建 Oracle。所以——Replatform 前一定要做兼容性测试。
4.3 Refactor（重构）——「大动干戈，但值得」
Refactor 也叫「重构」或「Re-architect」。这是最彻底的策略——把单体应用拆成微服务，把传统数据库换成云原生数据库，甚至重写整个业务逻辑。
适用场景：
- 现有系统已经无法满足业务需求，比如性能瓶颈、扩展性差
- 想充分利用云原生能力，比如 Serverless、容器化
- 系统本身需要技术债务清理
优点：长期收益最大，架构现代化。
缺点：周期长、成本高、风险大。
注意：Refactor 不是「银弹」。我见过一个团队，花了一年时间重构一套核心交易系统，结果上线第一天就出了生产事故。为什么？因为重构过程中业务逻辑变了，但测试用例没跟上。所以——Refactor 一定要有完善的自动化测试覆盖。
4.4 Retire（退役）——「该扔就扔，别舍不得」
Retire 就是「退役」。有些系统已经没人用了，或者功能被其他系统替代了，那就直接关掉，别往云上搬。
适用场景：
- 系统已经废弃，或者用户量极少
- 有替代系统可以承接功能
- 维护成本远高于使用价值
优点：省成本、省运维精力。
缺点：需要确认数据是否需要归档，以及是否有合规要求。
我的习惯：每次做迁移评估，我都会先问业务方：「这个系统还有人用吗？」如果答案是「好像没人用了」，那就直接走 Retire 流程。我曾经帮一家保险公司关掉了 12 套老旧系统，每年省下近 200 万的运维成本。
4.5 Retain（保留）——「先不动，看看再说」
Retain 就是「保留现状」。有些系统暂时不适合迁移，比如依赖特定硬件、合规要求不允许上云、或者迁移成本太高。
适用场景：
- 系统依赖专有硬件（比如 ATM 前置机）
- 监管要求数据必须留在本地
- 迁移成本 > 迁移收益
优点：避免不必要的风险。
缺点：无法享受云的优势，需要继续维护本地环境。
关键点：Retain 不是「永远不动」。我建议每半年重新评估一次，因为云服务商的能力在变，监管政策也在变。说不定明年就能搬了。
4.6 如何选择？——一个简单的决策框架
你想想看，面对几十上百套系统，怎么快速决策？我个人习惯用这个四步法：
- 第一步：问「这个系统还有人用吗？」——没人用就 Retire。
- 第二步：问「能搬吗？」——有合规或硬件限制就 Retain。
- 第三步：问「需要改吗？」——不需要改就 Rehost；需要小改就 Replatform；需要大改就 Refactor。
- 第四步：问「值得改吗？」——如果改造成本 > 未来收益，那就 Retain 或者 Retire。
下面这个表格可以帮你快速对照：
| 策略 | 改动量 | 迁移速度 | 风险 | 长期收益 | 典型场景 |
|---|---|---|---|---|---|
| Rehost | 无 | 快 | 低 | 低 | 老旧系统、紧急迁移 |
| Replatform | 小 | 中 | 中 | 中 | 数据库云化、中间件替换 |
| Refactor | 大 | 慢 | 高 | 高 | 核心系统现代化改造 |
| Retire | — | — | — | — | 废弃系统、功能合并 |
| Retain | — | — | — | — | 合规限制、硬件依赖 |
最后提醒一句：别指望一次把所有系统都搬完。我建议按「二八原则」——先搬 20% 最容易的系统，积累经验，再逐步推进。我曾经见过一个团队，一上来就 Refactor 核心系统，结果搞了半年还没上线，老板直接叫停了整个迁移项目。
嗯，策略选择就讲到这里。记住：没有完美的策略，只有合适的策略。 下一章我们会聊迁移前的评估和规划，到时候再细说。