只要列出服务器和目标环境，一份迁移方案看起来就可能已经完整。但更棘手的问题在于这些服务器所支撑的实际工作：员工能否继续处理订单？定时导出何时运行？迁移后由谁检查记录？云迁移计划应将基础设施决策与这些日常活动联系起来。按照以下顺序，可以把笼统的迁移目标转化为可评审的具体工作。
本页内容
明确运维层面的改善目标
不要只把目标写成“迁移到云端”，而应说明一个能够评估的理由。例如，版本发布可能依赖一台手动配置的服务器，或者业务高峰所需容量已经超出现有环境的能力。在定义未来环境之前，先记录当前系统的实际表现。缺少这一基准，就很难判断迁移究竟解决了原来的问题，还是仅仅改变了问题发生的位置。
- 明确受影响的工作流程及其负责人。
- 描述可观察到的改善，例如可重复执行的部署流程。
- 列出迁移必须遵守的约束。
梳理每个工作负载周围的连接
为每个应用列出数据库、文件存储、定时任务、外部服务和访问要求，并请负责运行该应用的人员审阅这份关系图。夜间生成的报告或供应商连接，在服务器清单中很容易被遗漏。标明哪些依赖项需要一起迁移，以及分阶段过渡期间哪些连接可以保持现状。
为每个应用选择迁移方式
举例说明一个决策：某客户门户使用仍受支持的运行时环境，但与旧版财务应用共用一个数据库。只有留在原环境中的数据库连接满足约定的访问与性能要求时，优先迁移门户才可能合理。否则，应将相互连接的工作负载一起迁移，或先处理依赖问题。应根据该应用的需求，比较直接迁移、针对性调整和重新开发，而不必让整个系统环境采用同一种方式。
设计新环境的运行方式
明确访问管理、部署、告警、备份和费用审查的负责人。利用现有使用数据估算需求，兼顾低峰与高峰时段。还应考虑存储增长或服务之间传输数据时，估算会如何变化。有价值的成本讨论应解释其假设，以及上线后需要监控哪些内容，而不是把第一次估算当作固定的运维账单。
- 谁可以修改生产环境设置？
- 任务失败时由谁响应？
- 如何验证备份恢复？
在切换前确定回退决策条件
以上述门户为例，应在开放新环境之前，约定团队如何验证登录、订单提交和记录数量。明确哪些故障会中止过渡，以及由谁作出决定。如果用户在切换后能够创建新记录，仅将流量切回旧服务器并不足够，还需要约定这些记录的处理方案。应演练整个操作顺序，并明确从哪个时间点开始，回退会涉及额外的数据处理工作。
通过运行检查完成迁移收尾
迁移后，应对照约定基准检查工作流程、定时任务、告警和使用模式。为尚未解决的问题指定负责人。只有团队完成过渡检查，并确定哪些数据或配置需要保留之后，才能停用旧环境。应确保后续维护人员能够获取应用关系图和恢复说明。