If you're considering moving an existing Apple Wallet or Google Wallet programme to PassKit, or want to understand what would happen if you later moved from PassKit to another provider, there is an important distinction to understand:

This is not a PassKit restriction. It is a consequence of how Apple Wallet and Google Wallet are architected and applies whether you use PassKit, another wallet platform provider, or operate your own wallet infrastructure.

You establish your programme and templates in PassKit, connect or migrate the required data, and issue new PassKit-managed passes. Customers add the new passes to their wallets.

You establish your programme with the replacement provider, recreate the required pass records using your master system and/or exported PassKit data, and issue replacement passes. Customers add those new passes to their wallets.

In either direction, you should plan on issuing replacement passes rather than transferring existing installed passes between providers.

This is one reason we recommend keeping your CRM, loyalty platform, ticketing system, membership database or other business system as the authoritative source of customer and programme data.

For more information about this architecture, see Planning Your Integration.

Apple Wallet and Google Wallet use different architectures, but neither treats an installed pass as a vendor-neutral record that can simply be exported from one service provider and imported into another.

Apple Wallet passes that support dynamic updates contain information identifying the web service responsible for managing them.

When a customer installs an updatable pass, their device registers the pass with the web service specified within it. This establishes the relationship required for future updates.

When pass information subsequently changes:

The relationship between the installed pass, the device and the service responsible for maintaining it is therefore established as part of the pass lifecycle.

There isn't a vendor-neutral mechanism for simply moving that installed pass from Provider A to Provider B and having Provider B automatically inherit the existing device registrations and update relationship.

Apple documents the update architecture in Adding a Web Service to Update Passes in the Apple Developer documentation.

Google Wallet uses a different architecture.

Google Wallet passes are represented by objects within Google's Wallet infrastructure. These objects are associated with a Google Wallet issuer and become linked to a customer's Google account when saved to Google Wallet.

Updates are subsequently made to those existing objects through the Google Wallet API.

As with Apple Wallet, you should therefore not treat an existing Google Wallet pass as a portable file that can simply be exported from one service provider and imported into another while preserving the existing customer relationship.

Organisations regularly move existing wallet programmes from other providers to PassKit.

The migration is normally straightforward when the underlying customer and programme data is available from your existing business systems.

Create the required programmes and pass templates within PassKit.

A migration can also be a useful opportunity to review your existing pass design, fields and customer experience rather than necessarily reproducing the previous pass exactly.

Your CRM, loyalty platform, membership database, ticketing system, booking platform or other master system should remain the authoritative source of customer and programme information.

Configure your integration so this system can create and maintain the appropriate records within PassKit.

Where your master system already contains the necessary information, new PassKit records can normally be created directly from that source.

If information exists only within your previous wallet provider, export the relevant data before terminating that service.

Create new passes through PassKit for the customers being migrated.

These are new Apple Wallet and/or Google Wallet passes managed through PassKit rather than transfers of the previously installed passes.

Provide customers with a convenient way to add their replacement pass.

Delivery options can include:

A migration can also be phased rather than requiring every customer to transition simultaneously.

The same principles apply if you decide to move from PassKit to another wallet provider or your own infrastructure.

Configure the appropriate programmes, templates and wallet infrastructure with the replacement provider.

If your CRM, loyalty platform or other master system remains your source of truth, it should already contain most of the information required to recreate your wallet passes.

Where required, your PassKit data can also be exported in accordance with your contractual data rights.

Configure your master system to create and maintain passes through the replacement platform.

Create new Apple Wallet and/or Google Wallet passes using the replacement infrastructure.

Provide customers with a straightforward way to add their replacement pass.

The existing installed pass does not automatically become managed by the new provider.

An existing pass and its replacement should be treated as separate wallet objects.

Depending on the wallet platform, pass configuration and lifecycle, an old pass may remain visible in a customer's wallet in its last available state.

However, you should not design a migration on the assumption that a replacement provider can simply take over management and updating of an existing installed pass.

Instead, your migration plan should include a process for issuing replacement passes and communicating the transition to customers.

Issuing a replacement pass doesn't necessarily need to be viewed as a negative customer experience.

