POS Loyalty Migration Guide 2026: Keep Earned Rewards

A regular customer has earned 180 points before your POS change. On opening day with the new system, the cashier finds the customer but sees zero points. The contact import succeeded; the loyalty migration did not. That distinction should be settled before you choose a replacement POS, not during a checkout dispute.

This guide explains how to compare POS loyalty migration proposals in 2026. It focuses on preserving earned value, matching customers, testing redemptions, and setting a controlled changeover. POSadvice.com helps you compare POS systems. We are a national research and comparison site, not a loyalty platform or migration service.

Separate customer records from reward obligations

A customer directory and a loyalty ledger serve different jobs. A directory identifies people and may hold contact details, notes, and marketing preferences. The ledger records points earned, points spent, adjustments, and possibly issued rewards. Moving names and email addresses does not establish that the new platform understands any of those reward events.

Inventory the pieces of your current program: available points, already-issued coupons, free-item rewards, tier status, expiration dates, pending points, returns awaiting adjustment, and customer identifiers. Record which pieces the destination can import directly, which require a conversion, and which need a separate process. Avoid a vague acceptance condition such as “all customer data transferred.”

Gift cards, store credit, and paid memberships should have their own reconciliation plans. They may live beside loyalty in an interface, but that does not make them interchangeable. For the gift-card workstream, use our POS gift card migration guide rather than assuming a points importer will handle stored balances.

Comparison table: loyalty migration approaches

These are implementation patterns, not promises that every POS offers all four. Ask the provider to identify exactly which method is included in its proposal. If a third party performs the work, the contract should identify who resolves a missing balance and who pays for rework.

What current documentation actually establishes

Square’s customer-directory documentation explains bulk imports through its Dashboard, field assignment, and summaries of imported, matched, and failed customer rows. That is useful evidence for directory preparation. It is not, by itself, proof of a turnkey import for your existing loyalty balances, coupons, or tier history.

Square’s Loyalty API documentation separately describes accumulating points, adjusting points outside the normal purchase flow, and recording loyalty events. Its adjustment operation uses an account identifier and an idempotency key, which helps an integration distinguish a retry from a new operation. These capabilities can inform an implementation discussion; they do not establish that a custom migration is included in a POS subscription.

The same separation appears in Shopify’s customer CSV documentation: order information cannot be imported through the customer CSV, and the Total Spent and Total Orders columns are not imported with customer details. If a proposed loyalty program bases tiers on historical spend, ask how the implementation will obtain and use that history. A populated customer profile is not sufficient evidence.

Use these documents to ask precise questions, not to infer unsupported compatibility between products. Require the destination loyalty provider to confirm eligible regions, account requirements, source formats, and supported reward types for your particular migration.

Build the source-of-truth export before signing

Ask the current provider for a sample export while your account remains active. Include a stable customer ID, available points, currency where monetary rewards exist, reward identifiers, and a timestamp for the snapshot. Preserve the unedited original and work from a copy. An export that contains only phone numbers and a total might be usable, but it leaves more matching questions to resolve.

Check for duplicate profiles, missing identifiers, shared phone numbers, international number formats, and changed email addresses. Do not automatically combine accounts because names look alike. Document the matching rule and send ambiguous records to an exception list with a named reviewer. Keep the old-to-new ID mapping so later disputes can be traced back to the source.

Preserve marketing preferences separately from reward membership. A customer having a points balance does not establish permission to send promotional messages. Square’s documented directory import behavior, for example, does not allow previously unsubscribed customers to be resubscribed through that import tool. Your migration should preserve the relevant preference records rather than silently treating every customer as a new subscriber.

Convert value deliberately when point rules change

Matching the numeric balance is not always the same as preserving the benefit. Suppose an illustrative old program grants a $5 reward at 100 points and a new program grants the same reward at 50 points. Moving 100 old points as 100 new points would double the customer’s progress under those simplified rules. Moving half the points would preserve that particular threshold relationship.

Real programs are more complicated. Free items, minimum purchase requirements, product exclusions, tier bonuses, and expiration policies can break a simple ratio. Ask the provider to show a conversion table for several realistic customers: someone just below a reward, someone holding an issued reward, and someone with multiple available rewards.

