Existing gift card holders may be able to redeem their balances after a POS change, but only if the old and new systems can support an agreed transfer or the restaurant keeps a workable way to honor the old cards. Do not assume that a card number, a balance file, or a new POS gift card feature is enough on its own.
Before signing, ask both providers to explain how an existing card will be recognized, where its current balance will live, and what staff should do when redemption fails. Get the answers in writing and make them part of your changeover decision.
Start with the guest at the counter
Picture a guest presenting a physical card for dinner on the first weekend after your switch. The server needs to know whether the card is valid, how much remains, and whether it can pay part or all of the check. A manager needs a clear route for exceptions without asking the guest to explain the restaurant’s software change.
That service moment should shape your requirements. List every type of outstanding card: physical cards, digital codes, and any older formats still accepted. For each one, identify the number or code staff use, where the balance is held, and whether guests redeem it in person, online, or both. Ask whether any cards have identifiers that the new system cannot read or accept manually.
Next, decide which result is acceptable. A full transfer may let staff handle old and new cards in one workflow. A fallback may require staff to check and update balances in the old system for a defined period. Either can be workable, but the second adds steps and may require continued access or fees. A plan that leaves staff unable to check a balance is not a finished plan.
This is a stored-value question, separate from moving historical sales records. An old transaction report can help investigate a dispute, but it is not necessarily an up-to-date balance that the new system can redeem.
Compare the complete redemption workflow
Bring the old provider, the prospective POS provider, and any separate gift card provider into the discussion. Ask who controls the balance data and whether provider consent, a processor relationship, or a particular plan is required. Have each party identify its responsibilities in writing; an answer from only one provider may leave an important handoff unresolved.
Use the table to compare the proposed transfer with your current operation. The last column is the decision point: if a provider cannot demonstrate or commit to the result, record the gap and choose a fallback before changeover.
| Checkpoint | Ask the providers | Result to establish |
|---|---|---|
| Card identifier | Can existing numbers or codes be imported and entered or scanned? | Staff can identify the same card without issuing a replacement. |
| Balance data | Can current balances be exported, securely transferred, and matched to identifiers? | Each accepted card has the agreed opening balance. |
| Service access | Which devices, staff roles, channels, plans, or processors support redemption? | The people taking payment can use the intended workflow. |
| Remaining value | How is a partial redemption recorded and checked later? | The remaining balance is visible and usable under the chosen process. |
| Exception | What happens if a card is unreadable, missing from the file, or disputed? | A named person can investigate without guessing at the balance. |
Ask for a demonstration on the devices your team expects to use. Include the role that normally closes checks, not just an administrator account. If online redemption matters, ask to see that workflow separately; success at a counter does not establish what happens online. Consider whether your planned POS hardware can read the card format, and ask how staff should enter a code when a reader cannot.
For the transfer itself, ask what fields the export contains, how balances are matched to cards, who handles duplicate or invalid identifiers, and how the file is protected in transit. Agree on a cutoff: redemptions made after an export can make the exported balance stale. The providers should explain how those changes will be captured or reconciled before the new balances are used.
Request an operational quote for both the transfer and any fallback. Separate one-time setup or data work from ongoing plan, processor, or old-system access charges. Also ask about exception costs, such as investigating unmatched cards. A low transfer quote is not the whole operating cost if the restaurant must keep another system active.
Run a balance transfer and fallback check
The following example is hypothetical. It is a worksheet for a simulated check, not a claim that a particular product supports these steps. Use a provider-approved test environment or demonstration data. The simulation must not charge a real payment method, message a guest, or dispatch a courier.
Suppose a sample card has an opening balance of $38. A simulated dinner check is $29, and the guest chooses to apply $20 from the card. The expected result is a $20 gift card payment, $9 still due on the check, and an $18 card balance. If the remaining $9 is represented as paid in the simulation, use a test-only payment method. Do not use a real card.
- Prepare the record. The manager gives both providers the sample identifier and opening balance. Confirm whether the test represents an imported record or a manually created demonstration record; those are different checks.
- Find the card. A staff member using the intended service role enters or scans the sample identifier. The expected screen shows the matching card and $38 available. If the identifier is rejected, stop and record the result rather than substituting a different card.
- Apply part of the value. Enter the $20 simulated redemption against the $29 check. The expected check or receipt view shows $20 applied and $9 still due. Confirm what the guest-facing receipt would show, if that is part of your required workflow.
- Check the remainder. Look up the sample card again. The expected balance is $18. Ask where that change appears in the gift card report and who can view it.
- Try an exception. Use a separate, deliberately unmatched sample identifier. Confirm that the screen gives staff a clear failure or lookup result. The manager should follow the documented fallback rather than inventing a balance.
- Record the outcome. Write the expected result beside the observed result only after an authorized test. Note the device, role, channel, and whether the record actually went through the proposed import process.
Repeat the relevant checks for a full redemption, an unreadable physical card, and a card whose balance is disputed. If online use is required, simulate that channel separately. A successful demonstration is useful evidence, but it does not settle every outstanding card or prove that the final transfer file is correct.
Training can use these same simulated cases. A live service pilot is different: it involves real guest transactions and should begin only after providers have agreed on the setup, responsibilities, and support route. Staff should know when to pause and call the manager rather than treating a live guest’s card as a practice record.
Set the operating rule before changeover
Assign one person to own the card list and reconciliation, one provider contact for technical issues, and a manager for guest-facing exceptions. Write the rule where staff can find it: which system to check first, what evidence to collect, and who can authorize a resolution. Avoid putting full card identifiers in an unsecured shared note; agree with your providers on a safe way to exchange investigation details.
For a transfer, set acceptance criteria before the final export. At minimum, require the agreed card identifiers and balances to be accounted for, a sample of records to pass the redemption workflow, and unmatched records to have an owner and resolution path. Compare the final balance totals and record counts with the old system, then investigate differences. Matching totals alone are not enough: two individual balances could be wrong while the total still matches.
If the transfer cannot meet those criteria, decide whether the old system can remain accessible for checking and updating balances. Confirm its cost, staff access, support period, and how a redemption there will be reflected in your records. Do not let the same balance be spent independently in two systems. If the providers cannot explain how they prevent or reconcile that situation, pause the changeover decision until there is an agreed process.
Make an exception list for cards with missing identifiers, unclear balances, or disputes. Set a review date for unresolved cases and a point at which the fallback will be reassessed. Ask qualified advisers about any contract, legal, or tax questions raised by the change; the technical migration plan does not settle those matters.
When comparing a restaurant POS system with your wider restaurant management software, keep this worksheet with the quote. Request a POS demo using the sample scenario and your own acceptance criteria, then ask the provider to show how your outstanding cards and exceptions would be handled.
Frequently asked questions
Will old gift cards work automatically after a POS switch?
Not necessarily. The card identifiers and current balances must be usable in the new setup, or staff need an agreed way to honor cards through the old system. Confirm the process with every provider involved.
Is a balance export enough to complete the transfer?
No. The receiving system must be able to match and use the records, and changes after the export must be accounted for. Check individual records and the redemption workflow as well as totals.
What should staff do if an old card is not found?
Follow the written exception process and involve the designated manager. Capture the information needed for investigation through the agreed secure route; do not guess the balance or promise that a transfer succeeded.