Organisations migrating to PassKit often use the transition as an opportunity to introduce a refreshed “Card 2.0” experience, with an updated design, new functionality or additional benefits for customers.

The principle is similar to replacing a physical membership, loyalty or payment card. When a new plastic card is issued, customers understand that they need to start using the replacement and can dispose of the old card. A digital wallet transition follows much the same pattern, but without the cost and logistics of manufacturing and posting physical cards.

A migration can therefore provide a natural reason to communicate with customers and re-engage them with the programme. For example, you might:

Once the customer has added the replacement pass, they can simply remove the previous pass from their wallet.

The important consideration is therefore not whether customers need to add a replacement pass, but how you design and communicate the transition. With appropriate planning, migration can become a useful customer engagement opportunity rather than simply a technical exercise.

For organisations planning their wallet architecture from the outset, see Planning Your PassKit Integration.

Apple requires organisations issuing Wallet passes to maintain the appropriate Apple Developer account and Pass Type ID configuration.

The Pass Type ID and the certificate used to sign passes are related but separate.

Pass Type ID certificates are created using a Certificate Signing Request (CSR). When PassKit is responsible for signing passes, the certificate is configured for PassKit's signing infrastructure.

If you subsequently change provider, the replacement provider may require a new certificate generated using its own CSR and signing infrastructure.

This does not necessarily mean creating a new Apple Developer account or Pass Type ID, but certificate and signing configuration should be considered as part of the migration.

Importantly, retaining an Apple Developer account or Pass Type ID should not be confused with portability of the installed pass itself.

Google Wallet uses a different issuer model from Apple Wallet.

For standard PassKit implementations, PassKit automatically provisions the Google Wallet configuration required to issue passes. You do not need to establish and manage a separate Google Wallet issuer account simply to use Google Wallet with PassKit.

This simplifies implementation and allows the underlying Google Wallet infrastructure to be managed by PassKit.

Where an organisation has a specific requirement to establish its own direct Google Wallet issuer relationship, this can be considered separately as part of the implementation architecture.

If you subsequently migrate to another provider, that provider will need to establish the appropriate Google Wallet configuration for its implementation.

Again, the issuer configuration should not be confused with portability of passes already saved to customers' Google Wallets.

The most important way to maintain flexibility is not to make your wallet platform the master repository for your business data.

Your CRM, loyalty platform, membership system, ticketing system or other backend should remain authoritative for information such as:

PassKit then becomes the infrastructure through which the appropriate information is presented and maintained within Apple Wallet and Google Wallet.

If you later change wallet providers, your underlying customer and programme data remains available independently of the wallet platform.

This Master System-first architecture is covered in more detail in Planning Your Integration.

Maintain a clear relationship between records in your master system and the corresponding wallet records.

PassKit External IDs can be particularly useful where your existing system already has stable identifiers such as membership numbers, customer IDs, booking references or order numbers.

Keep copies of logos, images, colours, field definitions, programme rules and other assets required to reproduce your wallet experience elsewhere if necessary.

Maintain independent ways of communicating with customers through channels such as email, SMS, your website, customer portal or mobile application.

If you ever need to issue replacement passes, these channels provide the mechanism for transitioning customers.

The distinction can be summarised as follows:

The objective of a well-designed integration is therefore to avoid data lock-in and maintain control of your underlying customer relationships and business logic.

It should not be interpreted as making an already-installed Apple Wallet or Google Wallet pass portable between service providers.

No.

PassKit does not require your CRM, loyalty, membership, ticketing or other underlying business data to become dependent on PassKit.

You can export relevant data held within PassKit and establish a replacement wallet programme elsewhere.

What PassKit cannot provide, and what another wallet platform provider cannot guarantee when replacing PassKit, is the automatic transfer of an already-installed wallet pass into another provider's infrastructure without a customer transition.

That limitation exists at the wallet ecosystem level rather than being a PassKit contractual restriction.

If you're considering moving an existing Apple Wallet or Google Wallet programme to PassKit, contact support@passkit.com with information about:

Our team can help you understand the appropriate migration approach before you begin.