Pass Migration

Use pass migration to change the system that manages passes, while keeping already-installed passes working for customers.

A migration is a “behind the scenes” change. Customers keep the same pass in Apple Wallet or Google Wallet. The goal is continuity: the pass stays valid, and updates keep working.

In most cases, a migration is possible without impacting customers.

With the switch planned and tested first, customers keep the same pass and it keeps updating.

Real-world examples

• A retail brand migrates loyalty cards mid-season without asking customers to reinstall.

• A show organizer switches ticketing providers after a pilot.

• A brand consolidates several pass providers into a single platform.

What customers should experience?

When a migration is done correctly, customers do not reinstall anything. They keep the same pass on their device, and they can continue using it as usual.

In practice, this means the barcode or QR code used in-store or at the gate stays the same. The pass also keeps receiving updates (for example : points, tier, balance, seat, gate, or validity).

Most migrations include a short pilot. The flow is validated with a small batch, then the remaining passes are cut over.

Typical migration plan

The exact steps depend on the direction (to or away from The Wallet Crew) and the platform constraints. The flow below stays broadly true in most projects.

1

1) Confirm what “in-place” means for the setup

Confirm which Apple issuer identity signs the passes, and which Google Wallet issuer account owns them. This is what decides whether customers can keep the same pass, or whether a re-issuance flow is required.

2

2) Export pass technical identifiers

The new system needs the identifiers that let it attach to the existing passes (for example Apple serial numbers + authentication tokens, or Google resource IDs/object IDs).

3

3) Map fields and run a pilot batch

Run a small batch first. Update a visible field and validate it on real devices. Keep the pilot simple to allow fast iteration.

4

4) Cut over, then monitor

Execute the cutover plan, then monitor updates and redemption for a few days. Keep a rollback option if the previous provider supports it.

Coordination and timeline

A migration requires coordination between parties. It usually involves the current provider and The Wallet Crew, with the brand's own team involved when it controls issuer accounts and certificates.

The work is rarely “hard” technically. Most of the time is spent aligning on export format, field mapping, security approvals, and the cutover plan. Plan a few weeks for a typical project. Timelines vary by provider and approval cycles.

Choose a path

• Moving to The Wallet Crew: Move passes to The Wallet Crew

• Moving away from The Wallet Crew: Export passes from The Wallet Crew to another provider

Key constraints (Apple vs Google)

Apple Wallet and Google Wallet have different rules. These rules explain why migrations require coordination and why a test batch matters.

Apple Wallet

Apple Wallet migrations depend on the issuer identity used to sign passes. They also depend on the update “address” embedded in the pass (webServiceURL), because devices call that URL to fetch updates.

When the same issuer identity is kept and webServiceURL is correctly repointed, customers can usually keep the same installed pass.

Google Wallet

Google Wallet migrations depend on which issuer account owns the passes. If the issuer account changes, passes usually need to be re-issued (which implies a new save flow for customers).

When the same issuer account and object IDs are kept, customers can usually keep the same pass.

FAQ

Do customers need to reinstall their pass during a migration?

Usually no. With an “in place” migration (same Apple issuer identity, and Google under the same issuer account), customers keep the same pass and it keeps updating.

What data do we usually need from the previous provider?

The new system usually needs technical identifiers that let it attach to the existing pass.

• For Apple, it’s typically the serial number and authentication token.

• For Google, it’s typically the resource ID (object ID).

How long does a migration usually take?

Plan a few weeks. Most of the time is coordination, not implementation. Time is needed for export, mapping, and a small test batch.

Who needs to be involved?

The current provider and The Wallet Crew. When the brand controls issuer accounts and certificates, its team is involved too.