Pass migration

Move existing passes to or away from The Wallet Crew, without breaking updates for customers.

Use pass migration when you want to change the system that manages your 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. Your goal is continuity: the pass stays valid, and updates keep working.

In most cases, you can migrate without impacting customers.

If you plan the switch and test 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. You validate the flow with a small batch, then you cut over the remaining passes.

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 your setup

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

2

2) Export pass technical identifiers

You need the identifiers that let the new system 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 so you can iterate fast.

4

4) Cut over, then monitor

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

Coordination and timeline

A migration requires coordination between parties. It is usually your current provider and The Wallet Crew, with your own team involved when you control 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 your 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.

If you can keep the same issuer identity and correctly repoint webServiceURL, 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, you usually need to re-issue passes (which implies a new save flow for customers).

If you keep the same issuer account and object IDs, customers can usually keep the same pass.

FAQ

Do customers need to reinstall their pass during a migration?

Usually no. If you migrate “in place” (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?

You usually need technical identifiers that let a new system 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. You need time for export, mapping, and a small test batch.

Who needs to be involved?

You need your current provider and The Wallet Crew. If you control issuer accounts and certificates, your team is involved too.