大多数数据中心迁移失败于执行阶段，而非规划阶段。项目获批，进度如期，预算确定，问题却在工作开始影响生产系统时才浮现。
此时，尽量减少停机时间与遵循既定顺序开始相互冲突。决策时间被压缩：一个未记录的依赖关系是否重要，一次验证失败是否足以触发回滚，目标环境是否已准备好接收下一批设备。每个决定都比规划阶段预想的更仓促，掌握的信息也更少。
以下十个阶段涵盖了迁移开始前需要明确的事项、迁移本身的执行顺序，以及留下的设备如何处置。
核心要点
- 迁移失败于执行，而非规划。失败点在于未记录的依赖关系、未定义的回滚标准，以及在目标环境尚未就绪时就假定其已就绪。
- 建立两份清单：物理资产清单，以及在其上运行的应用清单。每个应用都需要一名指定负责人。
- 应用团队与网络团队共同审查依赖关系图。任何一方的视角都无法单独确定完整路径。
- 回滚触发条件在规划阶段确定，并由一名指定人员负责做出叫停决定。
- 系统恢复上线并不等于验证完成。应将数据与源端进行核对，并由应用负责人签字确认。
- 强化监控期（hypercare）持续一到两周，用于发现周末切换期间无法暴露的月末依赖关系。
迁移前全面摸清数据中心环境
前三个阶段旨在确定环境中有什么、各部分如何关联，以及可能出现哪些问题。这三个阶段都在任何设备迁移之前完成。
Uptime Institute的2025年调查显示了忽视这些阶段工作的代价。调查发现，57%的重大数据中心故障造成的损失超过100,000美元，五分之一超过100万美元，而这正是这一阶段能够提前发现的问题。
建立资产与应用联合清单
迁移计划需要两份独立的资产清单：一份涵盖当前数据中心基础设施中的每一项物理资产，另一份涵盖在其上运行的每一个应用或工作负载。一台服务器可能承载多个应用，每个应用的负责人不同，对停机的容忍度也不同。
每个应用都需要一名指定负责人，能够确认该应用的用途以及依赖它的团队。基础设施团队通常并不掌握这些背景信息，因此依赖现有文档会在后续阶段引发问题。
没有指定负责人的应用可能在迁移进行到一半时才冒出来。到那时，可能已没有足够时间来确定如何处理。
同时映射应用与网络依赖关系
依赖关系映射记录的是各组件之间的依赖：应用、数据库、身份验证服务、网络基础设施、计划任务和许可证服务器。
导致迁移失败的，往往是那些没有任何文档记录的依赖关系。脚本中硬编码的IP地址；只在月末运行的批处理作业；仍指向一个多年前就已退役、此后再无任何系统需要的网络配置。
依赖关系图需要由应用团队和网络团队共同审查。每个团队只能看到环境的一部分，只有双方在同一次会议中共同审查，缺口才会显现。应用负责人可能知道某个工作负载在许可证校验失败时无法运行，而网络团队知道该许可证服务器位于哪个子网。任何一方的视角都无法单独确定完整的依赖路径。
将风险评估转化为可执行的风险登记册
风险评估应产出一份风险登记册。每个条目都应包含以下四项：负责人、影响评估、缓解措施，以及在切换前降低风险所需的资源。
预先部署的故障转移路径提供缓解手段，而有记录的故障转移测试则证明其切实可行。如果没有指定负责人，风险可能在切换期间反复出现，团队可能别无选择，只能临场应变。
Uptime Institute的2025年故障分析发现，近40%的组织在过去三年中经历过由人为失误导致的重大故障。其中85%的事件与员工未遵循流程或流程本身存在问题有关。
确定设备迁移的方式和去向
资产清单和风险登记册明确了现有资产及可能出现的问题。接下来的三个阶段将确定设备迁往何处、按什么顺序迁移，以及迁移被迫中止时如何应对。
确认新数据中心环境已准备就绪
首先，在设备开始迁移之前，确认新的数据中心能够支撑相应的工作负载。这包括检查供电和制冷容量、机架空间、网络基础设施、安全控制，并最终确定IP和VLAN方案。
将仍在建设中的站点视为已就绪站点，可能为后续埋下隐患。网络团队应在每批迁移之前确认站点已准备就绪。如果设备运抵后才发现目标环境无法支撑，延误的代价会更高。
围绕依赖关系安排迁移顺序
根据依赖关系图决定先迁移哪些内容。迁移方法应与工作负载相匹配。“直接迁移”（lift-and-shift）方式可以在不改变架构的情况下迁移工作负载，而更复杂的系统则需要采用其他方法。
数据库可能需要与使用它的应用一同迁移，因为该应用还依赖某个身份验证服务。而一台不相关的文件服务器则可以按单独的迁移计划进行。为了方便而随意搬迁设备，可能导致应用仍指向已被移走的硬件。
在切换前规划备份与回滚
备份与回滚规划要回答两个问题：迁移前要备份哪些内容，以及在什么条件下团队要退回旧环境。第二个问题常被团队推迟，但必须在切换窗口开启前而非期间解决。切换前检查包括：完成备份、完成恢复测试，并在整个窗口期内预留回滚人员和容量。
灾难恢复计划也应作为同一准备工作的一部分进行审查。如果迁移失败，团队需要一种经过测试的方法来恢复丢失的数据。
必须有一份经过恢复测试的备份，并通过与源数据进行校验和比对来确认其有效。回滚触发条件也应足够具体，使切换团队无需在迁移过程中再去判断其含义。
执行切换并确认成功
最后四个阶段涵盖迁移本身及随后的验证，因为系统恢复上线并不代表迁移成功。应用可能看似运行正常，却带着不完整的数据；而月末才出现的依赖关系也不会在周末切换期间暴露。
正式迁移前先进行演练
切换前测试意味着完整运行整个迁移流程，而不是孤立地测试各个组件。与生产环境高度一致的预演环境，让团队有机会在迁移前测试数据中心迁移工具。该环境还可用于检查容易被忽视的监控工具和网络配置。
测试与分级用于确定不迁移至新环境的设备状况。如果因为期限紧张而跳过演练，切换就会成为整个流程的第一次完整测试。
为切换制定操作手册，并指定唯一决策人
切换应遵循书面操作手册，明确每一步要做什么、需要多长时间，以及团队在哪些节点暂停验证后再继续。
应由一名负责人掌握决策权。当决策权属于一个小组时，大家可能会犹豫是否叫停。没有人愿意成为叫停的那个人，结果往往在回滚更安全的情况下仍继续推进。
应在迁移前就与相关方的沟通方式达成一致。每位相关人员都应清楚系统何时不可用，以及从哪里获取最新进展。
验证功能与数据
执行检查，确认应用功能正常、数据完整。性能需对照业务负责人对关键系统的预期进行衡量。即使应用中存在数据问题，服务器也可能看似运行正常。
当涉及大量数据时，将迁移分成可控的批次完成可以降低风险，也使验证更加容易。
审批不能仅由迁移团队决定。对于不在日常工作中使用的应用，迁移团队很容易忽视其功能问题，因此最终签字确认应由应用负责人或业务负责人完成。
在迁移后检查期间监控系统
迁移后检查包括一段明确的强化监控期，即hypercare，持续一到两周。强化监控期让团队有时间发现与每周任务或月末流程相关、稍后才出现的问题。
团队借助这最后一个监控窗口确认新环境足够稳定，可以停用旧系统。迁移后检查也为决定如何处置留下的设备提供了时间。
只有在已迁移系统通过验证、新环境证明稳定之后，才开始退役工作。
决定不迁移设备的去向
计划应考虑到，原始清单中的资产并非都会随迁。对于即将寿命终结的设备，以及与新环境不兼容的硬件，应确定明确的处置路径。
AI基础设施的建设使企业的整合工作不断增加。一个近期的大规模数据中心退役项目涉及2,500台AI服务器和超过17,000块散装硬盘，充分说明了为何需要将资产处置与迁移和追踪一并规划。
安全的数据处理和资产核对，让团队能够记录每项退役资产的去向，每一项都能与原始清单相对应。围绕测试与安全擦除建立的流程能够识别出经过测试且仍可正常使用的硬件，从而回收其转售价值。
在此基础上，设备可按相应路径处置：
- 在组织内部重新部署
- 有价值的设备进行转售或翻新
- 寿命终结的设备进行认证回收
在迁移过程中一并处理这些设备，也能降低设施关闭时退役设备被遗留或下落不明的风险。
成功的数据中心迁移带来什么
一次完成的迁移留下的是证据，而非保证：系统在预期窗口内恢复，应用通过功能检查，数据完整性经与源端核对得到确认。
同样的标准也适用于留下的设备。每项退役资产都有记录在案的处置结果，以及从原始清单到最终处置的追溯记录。即使迁移实现了全部技术目标，如果在即将关闭的设施中仍有硬件下落不明，项目也不算真正完成。
妥善完成迁移计划
迁移策略决定工作负载迁往何处，项目计划决定迁移顺序、各项决策由谁负责，以及什么情况下叫停迁移。迁移恰恰失败于两者之间的空白地带。期限压力往往会压缩这段空间，砍掉那些没有可见产出的工作：依赖关系审查、回滚标准、演练。而这些工作的意义，正是在问题修复成本仍然较低时将其暴露出来。
将全部十个阶段纳入计划，能为团队提供清晰的执行顺序，并明确留下的设备如何处置。Reconext的数据中心IT资产处置（ITAD）服务涵盖安全数据处理和资产核对，帮助团队追踪退役设备直至最终处置。
常见问题
一个典型的数据中心迁移项目需要多长时间？
不同范围的项目时间差异很大。中等规模的迁移从规划到强化监控期需要三到六个月。
迁移项目计划应由IT运维部门负责，还是由专门的项目团队负责？
由专门的项目负责人协调计划，并保持各团队步调一致。IT运维部门提供计划所依赖的环境知识，但无需在现有工作之外再承担迁移任务。
如何决定是回滚切换，还是克服问题继续推进？
在规划阶段定义回滚触发条件，并记录需要回滚的具体情形。这样，一旦这些情形出现，切换团队就有明确依据叫停迁移。
迁移期间，现有数据中心是否应并行运行？运行多长时间？
在新环境通过验证并保持稳定之前，必须让现有环境继续运行。迁移预算应考虑这一期间同时运行两个环境的成本。
