Not every device has a proper compliance check and rule validation controls in place, that depends how large is the organization and how willing the Infosec team is to validate every rule on every device. Because of that difference in methodologies from SOC to SOC, those performing the migration using the Migration Tool 3.0 must be capable of understanding the project requirements, and the legacy devices, as well as any compliance requirements for the, or target, PAN-OS device.
The most common case is to find several address objects, address-groups, service objects and service-groups duplicated in value, meaning that the same service or group of services are part of 2 or more groups with different names. What that causes is, most certainly, policy duplication, maybe NAT policies duplication as well. When finished the legacy configuration file should be examined by the resource thoughtfully, even before to be brought into the Migration Tool 3.0.
The reasoning being:
Wrongly created rules, will generate wrongly migrated policies.
The Migration Tool 3.0 is capable of finding unused objects, duplicated objects by name, IP, CIDR, or service port, but the decision to replace them lies on the hands of the resource performing the migration.
As a good practice, I recommended you understand, validate, and review any legacy configuration file prior to your migration project. The Migration Tool 3.0 is a migration tool not a conversion utility.
