在供职于一家基础设施即服务提供商的过程中，我看到了很多IaaS应用程序迁移。迁移主要集中于两个方向：从物理服务器到云服务，以及在私有云和公共云之间的相互迁移。
虽然企业经常有需要部署相关的迁移工作，但这样的工作实在不应该仓促进行。一个糟糕的迁移策略，可能会导致成本昂贵的时间延迟、数据丢失以及其他的困难，这样反而阻碍了您企业成功部署现代化基础设施的步伐。
每个场景都是不同的，您需要根据您的应用程序的不同，明确您要从哪里开始着手，以及您部署迁移到真正目的是什么。
***实践方案：选择好您的迁移策略
选项1：只是数据迁移。这通常是典型的1级和2级应用程序的正确选择。如果您选择迁移您的虚拟机或虚拟应用程序，其仍然会不断地改变。如果它是1级应用程序，您将无法负担大量的停机时间。
所以，在一般情况下，我们建议调用一些复制。复制本身是一个复杂的、详细的主题，但理解的关键是识别数据的大小和变化，以及源和目标之间的带宽速率。
作为一般规则，如果您的变化率大于或等于您的带宽，您的迁移可能会失败。这是因为变化率涉及到任何进入到应用程序的变化。您需要足够的带宽以“超越”变化率。
选项2：机械复制。这对于1级和2级应用程序是***的，能够承受一定的停机时间，它涉及到堆栈的迁移。在这种情况下有较少的配置，但有更多的数据迁移。
如果您是迁移到一个内部私有云，选项2是***的实践方案。您将能够复制整个堆栈，因为您有足够的带宽来移动周围的东西。
注意到VMware基础技术的可移植性是很重要的，因为虚拟机允许您将整个虚拟机/ 虚拟应用程序、整个堆栈打包成OVF。如果您已经在物理虚拟服务器上，OVF可以将其迁移到任何地方。
选项3：P2V迁移。您通常看到2级和3级应用程序并没有被虚拟化。这一概念涉及到物理应用程序的虚拟化。VMware有一套虚拟转换器，并进行P2V。采用P2V可以很容易从一台物理设备迁移到私有云。
但是，***实践方案的设置完全不同，您应该做一些扩展研究，确保您更新到***的设置，采用了***的做法和建议。在选项3中，没有复制。但是，这些应用程序可以被迁移公共云供应商，在完成了虚拟化后公共云中运行。
选项4：灾难恢复。一些企业***采取的一个路径是将其作为一个灾难恢复(DR)的情况。进行一些设置，然后在一些物理设备之间进行基本的复制。他们选择复制整个堆栈从A点到B点，然后单击“切换”按钮。
现在，让我们假定您已经找到了***的工具和路径迁移您的应用程序。在您真正开始迁移工作之前，仍然有相当多的信息需要进行评估和整合。
***实践方案：了解您的数据的权重
没有简单的方法来压缩数据，所以您需要评估您考虑迁移的应用程序数据的权重。特别是如果您的企业是一家大的交易公司，或者如果您的交易中会有大量的数据复制。数据应用程序将占到数据权重的99%。
另一个方面，您应该评估您的预迁移计划，以确定您的虚拟机或虚拟应用程序如何与其他应用程序连接。如果您有很多的应用程序与您要迁移的应用程序紧密耦合，云计算可能不会是这些应用程序的一个好的选项。
***实践方案：确定您应用程序的连接
您的应用程序是否有其他应用程序需要快速访问数据?如果是这样的话，一个“全有或全无”的经营理念，将是您迁移的***选择。如果您的应用程序是与其他的两个或三个应用程序紧密耦合，您可以把他们都迁移到云计算。因为他们仍然是紧耦合的，如果您的云托管需要访问物理服务器以获取其运行需要的数据应用，您也不会有延迟。
确定多少应用程序是与您需要迁移的应用相绑定的。下一步，确定这些应用程序对于延迟问题的敏感程度。敏感程度将是您是否迁移相关应用程序的重要考虑因素。
仔细检查***实践方案的列表，以确保了解您的应用程序，并且不会在迁移完成之后对于发生的相关改变而惊慌，甚至手足无措。
每款应用程序、已经迁移策略都是独特的，所以没有一套详细的指导手册是放之四海而皆准的，您需要根据您企业迁移到具体需求，制定适合您企业的实践方案。
