Whenever a PAM Proxy is moved from a virtual platform to Cloud (Azure, GCP....) or conversely, or in general it migrates across platforms, even if the same IP, disk configuration and machine name are kept, it will stop working.
This article explains the reason for this
CA PAM Proxy all versions
CA PAM has the ability to update a PAM Proxy configuration in its database. PAM determines whether a certain proxy exists in the database based on calculation of a Fingerprint, which among other things takes into account the NIC type and other hardware parameters
So if a PAM Proxy is stopped in subnet A and moved to subnet B, and subsequently started, it will send its fingerprint to CA PAM who will detect it is an existing machine in the database. CA PAM should subsequently be able to change its IP address from the one in subnet A to the one in subnet B and the PAM Proxy should continue to work seamlessly
However if one is moving a machine across platforms, that will change the machine hardware layout, so even if the same name or even IP is maintained, when the PAM Proxy starts it will send to the CA PAM server a completely different fingerprint than the one it was sending when in the old platform. PAM will compare what it is receiving against what is in the database and consider the moved machine a a new CA PAM Proxy. Entries in the database will be created for it and the old registered Proxy will stop working.
There is no easy resolution for this. The most simple one is to find the entry for the migrated machine in CA PAM and add it to the same Target Applications as the old proxy was part of, then decommission the outdated one and make sure the the entry in the Devices references the new one
This may be sometimes a cumbersome process so if this is happening you are advised to contact Broadcom Support for assistance