云迁移出问题，很少是因为技术本身，更多是因为某个问题直到项目开工才有人问，而那时改变方向已经要花真金白银。在迁移任何工作负载之前，我们希望看到这六个问题的书面答案，篇幅不超过两三页。
一、我们要买的结果是什么？
“上云”只是一项活动。结果应该像这样：租约到期前必须撤出这个机房，站点故障后四小时内恢复，从每季度发布变成每周发布。
答案决定后面的一切。硬性的撤离期限可能足以支持把服务器原样搬过去；但想加快交付，这样做毫无帮助，缓慢的发布流程搬到别人的硬件上依然缓慢。如果目标是降本，在回答第四个问题之前都要保持怀疑，因为把长期开机的服务器原样搬过去，往往更贵。
二、我们到底在运行什么？
文档多半已经过时，所以既要读资料，也要实际观察环境。
- 有哪些应用，各归谁负责？
- 谁在和谁通信？观察网络流量，别漏了夜间和月末任务。
- 哪些系统对留在本地的东西有低延迟要求？通信频繁的应用与数据库分开后，可能根本没法用。
- 哪里写死了IP地址，哪些许可证绑定了特定硬件？
- 哪些应该直接下线，而不是迁移？
依赖关系图是早期规划最有用的成果，它决定了哪些系统必须一起迁移。
三、数据必须放在哪里，谁能接触到？
先弄清真正的义务。合同、行业规定和对客户的承诺可能限制存放地点，而不少人以为的“数据必须留在新西兰”其实只是偏好。偏好也可以成立，但要承认这是一种选择。
本地选项已经多了：微软Azure的奥克兰区域于2024年推出，AWS亚太（新西兰）区域于2025年开放。要确认所需的具体服务在该区域可用，覆盖情况各不相同，新区域通常要逐步补齐。
托管在境外并不能免除责任。隐私专员关于境外披露的指引说得很清楚：放在云服务商那里的个人信息，一般仍由你负责。加密、密钥控制、服务商支持人员的访问和管理员权限，也要现在定下来。
四、三年下来要花多少钱？
用现实的模型与当前开支比较，算上硬件更新、电力、场地和人力这些真实的本地成本。再加上常被遗漏的部分：
- 迁移期间两套环境并行，时间可能远超预期。
- 数据传输费，尤其是流出云端的流量。
- 备份、日志和监控，可能增长成不小的开支。
- 许可证变化，有些软件在云上适用不同条款。
- 培训费用，以及负责迁移的工程师的时间。
计算资源价格是这个模型里最容易的部分。只按服务器清单做的估算，只能当作下限。
五、上线之后谁来运维？
云服务商负责设施和底层平台。按照责任共担模型，身份、配置、你所管理部分的补丁、数据保护和成本仍归你。
决定谁值班、谁批准变更、谁审查安全发现、谁盯账单。第一个工作负载迁入之前，先把账户结构、身份、网络设计和日志作为基础搭好，等系统跑起来再补会很痛苦。如果团队不熟悉平台，先在低风险项目上练手。
六、怎么迁过去，又怎么退回来？
为每个工作负载选择方式。有的值得原样迁移，有的适合换到托管服务，少数需要重新设计，还有的应该留在原地或换成SaaS产品。一刀切的策略对大多数系统都不合适。
每次迁移都要写下：
- 数据如何同步，最终切换需要多久。
- 用哪些验收测试确认一切正常。
- 什么情况触发回退、谁来决定，以及从什么时候起无法再回退，通常是新数据写入目标环境之后。
- 在新环境中用备份做一次恢复测试。
至少用接近真实的数据量演练一次切换，传输时间常常出人意料。
本周可以做的事
把答案写进一份文档，每条标注已知、假设或未知，并发给财务、安全和各应用的负责人。所有未知项都排进项目计划的最前面，先于任何资源开通。如果第一个问题没有明确答案，就先停在那里，直到有答案为止。