Decide how to handle fractional points before loading data. Do not round different batches inconsistently. Keep the original balance, conversion rule, resulting balance, and approved adjustment in the migration record. Describe changes in plain language to customers, and do not present a change that reduces a promised benefit as a purely technical upgrade.

Run a representative pilot, not only a clean sample

A pilot should include ordinary accounts and difficult cases. Select a customer with no points, one with a large balance, one with a changed identifier, one with an outstanding reward, and one with a recent refund. Include any relevant locations and channels. Use controlled test data where possible; share real customer records only through the agreed protected implementation channel.

For every test account, confirm the directory match, available points, issued rewards, and tier treatment. Then perform the actual operations: earn points on a qualifying purchase, redeem a reward, cancel a transaction, and process a return. Check the resulting event history. A correct opening balance can still become wrong after the first refund.

Also test a retry. If the importer is interrupted and restarted, it should not add opening points twice. Ask whether the tool sets a balance, adds an adjustment, or imports events. Those methods behave differently. The implementation team should demonstrate a supported way to identify already-processed records and safely resolve failures.

Make acceptance criteria measurable. For example, require every source account to be either matched and reconciled or listed as a documented exception, with no unexplained aggregate point difference. Customer counts alone are not enough: 100 correctly created profiles can still contain 100 incorrect balances.

Plan the changeover around one active reward ledger

Choose a cutoff time and record its timezone. Identify who stops old-system accrual and redemption, who obtains the final export, who loads the new ledger, and who authorizes reopening. If sales must continue, specify how transactions after the snapshot will be captured and reconciled. A vague promise to “sync it later” creates an avoidable gap.

Do not leave both systems independently able to spend the same opening value. A transition period may be necessary, but it needs one authoritative redemption process and a record of every exception. Train staff to escalate an uncertain balance rather than create an undocumented goodwill reward that obscures what actually went missing.

Agree on rollback criteria before launch. If an import fails, preserve the failure report and avoid repeatedly reloading the file without understanding whether points were already added. Reverting to the old system also requires accounting for any new rewards earned or redeemed after the switch. A rollback is a controlled reconciliation, not simply changing which tablet is used.

Pros and cons of migration versus restarting

Pros of preserving the program: customers retain earned benefits, staff can explain continuity, and the business avoids treating longstanding members as if they had never participated. A well-documented migration also creates an opportunity to resolve duplicate accounts and record ownership more clearly.

Cons and costs: old reward types may not map cleanly, history may remain in a separate archive, and reconciliation takes time. A custom integration may need ongoing support. The new platform’s attractive earning rules do not remove those implementation obligations.

Starting a new program can be operationally simpler, but it does not answer what happens to existing promises. If restarting is the chosen approach, establish a clear and appropriate treatment for outstanding benefits and communicate it before launch. Do not select a restart merely because a provider’s standard onboarding package ignores migration.

Compare complete migration quotes

Ask for separate prices for source extraction, data cleanup, mapping, test loads, final load, training, exception resolution, and post-launch support. Specify whether multiple attempts are included. A proposal that lists “customer import” without mentioning points and rewards should not be priced as a complete loyalty migration.

For a planning example only, assume $400 in implementation charges, ten hours of internal data review at $30 per hour, and six hours of training at $25 per hour. That totals $850 before recurring loyalty software, messaging, taxes, or other fees. These invented budgeting inputs illustrate the calculation; they are not market rates or an offer from any provider.

Give all bidders the same counts: active members, total points, reward types, locations, channels, and known exceptions. Ask who owns the loyalty ledger after launch and how you can export it if you leave. The system that imports today’s balances but makes the next move opaque may simply postpone the problem.

Choose the system that can prove continuity

Use our POS demo buying guide to structure the broader evaluation, then add the migration scenarios in this article. Prioritize documented mapping, a successful pilot, repeatable reconciliation, and a named support owner over an unsupported promise that everything transfers automatically.

POSadvice.com helps you compare POS systems and provider proposals. Get free POS quotes with your loyalty migration requirements attached, and ask each provider to explain exactly how customers will earn and redeem on the first day.

Editorial method: buying criteria and illustrative scenarios, with linked official documentation checked October 9, 2026. This is not a hands-on product test. Confirm current capabilities and charges in your written provider proposal.