# 迁移批次规划的方法
迁移批次规划既是科学也是艺术，有些规划依据数据，有些规划只能依赖专家经验，批次规划需要做好三件事情：迁移分组、迁移分批、迁移优先级。
图1批次规划   
![](https://support.huaweicloud.com/usermanual-caf/zh-cn_image_0000002264949372.png "点击放大")
**一、迁移分组**
迁移分组主要是基于依赖关系将迁移对象进行分组，我们将一组具有强依赖关系的应用程序和基础架构的集合（包括APP、主机、存储、数据库、中间件等）放进一个迁移分组，迁移的时候要放同一批次，切换的时候要一起切。
依赖关系主要包括三种：共享数据依赖、共享服务器依赖、应用间的通信依赖。
依赖关系还有强弱之分：以共享数据依赖举例：应用程序A、B 和 C 都连接到db01，A 和B 每秒都会进行许多读写操作，但是C每晚在非高峰时间运行批处理作业，因此A、B和db01是紧耦合，C与db01是松耦合，A和B必须与db01一起迁移，放到同一个迁移分组，C可以单独移动，如果需要可以放到另一个迁移分组。
**二、迁移分批**
企业上云过程往往是分批进行的，1个分批可以包含1个或多个迁移分组，每个分批都是上云过程的一个里程碑，迁移分批一般参考以下原则：
- **依据关联性分析结果，强关联的应用要放在一个分批**
  关联性强的要放在一个批次一起迁移，避免云上云下互访延时对业务的影响
  
- **一个分批跨度** **4\~8** **周最合适**
  将批次划分到合适的大小，以确保有足够的人力和技术资源来执行迁移过程，并将风险降至最低，业界最佳实践一个批次跨度4\~8周最合适，时间指的是（部署、迁移、切换），不包含准备阶段。
  
- **一个分批不能太大，太大增加迁移风险**
  根据业界最佳实践，一个批次不应超过20个应用程序、150 个服务器和30个数据库，超过这个大小挑战和风险都很大，增加失败挑战和回退风险，建议严格检查此规则的任何例外情况。
  如果一个分批很大，首先要将关联关系打开，识别出强关联和弱关联，将弱关联断开，拆分成较小的分批迁移，降低风险。
  
- **同一供应商的系统安排在同一批或相邻的批次上云**
  同一供应商的多个系统之间耦合度较高，将这些系统的上云时间安排在一起，更有利于供应商在一段较短的时间内集中人力资源，确保各项目组之间的协同，有利于上云迁移实施的顺利开展。
  
- **不同的迁移环境放到不同的分批**
  将生产环境与测试环境放在不同的分批中，先迁移测试环境，可以大大降低生产环境的迁移风险。
  
**三、迁移优先级**
影响上云迁移优先级的影响因素有如下：
表1迁移优先级影响因子 
| **影响因素** |        **影响结果**        |
|---|---|
| 业务上云意愿   | 上云意愿度高的先上，意愿度低的后上      |
| 业务环境     | 测试环境优先，生产环境最后          |
| 业务重要性    | 一般业务先上，核心业务后上          |
| 业务关联度    | 关联关系简单的业务先上，复杂的业务后上    |
| 基础架构复杂度  | 底层基础架构简单、实例数少的先上，复杂的后上 |
| 允许停服时间   | 停服时间长的先上，不停服的最后上       |
| 迁移策略     | 平迁的先上，要改造的后上           |
   
其中，业务部门的上云意愿是第一优先级，先基于上云意愿排序，然后再按其余因素进行排序。如果做的更科学一点，可以基于每个影响因子打分，按照打分结果确定优先级。
表2迁移优先级参考评分表 
| **分类**  | **影响因素**     | **分数参考** |
|:---|:---|:---|
| 业务环境    | 开发           | 5        |
| 业务环境    | 测试           | 3        |
| 业务环境    | 生产           | 1        |
| 业务重要性   | 一般           | 5        |
| 业务重要性   | 重要           | 3        |
| 业务重要性   | 核心           | 1        |
| 关联性     | 简单           | 5        |
| 关联性     | 复杂           | 3        |
| 关联性     | 非常复杂         | 1        |
| 基础架构复杂度 | 简单（实例数1\~3）  | 5        |
| 基础架构复杂度 | 复杂（实例数4\~10） | 3        |
| 基础架构复杂度 | 很复杂（实例数11\~） | 1        |
| 允许停服时长  | 120分钟以上      | 5        |
| 允许停服时长  | 60\~120分钟    | 3        |
| 允许停服时长  | \<60分钟       | 1        |
| 迁移策略    | Rehost       | 5        |
| 迁移策略    | Replatform   | 3        |
| 迁移策略    | Re-architect | 1        |
   
#### 应用迁移批次规划样例
表3批次规划样表 
| **应用名称** | **上云策略** | **上云批次** | **第一批次上云**             | **第二批次** **上云**        | **第三批次** **上云**        | **第四批次** **上云**        |
|:---|:---|:---|:---|:---|:---|:---|
| -        | -        | -        | 2025.01.01\~2025.03.31 | 2025.04.01\~2025.06.30 | 2025.07.01\~2025.09.30 | 2025.10.01\~2025.12.31 |
| 此处仅给出表头信息作为参考。 表格具体内容请按业务实际情况进行补充。                                                             |||||||