上云迁移：策略与如何不失败

上云迁移是那种可能非常顺利、也可能变成成本与宕机噩梦的项目之一。差别几乎从不在于技术，而在于规划：在于理解迁移什么、如何迁移以及按什么顺序迁移。一次做得好的迁移让企业现代化并降低成本；一次做得差的，则只是把一贯的老问题转移到一张更贵的账单上。在本文中，我们将说明如何谋划一次迁移才能成功。

我们将回顾迁移策略（人所共知的 6R）、一个规划良好的项目的各个阶段，以及最常见的、应当规避的错误。

迁移策略（6R）

并非所有应用都以相同方式迁移。最常用的框架按照每个工作负载被改造的程度区分出六种策略：

• Rehost（直接搬迁，lift-and-shift）：原封不动地搬，快但用不上云的优势。
• Replatform：做些小调整以提升效率，无需重写。
• Refactor：重新设计应用以真正发挥云的优势。
• Repurchase：改用一个等效的 SaaS 方案。
• Retire：关停不再使用的东西（比想象中更常见）。
• Retain：把暂时没有意义迁移的留在本地。

如何选择合适的策略

正确的策略取决于每个应用的价值及其技术状态。一个关键且有未来的系统通常值得做一次让它现代化的 refactor；一个能用但不具战略意义的可以用一次简单的 rehost；而已经无人使用的则应当退役。错误在于对一切只套用一种策略：高效的做法是分析应用清单，为每个应用分配能让其回报最大化的策略。

一次规划良好的迁移的各个阶段

一次严肃的迁移会经历清晰的阶段：发现与盘点（你有什么、它们如何关联）、评估（为每个工作负载选哪种策略）、目标架构设计、用非关键工作负载做一次试点、分批次迁移，最后是上云后的优化。分批次迁移、从风险最小的入手，能让人在动到关键系统之前学习并纠正。

应当规避的常见错误

最常见的失误是可预见的：对一切做 lift-and-shift 而不优化（结果付得比以前更多）、没有把成本估准、低估系统间依赖的复杂性、忽视配置中的安全，以及不培训团队。所有这些都可以通过规划，以及一次能在问题还便宜时就让它们浮出水面的试点来规避。

迁移过程中的安全与合规

一个常被忽视的点是迁移过程本身的安全。把敏感数据迁上云要求对其在传输中和静止时加密、审查谁有权访问什么，并从第一天起正确配置权限，因为一个配置错误的存储桶是最常见的泄露原因之一。此外，视行业而定，还须保证合规（GDPR、数据驻留）并留存操作记录以备日后审计。把安全融入迁移计划，而不是作为最后的复查，能避免代价高昂的事故和临门的延误。

迁移也是现代化的机会

迁移不应只是一次搬运：它是清除冗余、把有价值的东西现代化、并留下一个可供成长的基础的最佳时机。借这个项目引入自动化、改善可观测性并重新设计关键工作负载，能把一笔不得不花的开支变成一项在敏捷和效率上多年回本的投资。

在 AxiomTech，我们分批次规划并执行上云迁移，为每个工作负载选择合适的策略，并借项目之机进行现代化。如果你想在成本和性能上都不出意外地迁移，我们聊聊，为你提出下一步建议。