You may be able to retain order history, table identifiers and menu data when you replace a QR ordering provider, but access is not the same as a usable export. The answer depends on your contract, the outgoing provider’s export options and what the replacement system can import. Check all three before setting a cancellation date.
Start with a short list of records you need for operations and reporting. Then ask each provider to show you a sample file and explain what happens to access at the end of the contract. Keep a separate copy of any records you are entitled to retain; do not assume the new system will recreate your old reports.
List the records you need to keep
Order history is more useful when it includes the details behind each total. Ask for order IDs, timestamps, items, quantities, prices, discounts, payment status, refunds and the table identifier attached to each order. Also ask whether canceled orders and corrections appear, and whether totals can be reconciled with your existing reports.
Decide who needs guest information and why before requesting it. A record may contain contact details or payment-related references that are not needed for your migration. Ask what is included, who can receive it and how it will be transferred securely. A payment status or transaction reference is different from access to a guest’s payment credentials.
Table data needs its own inventory. List each physical table, its location, the old system’s identifier and any service area or routing label associated with it. A party of guests is not the same thing as a physical table: one party may move or occupy more than one table, and the same table can serve many parties in a day. Ask whether the export preserves those distinctions.
Menu data can include item names, prices, descriptions, categories, options, modifiers and availability settings. An item list without modifier relationships may still be useful, but staff may have to rebuild choices such as sides or cooking preferences. Ask whether images and menu schedules can be exported too, and whether the receiving system accepts them.
Consider other records only if they matter to your operation: staff assignments, service areas, order notes or reporting categories. For each one, decide whether you need a searchable history, a file for reference or data actively loaded into the new system. Those are different outcomes.
Compare export terms and the practical alternatives
Use the worksheet below in a meeting with both providers. The alternatives are not equally convenient: an archived file may preserve evidence of past orders without making those orders visible in the new dashboard.
| Record | Ask the outgoing provider | Ask the replacement provider | Fallback if import is unavailable |
|---|---|---|---|
| Order history | Can we export line items, statuses and refunds together? | Can historical orders be imported and searched? | Keep a readable, secure archive and use the new system for future orders. |
| Table identifiers | Can we export IDs with location and service area? | Can old IDs be mapped to new table records? | Maintain a crosswalk for historical reporting. |
| Menu and modifiers | Are item-option relationships included? | Which fields can be imported? | Rebuild missing choices and check them before service. |
| Access and delivery | What is the deadline, format and delivery method? | How long does setup and validation take? | Export earlier and retain access long enough to check the files. |
Ask for the file format and a sample with representative relationships, not just a screenshot. A spreadsheet or CSV may be easy to inspect, but related records might arrive in separate files. Ask how those files connect. If the provider offers an API or a custom export, ask who will do the work and what it will cost.
Get the access deadline in writing. Does dashboard access end when notice is given, on the final service date or later? Is a final export available after cancellation? Ask how long the provider retains data and whether it charges for retrieval. If contract wording is unclear, ask a qualified adviser to review it rather than relying on a sales conversation.
Compare written quotes for export, import, setup and any temporary overlap between systems. Separate fixed charges from usage-based charges and possible exception work, such as repairing an incomplete menu file. Payment processing is a separate cost from software and migration work. For Fleksa’s published pricing, see plans, checked November 2026; confirm the quote and setup for your restaurant.
Map physical tables to replacement codes
A new QR code needs to point to the right table in the replacement system. Keep a crosswalk with the old ID, physical location, new ID and a check status. If table names have changed over time, include the dates or service periods to which the old names apply. This gives staff a way to interpret an old order even if the new system uses different identifiers.
Hypothetical example: A restaurant has six physical tables in its dining room. The outgoing system labels a window table W-2; the replacement labels the same physical table D-04. The crosswalk records W-2 → D-04 and notes “window, left side.” An old order remains associated with W-2 in the archive; the crosswalk explains its location without changing the historical record.
If two physical tables are regularly pushed together, keep their individual identities in the list and ask how a combined party will be handled. The six tables remain six physical tables, even when one party uses two of them. Also ask how the replacement handles a moved party, a reopened table and an order without a table assignment. Do not assume historical table IDs can be imported merely because new codes can be created.
Walk the room with the crosswalk before making new codes active. Confirm the label and location for each table, including outdoor or seasonal areas if you use them. Keep old and new identifiers clear to staff during the transition. Physical sign replacement is only one part of the job; a correct sticker still needs to resolve to the correct table and workflow.
For the wider service decision, the guide to where QR ordering fits in table service can help you decide what guests and staff should do at the table. If orders also go to a restaurant POS system or a kitchen display system, include those handoffs in your questions to the provider.
Set an acceptance test and stage the cutover
Choose one representative historical order and compare it with the export. Use a record you are authorized to access, and limit guest details in shared copies. Check the order ID, timestamp, items, quantities, total, payment status and old table ID. If the order was refunded or changed, check that the final state and relevant adjustment are understandable. Then look up the table in your crosswalk.
Record the result in plain language: “The exported order matches the source record on these fields; the table maps to this location; these fields are missing or unclear.” If a field fails, ask for a corrected export or decide whether the archive is sufficient. One matching order does not prove the whole export is complete, so also compare record counts and totals for an agreed period and investigate differences.
Next, run a simulated service check in a safe practice environment. Scan or otherwise open the replacement table flow for a mapped table and use a test order to check the table label, menu choices and staff handoff. Confirm in advance that the simulation cannot take a real card payment, send a guest message or dispatch a courier. If the provider cannot isolate those actions, agree on a safe alternative before practicing.
Write acceptance criteria before the check: the selected physical table displays the intended new ID; the test items and modifiers are correct; staff can identify the intended handoff; and the expected payment state is clear without a real charge. Record passes, failures, owners and fixes. If a required handoff is unavailable, stop and resolve it rather than marking the migration complete.
A live service pilot is a separate decision. After the simulated checks pass, agree which tables and service period will use the replacement, who will watch for problems and how staff will handle orders if something fails. Brief the team on the fallback, including how to serve a guest who cannot or does not want to use a phone. Keep the outgoing access available for the agreed overlap where possible, and reconcile orders from each system after the pilot. A staged switch reduces uncertainty; it cannot guarantee uninterrupted service or that no order will be missed.
Next step: Take your record list, table crosswalk and acceptance criteria to both providers. Compare them with the workflows available in Fleksa QR ordering, where guests can scan, order and pay in a browser without downloading an app. Ask how your historical records and table setup would be handled before agreeing on a switch date.
Frequently asked questions
Can I import every old QR order into a new system?
Not necessarily. Ask what the outgoing provider exports and what the replacement imports. If historical import is unavailable, a secure, readable archive may still preserve records for reference.
Should I cancel before requesting my data?
First confirm the export process and access deadline in writing. Request and check the files while you can still compare them with the source system, and allow time to resolve problems.
Will a new QR code preserve my old table ID?
Do not assume it will. Ask whether old IDs can be mapped or imported. Keep a crosswalk between the old ID, physical table and new ID so staff can interpret historical orders.
