Pass migration is the provider switch done properly: a program moves from one wallet platform to another, and the passes already sitting in members' wallets come along, still updating, without anyone re-adding anything. It is the difference between changing vendors and restarting a program.
On Apple Wallet, three assets make it possible. The pass type identifier and its certificates establish the right to sign and update the passes, which is why identifiers registered under the brand's own Apple Developer account migrate cleanly. The pass records, serial numbers and authentication tokens, identify every issued pass. And the device registrations connect those passes to the devices holding them. With all three exported and the pass web service repointed to the new platform, the next push update simply comes from the new home.
On Google Wallet, the question is account ownership: passes belong to an issuer account, so migration depends on whether the program's classes and objects live under the brand's own issuer account or the vendor's.
The time to think about migration is before signing with any vendor. Ask who owns the identifiers and accounts, whether pass records and member data are exportable, and what the vendor's documented exit process is. Portability you have in writing keeps every future negotiation honest, even if you never use it.