Before switching ordering vendors, ask for a written inventory of the customer and order information available to your restaurant, the terms governing its use, and a sample of the export. You may be able to take some records but not others, and an exportable email address is not automatically an address you can use for marketing.
The answer depends on your contracts, how each order was placed, what guests were told, and the applicable rules. Have qualified counsel review the intended uses. Meanwhile, use a synthetic file to check whether the next vendor can actually import the fields you need.
Inventory the data and the terms attached to it
Start with the places where orders originate. A restaurant may receive direct orders through its own site and separate orders through a marketplace. The records may look similar on a screen but be subject to different agreements and access limits. List each source separately rather than assuming one export covers the whole business.
Ask the current vendor for a field list and the relevant contract terms. Ask your staff which records they use for service, refunds, reporting, and repeat-guest communication. Then ask the prospective vendor what it can accept. These answers give you three different views: what exists, what you may use, and what can move into the new system.
For each source, inventory at least:
- Contact details: name, email, phone number, and delivery address, where collected.
- Order history: order date, items, modifiers, fulfillment method, totals, status, and refunds.
- Marketing records: opt-in status, channel, date, source, and the wording shown to the guest, if retained.
- Account and preference data: guest identifiers, saved preferences, and any loyalty balances or rewards.
- Records to handle separately: payment information, sensitive notes, and other fields that may not be appropriate to export or import.
Do not assume that seeing a field in an admin screen means you can export it. Likewise, a clause describing data ownership may not settle every question about access, permitted use, retention, or third-party restrictions. Ask who controls the data, which agreement applies to each source, and whether there are fees or a deadline for an export. Give any disputed terms to counsel rather than relying on a vendor's sales summary.
Request a sample export and a usable schema
Ask the outgoing vendor for a synthetic or fully de-identified sample, a field dictionary, and the export format before requesting the full file. The dictionary should explain column names, data types, identifiers, status codes, date formats, and how separate files relate to one another. A spreadsheet of contacts without those details can be difficult to interpret and risky to combine with another record.
Use the following worksheet to turn broad promises into decisions. The examples are hypothetical; they do not describe any vendor's actual export or import capabilities.
| Record | What to request | Question for the new vendor | Decision if unsupported |
|---|---|---|---|
| Guest contact | Name, email, phone, source, and guest ID | Can each field and the source be imported? | Keep only an approved archive; collect details again where appropriate. |
| Order history | Order ID, date, items, totals, status, and guest ID | Can orders link to the correct guest? | Retain a searchable archive if permitted; do not assume history appears in the new system. |
| Marketing permission | Channel, status, timestamp, source, and notice wording | Can permission evidence and opt-outs be preserved? | Do not use the list for that campaign until permission and handling are resolved. |
| Loyalty data | Balance, reward rules, and redemption history | Can balances and actual redeemable rewards be transferred accurately? | Agree on a separate guest-facing transition plan before changing programs. |
The worksheet separates access from usefulness. A file can contain order totals but omit modifiers, for example. That may be enough for a historical sales lookup but not for understanding what a guest ordered. Similarly, a points balance is not necessarily an available reward: ask what each balance entitles a guest to redeem and whether that entitlement survives the move.
Also request the export's date range, expected delivery time, file size, encoding, and a list of excluded fields. Ask whether updates made after the initial export can be provided in a later file. Check whether deleted or opted-out contacts are represented and how corrections are handled. If the vendor charges for extraction or offers different export formats, get those terms in writing.
A practical decision might be to import approved contact records but keep older order history in a separate, access-controlled archive. That avoids forcing incomplete history into a new system. First confirm that retaining and accessing the archive is permitted, how long it should be kept, and who will handle guest requests concerning those records.
Review consent and intended use with counsel
Separate operational use from marketing. A contact collected to complete an order may be useful for resolving an issue with that order. Whether the restaurant can use the same contact for an email promotion is a separate question. Record the intended purpose for each group of data and review it with qualified counsel, along with the notices, agreements, and permission evidence that apply.
Consider a hypothetical export with 60 email addresses. The permission records show 35 opted in to email marketing, 10 opted out, and 15 have no recorded email preference. Those figures describe the file, not permission to send. Ask counsel how the restaurant should treat each group and what evidence is needed. Preserve the opt-outs in a form the next system can honor; do not relabel the 15 unknown records as opted in simply because an address exists.
Check the details behind the status. Was the preference captured for email, text, or another channel? When and where was it recorded? What notice did the guest see? Can a later withdrawal override an earlier opt-in? If the export only says “subscribed” without a date or source, ask the vendor for the underlying evidence and discuss the gap with counsel.
Apply the same care to order notes. A free-text delivery note could contain more personal detail than the new system needs. Ask whether notes can be excluded or reviewed before transfer. Do not move full payment card details as part of a general customer spreadsheet; ask the relevant payment providers about their supported process for any payment-related transition.
Use a vendor portability questionnaire and a safe import test
Send the same questions to both vendors and compare their written answers. The outgoing vendor should explain what it can provide; the incoming vendor should explain what it can receive, retain, display, and use. Ask each to identify any work, charges, or dependencies outside its responsibility.
- Which fields and order sources can be exported or imported, and which are excluded?
- What formats, field definitions, identifiers, and sample files are available?
- Can guest contacts be linked to their orders without creating duplicate profiles? How are conflicts handled?
- Can marketing preferences, opt-outs, dates, and evidence be preserved by channel?
- Can historical orders be searched, and will item modifiers, refunds, and statuses remain understandable?
- Can loyalty balances and redeemable rewards be represented accurately? What happens to unsupported rules?
- What validation report shows accepted, rejected, and changed records? Can an import be reversed?
- Who performs the work, what does it cost, and when will the export and any follow-up file be available?
- How are files transferred, who can access them, and when are temporary copies removed?
Next, build a small fictional dataset with invented names, addresses, orders, and preferences. Include a duplicate-looking guest, a missing field, an opted-out contact, and an order linked to a guest ID. Agree on the expected result for each row before the test. For example, an opted-out fictional contact should remain opted out; a rejected order should appear in the validation report, not silently disappear.
Run this as a simulation in a suitable test environment with the vendors' help. Do not use real guest data, make a real card payment, send a guest message, or dispatch a courier. Review the imported fields and rejection report against the expected results. A successful simulation checks the mapping for those cases; it does not prove that every real record will import correctly. Decide how the team will review exceptions before requesting or transferring an approved production file.
Keep the portability decision distinct from the eventual service cutover. For broader buying criteria, see the online ordering buying guide and consider how your restaurant website connects guests to ordering. Use the checklist with your current vendor, then ask Fleksa about restaurant online ordering, the import questions above, and verified US availability for your location.
Frequently asked questions
Can I export every customer who ordered from my restaurant?
Not necessarily. Access and permitted use can differ by ordering source and agreement. Request a source-by-source field list and have counsel review the relevant terms and intended uses.
Does an email address in an export mean I can send promotions?
No. An address alone does not establish permission for a campaign. Check the channel-specific preference, its history, and any opt-out, then review the intended use with counsel.
What if the new system cannot import old orders?
Ask whether an approved, searchable archive can meet your operational needs and who will maintain it. Confirm retention and access requirements before keeping a separate copy.
