迁移计划的细节因数据中心而异，取决于开始实施服务器整合的时候有多少服务器和还要添加多少新的服务器。不过，在制定你的迁移计划的时候，总有一些通用的指南可供遵循。

• 将迁移过程划分为多个易管理的阶段，在各阶段之间给实施人员留下充足的时间用来处理遇到的各种问题，同时，在开始下个阶段之前，根据需求完善迁移计划。
• 即使分析阶段已经显示有足够的现存服务器可满足最终状态，你的计划中仍然需要购买一些“中转”服务器以满足迁移的第一个阶段的需求。
• 如果你需要购买少量几台服务器以满足最终状态的需求，那就添加几个新的服务器以便你有足够的设备支持迁移过程的第一个阶段。
• 制订各个阶段实施的顺序，保证构成最终状态的现存服务器能够在第一时间从迁移计划中释放。
• 对需要部署在专有服务器上的应用实例和数据库实例（包括他们的组合），如果现有的服务器性能足够，就不必迁移。如果你打算将某个实例从现在的服务器上迁走，请注意迁移文档上当前“服务器ID”一栏与实例的对应关系。
• 在完整的“应用/数据库实例检查”工作表中导入需要构建每个虚拟机的配置细节。然后将工作表分成多个单独的工作表——每个阶段一个。每个工作表应该包含的信息有应用或者数据库需要的操作系统和操作系统版本，实例所在的服务器和是否需要授权码。如果改变了服务器，或者你还应该要了解如何获得新的授权码。
• 为已制订好的迁移计划的每个阶段加入所有必须的网络改变，特别是当你无法将现有的IP地址分配给新的虚拟机的时候。
• 为每个阶段制订一个“回滚”计划，防止实施出错。“回滚”计划能够让你在出错的时候退回到迁移之前的状态。

　　最终状态操作准备

　　在迁移计划的实施过程中，需要与数据中心的员工一起，敲定大量的细节，从而使数据中心在最终状态下更加完整。确信如下细节已经得到足够的重视：

• 人员培训。迁移之前，所有的人员应该得到培训；高级人员必须参与到计划的制订过程中。
• 选择管理工具，购买并安装。选用哪种管理工具取决于你购买的是什么样的虚拟化软件。
• SAN的能力。确保你的SAN具有足够的容量。如果没有被数据中心中的一些现存服务器使用，SAN可能需要扩展。检查可能发生的性能瓶颈，比如,部分读/写活动频繁的服务器会对SAN产生较高的需求。
• 数据备份。更新你的灾难恢复计划，将数据中心内的虚拟化环境考虑在内。
• 配置管理数据库。用以支撑数据中心的CMDB（配置管理数据库）需要被升级。老的CMDB都是基于一个数据模型，该模型仅包含物理服务器——没有虚拟机。迁移之后，CMDB必须记录应用、虚拟机和服务器之间的关系。

　　比如，虚拟机V1运行在物理服务器S1上；应用A1运行在虚拟机V1上；虚拟机V1安装的是操作系统O1。同时，CMDB必须能够处理非虚拟化的关联关系：应用A2部署在物理服务器S2上；物理服务器S2安装的是操作系统O2。如果你的CMDB没有设计成支持上述的模式、无法识别这些新的关系和属性，在迁移过程中，你的配置管理过程将会很快变的很松散。

• 控制虚拟机蔓延。为数据中心运维管理加入特殊的程序以避免虚拟机蔓延——随着开发团队或者其他组的人员的要求，大量的未使用的虚拟机被创建。虚拟机蔓延会产生诸多浪费，特别是软件授权，在被放弃的虚拟机上没有使用授权会被浪费。所有临时性的虚拟机都应该有一个过期的时间。一旦到了过期时间，就需要从服务中收回未使用的虚拟机，并删除其上的软件。

　　在每个阶段完成之后以及最后一个阶段完成之后几个星期里，密切监视整合后的新环境。确保所有的服务器都适当的运行着多个应用和数据库实例。如果在此期间，出现某个服务器过载，就需要从该服务器上移走几个虚拟机到一个利用率不高的服务器上。