如果你要一个数据中心迁移或整合项目，就要做一些非常具体的准备工作，才能确保这个项目取得成功。如果你正从一家供应商换成一家新的供应商，就不要急着开展这个项目，等到满足了规划方面的某些标准再开展也不迟。
从这类迁移项目汲取的经验有重大意义，这有几个原因，包括IT部门内外客户的满意度、成本以及为集成商赢得业务的普遍成功。
就其性质而言，这类项目往往给人的压力特别大，因而团队建设和幽默感成为了重要的工具。让项目三方的技术团队及早参与这个过程，将便于转移知识、加强团队合作。
与客户和第三方分包商积极沟通，并得到他们的大力支持，这至关重要;与第三方企业的上上下下积极沟通事关这种项目的成功。这种项目同样面临人员配备、管理、沟通、谈判和架构等方面的挑战。行动要灵活，思维要有创造性，还要准备打破既定的方法，那样才能竭力推进架构方面的工作。
第一道障碍将是确保现现有和新的供应商、客户及与项目有利害关系的其他任何人都参与进来，并且就承包出去的工作达成一致意见。不管协议多么不重要，任何协议都必须列入文档，因为几个月后大家会渐渐淡忘。
合同内容通常很繁琐，要花很大的精力来拟订草案。如果你有一个团队坐等合同拟订草案、通过审批，预计项目会出现超出预算的情况。这方面要把握的一个准则是，要是没有订好适当的协议，项目就不要开始，因为这会消耗项目资金、导致预算出现问题。
一旦拟订好了协议，经验表明：虽然我们会发现平日的技术人员非常乐于合作，但是第三方供应商的管理人员可能会抵抗，如果他们失去业务更是如此。由此带来的结果将是，由于需要上报无关紧要的事情、转型期间的活动以及竞争优先事项，项目时间表会被往后推迟。
一家供应商习惯采用的流程可能要加以改动;这在一些情况下可能需要修订合同。迁移过程可能由项目团队来推动，这是个错误。就因为你有一支精干的技术团队，能够在周末把数百台服务器迁移过去，并不意味着客户或公司就有能力来测试、核实和接收环境出现的那么多变化。
想确保项目成功，还需要额外的项目管理费用，以及面面俱到的沟通策略和创造性思维。你必须预料到仅仅安排与客户及供应商、架构和技术中小企业开会就面临困难，因为彼此的优先事项可能并不总是一致。
我发现，当迁移项目不是各团队的优先事项时，三方之间缺乏力度或不连贯的项目管理会导致进一步延迟。要牢记一点：如果三方的目标不一致，那么一些简单的任务也需要上报，比如转移许可证，或者建立从新供应商环境到原供应商环境的网络连接。
通常情况下，供应商不会允许任何第三方的人员进入其场地，如果这家供应商在共享基础设施上托管多个客户更是如此。这就意味着，你将无法直接访问管理工具，也无法直接访问收集数据的服务器，这影响了敲定解决方案的进度。
要是无法访问数据中心和管理工具，你就只好赖供应商的人员来做一些工作;这将导致工作从一家内部或新的供应商移交到原供应商。转移资源意味着范围出现变化，可能会推迟项目进度。
出于安全方面的顾虑，供应商阻止你进入其数据中心;同样的原因可能也会阻止你运行数据收集和迁移工具。由自动发现改为手动发现会导致项目推迟几个月，而且事实的确如此。这是由于客户觉得现有供应商拥有的数据常常不完整。此外，环境通常比客户所了解的来得复杂。连锁反应是：
•非功能性需求可能需要加以改动;
•由于提供了新数据，架构方面的决定可能需要重新考虑;
•由于现在可以使用新数据，技术设计可能需要加以修改;
•由于环境的复杂性，测试阶段可能需要比原先预期更多的资源。
在供应商的确允许访问自动化工具的少数情况下，现有供应商的管理人员可能想要审查提供给第三方的任何客户数据。这个过程可能涉及没有落入到新供应商的人员手里的一部分数据。提供的通常是不充足的、过时的数据，不过并非总是这种情况。
最后，新供应商应该准备好只接收所请求的数据;因而，请求在想要多详细的数据方面必须非常具体。
不要简单地请求利用率方面的数据;还要请求处理器线程和利用率、内存和调整内存、网络输入/输出、磁盘输入/输出、磁盘空间使用情况等方面的数据。另外，由于数据收集可能需要重新考虑，进行评估所需要的任何工具都应该在数据收集工作完成后一段时间内保持仍然可用，最好是直到技术设计通过验收。
原文链接： http://www.zdnet.com/blog/btl/datacenter-and-workload-migrations-lessons-from-the-trenches/79942?tag=content;search-results-river