The VMware Aria Automation 8 migration assistant has these deployment limitations.

  • Migration of a deployment is final regardless of whether it succeeded or failed. You cannot retry a deployment migration. You can rerun the plan created by the migration service, under Onboarding service.When rerun using the Onboarding service the owner, lease, and history of the deployment are not migrated.
  • Historical costing information is not migrated with deployments. For more information on pricing and costs, see What are Pricing Cards.
  • For deployments with on-demand networks, if you migrate a deployment that contains an IPAM-managed IP and then delete the migrated deployment from VMware Aria Automation 8, you must also manually delete the associated IP address from Infoblox.
  • After migrating to VMware Aria Automation 8, all IPAM information is migrated. However, day2 operations, such as deleting deployments, release the IP addresses from an external IPAM for deployments containing external network profiles only. You must manually remove the IP address from IPAM for deployments containing on-demand networks. As a workaround, you can create a subscription to remove the IP from IPAM.
  • If your source environment includes a load balancer configured to an existing network that is not connected to a machine, the external network is not migrated and the IP is not allocated during migration.
  • The "Update Deployment" functionality only works for deployments containing vSphere machine components. Running an "Update Deployment" action on deployments that contain other component types (networks, AWS machines, Azure machines, etc) attempts to recreate the deployment components.
  • vRealize Automation 7 does not collect data from Azure endpoints nor can it identify if an Azure machine was deleted outside of vRealize Automation 7. During Migration Assessment in VMware Aria Automation 8, any deleted Azure deployments are listed as Ready but are excluded during migration because the migration assistant cannot find the VMs.
  • You cannot migrate a source deployment if it has mixed network types, such as both NAT/route networks in the same deployment for NSX-T/NSX-V.
  • Source deployments that contain more than one NSX Load Balancer component are not migrated.
  • If your source environment contains multiple deployments of a one ARM existing load balancer (on-demand load balancer with existing network) created from the same blueprint on NSX-T, the migration assistant only creates one load balancer. Only one of the migrated deployments will have the load balancer component listed. All other existing one ARM load balancer deployments do not have the load balancer component.
  • The IP address configured to the NAT network in your source deployments is not marked as allocated post migration. However, the IP addresses of migrated load balancers and VMs are marked as allocated under Infrastructure > Networks > IP Address post migration.
  • If your source vRealize Automation 7 deployment contains an invalid resource, for example it does not have properties for a resource, then the resource is not migrated. If all the resources are invalid in the deployment, the entire deployment is not migrated.
  • During brownfield migration, both onboarded and migrated machines are not linked to cloud zones. As a result, these machines are not calculated into storage maximum definitions.
  • If you migrate a deployment with a single machine component and an existing network component, vRealize Automation attempts to recreate the existing machine and fails with a 'Subnet is required' error.
  • If you migrate a vSphere deployment that is linked to a Cloud Template, and then update the Cloud Template post migration the deployment fails.
  • If a deployment contains DNAT rules, reconfigure day 2 actions cannot be performed post migration.
  • Migrated clustered machines do not support scale in / scale out when applying iterative Cloud Template updates to the parent deployment.
  • You can only migrate clustered deployments from vRealize Automation 7.6 source environments. Migrating clustered deployments is not supported for vRealize Automation 7.5, 7.4, or 7.3 source environments.
  • Migration fails if a deployment contains 2 VMs that are configured to the same single network profile but belong to different networks. Before you can migrate this deployment, you must update the networks manually in vCenter by changing the network adapter to be the same for both VMs. Enusre data collection is completed and the VMs are updated with the changed networks in the source deployments.