Points, tiers, and stored value are three different migrations

One export, one spreadsheet, four kinds of asset. Points, tiers, coupons, and stored value usually arrive together, and it is tempting to move them together: pick a conversion rate, multiply, import, done. That works until a member asks why their tier dropped, why a coupon no longer applies, or where the balance they paid for went.

The four assets do not share a conversion rule, an owner, or a failure mode. They need separate rules, separate reconciliation, and in one case a separate conversation with finance and legal.

Points are a formula, not a number

A points balance is the output of rules: how points are earned, whether promotional points expire before purchased ones, how refunds reverse an earn, how rounding works, and what happens when an account goes negative. If those rules are not written down, the target system will invent its own, and members will notice.

Start by separating point types. Promotional points, points earned from spend, and points purchased or granted as compensation may have different expiry and different value. A single balance hides that mix. If the source keeps only a total, record it as a limitation and expect disputes that cannot be resolved without the ledger.

Then decide the conversion. A ratio such as 100 old points to 1 new point is a commercial decision, not a technical one. It changes what members effectively own, so it needs a stated rule, an effective date, and a way for members to see it. Rounding is part of the rule: rounding down is defensible if disclosed; rounding away small balances silently is not.

Tiers are a status derived from history

A tier is not an asset in the same sense as points. It is a status computed from behaviour: annual spend, points earned, order count, or a manual grant. There are two legitimate approaches, and they produce different outcomes:

• Carry the tier over. Fast and member-friendly, but it grants status without evidence. It can also preserve a tier that the new program no longer offers.
• Recompute from history. More defensible, but it requires complete order history, a defined period (calendar year, anniversary year, or rolling twelve months), and agreement on what happens when history is missing.

Whichever you choose, write down the period, the threshold, the grace period, and the date the rule takes effect. Test what a member sees on their first visit after the switch: the same tier, a lower tier, or an empty state. A silent downgrade is a support incident, not a data detail.

Coupons are instances, not balances

Coupons look like numbers because a report shows a count. In practice each coupon is an instance: a code, a validity window, a scope, a stacking rule, and a single-use constraint. Two systems rarely share code formats or validation logic, so “transfer the coupons” often means “reissue equivalent coupons”.

Inventory them before deciding: valid versus expired, used versus unused, and which ones are tied to a campaign or a specific product. Expired coupons are not a liability and usually should not be reissued. Valid ones need equivalent terms in the new system, or an explicit decision to compensate instead. Converting unused coupons into points is a product change; it needs a notice, not just an import script.

Stored value is money

This is the asset that most often turns a data project into a legal and financial one. A stored-value balance is money a customer has already paid. In many jurisdictions it is treated as a prepaid liability, with rules around refunds, expiry, receipts, tax, and who may hold the funds. Some of those rules may prohibit the transfer you are planning, or require the customer's agreement.

Before designing the import, answer four questions in writing:

1. Who owes the balance after the switch? The old entity, the new entity, or both under an agreement?
2. Is the balance still valid? Check expiry, frozen accounts, negative balances, and balances created by manual adjustment.
3. What happens on a refund? Can the new system refund in the same way, and who bears the cost?
4. What must the customer be told? Notice, consent, and a way to object may be required before the balance moves.

If the answer to the first question is unclear, stop. A technically perfect import that moves a liability to an entity that cannot legally hold it is worse than a delayed migration. Get finance and legal sign-off before the technical design, not after the test batch.

Do not silently convert stored value into points. It changes the nature of what the customer owns, often at a worse conversion, and it is very hard to reverse once members have spent the points.

Reconcile per asset, then total

A single row count tells you that records arrived. It says nothing about whether the values are correct. Reconcile each asset separately:

• Points: source total, target total, variance, and a list of accounts whose balance changed by more than the agreed rounding.
• Tiers: member count per tier before and after, with every move explained by the rule.
• Coupons: valid, expired, used, and reissued counts, plus the terms of the replacement.
• Stored value: total liability before and after, per batch, with the owner of every variance named.

Then define acceptance criteria before the test batch: which variance is tolerated, which must be zero, who signs off, and what happens if sign-off is withheld. A rollback or compensation plan belongs in the same document. If the old system is switched off before the new totals are accepted, the rollback option disappears with it.

What an assessment should return

A useful readiness assessment is not a single feasibility sentence. It returns a per-asset rule set with a version, the counts that support it, the exceptions with named owners, the acceptance criteria, and the open questions that only the merchant, the platform, or a lawyer can answer.

It should also say what is not in scope. “Stored value is excluded until the liability question is resolved” is a better answer than a plan that quietly assumes it away.

AcrossFlow works through these asset rules with merchants before a migration is scoped. The identity question decides whether members can be recognised; the asset rules decide whether what they own survives the move. Both have to be answered before anyone promises continuity.