How do I migrate gift card balances from Lightspeed Retail to Shopify without customers losing value?

Why this object is different from everything else in the migration

A gift card is a bearer instrument. The customer holds a physical or digital token with a code printed on it, and that code is the only thing linking them to a balance sitting on your balance sheet as deferred revenue. You cannot email everyone a new code, because you do not know who holds the old ones, and you cannot invalidate the old ones, because in most jurisdictions that balance is a liability you still owe.

Every other object in this migration can be re-derived, re-entered or archived. This one cannot.

Step 1: get the codes and balances out of Lightspeed

Here the series matters enormously, and the answer is good news for X-Series and bad news for R-Series.

X-Series exports gift cards from Reporting > Gift card reports > Export report, and the export contains "Gift card codes, Created date, Last used date, Balance, Status (active, redeemed, etc.), Customer ID and source, Order ID and source, Location ID, Last recipient email" (per Lightspeed X-Series support, September 2026). Full codes, current balances, status. That is everything you need.

R-Series has no equivalent published export path. Lightspeed's own documentation on the reverse journey states flatly, "You can't import customers' store credit, gift cards, or customers' outstanding balances (debt)," and prescribes recreating them manually against an "Account Migration" payment type (per Lightspeed R-Series support, September 2026). If Lightspeed treats gift cards as a manually reconstructed object on the way in, expect the same on the way out and plan a report-driven extraction with your finance team rather than a one-click export.

Step 2: get them into Shopify, which the admin will not do

Shopify's gift card documentation closes the obvious door: "You can't import the gift card CSV to create gift card products," and its own export "includes only the last 4 characters of gift card codes" and "can't be used to recreate cards or migrate them to another system on its own" (per Shopify Help Center, September 2026). Shopify's advice to merchants leaving Shopify is to "issue new codes when needed."

The door that is open is the API. The giftCardCreate mutation accepts an optional code field, and "if you don't provide a code, the system generates a random 16 character alphanumeric code" (per Shopify developer docs, September 2026). Optional means you can supply your own. It requires the write_gift_cards access scope, and it takes initialValue, customerId, expiresOn and note.

So the mechanism is: preserve the original code, set initialValue to the remaining balance rather than the original face value, and put the source system and original issue date in note.

Step 3: or buy the app, because two are live

Two purpose-built apps do exactly this, both verified live on 14 September 2026:

Review counts of 3 and 45 are thin. Treat both as tools rather than vendors, run them against a 20-card sample first, and verify redemption at a real register before loading the full book.

The five checks that make this safe

1. Reconcile the export total to the general ledger before you import anything. The sum of remaining balances in the export must equal the gift card liability in your accounts. If it does not, you have found a problem that predates the migration.
2. Load remaining balance, never face value. A $100 card with $12 left is a $12 card. Loading face value is a cash giveaway that reconciles to nothing.
3. Set initialValue from the export, then sample-test redemption at the register and online before the old system stops accepting cards.
4. Run a short dual-honour window. Keep Lightspeed able to check a balance for two to four weeks after cutover so a staff member holding a card with an unreadable code has somewhere to look.
5. Get a named finance sign-off on the post-import liability figure. This is the one migrated number an auditor will ask about by name.

When NOT to migrate gift cards

• When the balances are not reconciled today. Migration will not clean the ledger; it will freeze whatever is in it.
• When the card population is tiny and the codes are recoverable. Under a few dozen cards, honouring them manually at the register against a spreadsheet is cheaper and less risky than an API load.
• When your legal team has not confirmed expiry handling. Gift card expiry is regulated differently by jurisdiction, and expiresOn is a field you can set wrongly in bulk. Confirm the rule that applies to you before you populate it. This page describes mechanics, not legal advice on unclaimed property or escheatment in your jurisdiction.