VMware Aria Automation 8 Migration Assistant 具有以下部署限制。
- 部署迁移不可更改，无论成功还是失败。无法重试部署迁移。可以在“载入”服务下重新运行迁移服务创建的计划。使用“载入”服务重新运行时，不会迁移部署的所有者、租约和历史记录。
- 历史成本核算信息不会随部署一起迁移。有关定价和成本的详细信息，请参见什么是定价卡。
- 对于具有按需网络的部署，如果迁移包含 IPAM 管理的 IP 的部署，然后从 VMware Aria Automation 8 中删除迁移的部署，则还必须从 Infoblox 中手动删除关联的 IP 地址。
- 迁移到 VMware Aria Automation 8 后，将迁移所有 IPAM 信息。但是，实施后操作（例如，删除部署）仅对包含外部网络配置文件的部署从外部 IPAM 中释放 IP 地址。对于包含按需网络的部署，必须手动从 IPAM 中移除 IP 地址。要解决此问题，可以创建一个订阅以从 IPAM 中移除该 IP。
- 如果源环境包含配置为使用未连接到计算机的现有网络的负载均衡器，则不会迁移外部网络，并且在迁移过程中不会分配 IP。
- “更新部署”功能仅适用于包含 vSphere 计算机组件的部署。在包含其他组件类型（网络、AWS 计算机、Azure 计算机等）的部署上运行“更新部署”操作会尝试重新创建部署组件。
- vRealize Automation 7 不会从 Azure 端点收集数据，也无法确定是否在 vRealize Automation 7 之外删除了 Azure 计算机。在 VMware Aria Automation 8 的迁移评估过程中，任何已删除的 Azure 部署都列为“就绪”，但在迁移过程中却排除在外，因为 Migration Assistant 找不到虚拟机。
- 如果源部署具有混合网络类型（例如，在同一部署中同时具有 NAT/路由网络用于 NSX-T/NSX-V），则无法迁移源部署。
- 不会迁移包含多个 NSX 负载均衡器组件的源部署。
- 如果源环境包含在 NSX-T 上通过同一蓝图创建的一个 ARM 现有负载均衡器（具有现有网络的按需负载均衡器）的多个部署，则 Migration Assistant 仅创建一个负载均衡器。只有一个已迁移的部署将列出负载均衡器组件。所有其他现有的单 ARM 负载均衡器部署都没有负载均衡器组件。
- 在源部署中配置为 NAT 网络的 IP 地址在迁移后不标记为已分配。但是在迁移后，迁移的负载均衡器和虚拟机的 IP 地址在下标记为已分配。
- 如果源 vRealize Automation 7 部署包含无效资源（例如，没有资源的属性），则不会迁移该资源。如果部署中的所有资源均无效，则不会迁移整个部署。
- 在棕地迁移过程中，载入的计算机和迁移的计算机都不会链接到云区域。因此，这些计算机不会计入存储最大值定义。
- 如果迁移包含单个计算机组件和现有网络组件的部署，vRealize Automation 将尝试重新创建现有计算机，但会失败并显示“需要子网 (Subnet is required)”错误。
- 如果迁移链接到云模板的 vSphere 部署，然后在迁移后更新该云模板，则部署将失败。
- 如果部署包含 DNAT 规则，则迁移后无法执行重新配置实施后操作。
- 将迭代式云模板更新应用于父部署时，迁移的集群计算机不支持横向缩减/横向扩展。
- 只能从 vRealize Automation 7.6 源环境迁移集群部署。vRealize Automation 7.5、7.4 或 7.3 源环境不支持迁移集群部署。
- 如果部署包含 2 个配置为同一网络配置文件但属于不同网络的虚拟机，则迁移将失败。迁移此部署之前，必须先在 vCenter 中手动更新网络，方法是将两个虚拟机的网络适配器更改为同一个。确保数据收集已完成，虚拟机将使用源部署中已更改的网络进行更新。
