云迁移策略桑基图：从应用到状态
把应用组合从业务部门，经迁移策略（重新托管、重新平台化、重构、替换、退役、保留）画到状态。换成你的应用清单。
云迁移桑基图用一张图呈现整个应用组合：每个业务部门拥有哪些应用，你决定怎么处理每一个，进展到了哪一步。它让永远不会迁移的那部分一目了然。
示例有 100 个应用，分属四个业务部门。它们流向六种策略：重新托管、重新平台化、重构、替换、退役和保留。最后一列是状态：43 个已在云上运行，21 个进行中，20 个未开始，9 个已关闭，7 个继续留在本地。
迁移计划常常只报告完成百分比。桑基图显示了这个百分比藏起来的东西，比如有 22 个应用根本不会迁移，而未开始的工作中最大的一块是退役（6 个应用）。交付方面请看 /zh/guides/查找软件发布流程瓶颈，目标环境的成本请看 /zh/sankey/cloud-cost-allocation。
如何阅读此图表
- 100 个应用中有 43 个（43%）已在云上运行，21 个进行中，20 个未开始。
- 重新托管是最大的策略，有 35 个应用（35%）；重构只有 10 个。
- 22 个应用（22%）不会迁移：15 个退役，7 个保留在本地。
- 重构的进展最差：10 个中只有 2 个已上线，4 个未开始。
图表背后的数据
数字为虚构，仅作说明，并非任何真实机构、团队或系统的数据。单位为应用数量。
| 来源 | 目标 | 数量（个应用） |
|---|---|---|
| 财务 | 重新托管 | 10 |
| 财务 | 重新平台化 | 8 |
| 财务 | 重构 | 3 |
| 财务 | 替换 | 2 |
| 财务 | 退役 | 3 |
| 财务 | 保留 | 4 |
| 销售 | 重新托管 | 8 |
| 销售 | 重新平台化 | 5 |
| 销售 | 重构 | 2 |
| 销售 | 替换 | 5 |
| 销售 | 退役 | 4 |
| 销售 | 保留 | 1 |
| 运营 | 重新托管 | 14 |
| 运营 | 重新平台化 | 9 |
| 运营 | 重构 | 4 |
| 运营 | 退役 | 6 |
| 运营 | 保留 | 2 |
| 人力资源 | 重新托管 | 3 |
| 人力资源 | 重新平台化 | 3 |
| 人力资源 | 重构 | 1 |
| 人力资源 | 替换 | 1 |
| 人力资源 | 退役 | 2 |
| 重新托管 | 已在云上运行 | 25 |
| 重新托管 | 进行中 | 7 |
| 重新托管 | 未开始 | 3 |
| 重新平台化 | 已在云上运行 | 12 |
| 重新平台化 | 进行中 | 8 |
| 重新平台化 | 未开始 | 5 |
| 重构 | 已在云上运行 | 2 |
| 重构 | 进行中 | 4 |
| 重构 | 未开始 | 4 |
| 替换 | 已在云上运行 | 4 |
| 替换 | 进行中 | 2 |
| 替换 | 未开始 | 2 |
| 退役 | 已关闭 | 9 |
| 退役 | 未开始 | 6 |
| 保留 | 继续留在本地 | 7 |
同样的数据（CSV）
source,target,value
财务,重新托管,10
财务,重新平台化,8
财务,重构,3
财务,替换,2
财务,退役,3
财务,保留,4
销售,重新托管,8
销售,重新平台化,5
销售,重构,2
销售,替换,5
销售,退役,4
销售,保留,1
运营,重新托管,14
运营,重新平台化,9
运营,重构,4
运营,退役,6
运营,保留,2
人力资源,重新托管,3
人力资源,重新平台化,3
人力资源,重构,1
人力资源,替换,1
人力资源,退役,2
重新托管,已在云上运行,25
重新托管,进行中,7
重新托管,未开始,3
重新平台化,已在云上运行,12
重新平台化,进行中,8
重新平台化,未开始,5
重构,已在云上运行,2
重构,进行中,4
重构,未开始,4
替换,已在云上运行,4
替换,进行中,2
替换,未开始,2
退役,已关闭,9
退役,未开始,6
保留,继续留在本地,7运作方式
导出应用清单
列出每个应用及其所属业务部门、你的迁移决定和当前状态。
每个应用只用一种策略
为每个应用选主要策略并只算一次。如果一个应用的两部分不同，就在清单里把它拆开。
统计各条流
统计从部门到策略、从策略到状态的应用数量。
检查平衡
每种策略流出的应用数必须等于流入的。“保留”和最终状态到此结束。
常见问题
必须使用这六种策略吗？
不必。六个 R 是常用的说法，你可以用自己的标签。保持数量较少，中间一列才好读。
可以按成本或规模给应用加权吗？
可以：把单位改成年度运行成本（欧元）或服务器数量，而不是应用数量，并写明。数量和成本讲的是不同的故事。
编辑这张云迁移桑基图
把示例作为你自己的图表打开，填入你的应用数量。