Product
Operation types
Pricing
Compare
Resources
Log in See a 15-minute demo ESEN
Guide · 8 min

A guide to backing up and exporting the hotel restaurant’s data without depending on the provider

The hotel restaurant’s data belongs to the hotel, not to the system that stores it. This guide covers what to back up, which format to demand and how often to do it, so switching providers is never a leap into the dark.

One day, for whatever reason, you will want to change your hotel restaurant’s system. Maybe you grew, maybe the provider raised the price, or maybe you simply found something better. That day you will find out whether your data was really yours, or whether it was living on loan inside a system that never planned to let you leave.

Why this is not a systems issue, it is an ownership issue

Everything that happens in your hotel’s restaurant generates data: every ticket, every room charge (Room charge), every shift close, every recipe, every inventory movement. That data describes your business, not the software provider’s business. The question that decides whether it is truly yours is not who stores it, but how easily you can pull it out complete, in a format any other system can read.

A serious provider should have no interest in trapping you. If the only way out is to request a special file, wait for weeks and receive something incomplete, that is not a technical accident: it is an exit barrier disguised as support.

What to back up, in order of importance

Not every piece of data carries the same weight if you ever switch systems or need to rebuild lost information. This is the order worth thinking about them in.

DataWhy it mattersHow often to back it up
Sales by ticket, with date and revenue centerIt is your fiscal and business history; without it you cannot rebuild a monthDaily
Room charges with their folioLinks restaurant consumption to the guest who generated itDaily
Menu catalog, prices and recipesIt is the business knowledge: without it, migrating means retyping everything by handEvery menu change
Shift closes by revenue centerIt is the accounting evidence the controller and the auditor will ask forDaily
Inventory and warehouse movementsExplains waste, costs and purchases; without history, costing turns into guessworkWeekly
Corporate agreements and discount rulesThese are live commercial agreements; losing them causes disputes with companiesEvery agreement change
Priority guide for hotel restaurant backups. Adjust the frequency to your real volume.

Open formats: the difference between a real backup and a decorative one

It is not enough for the system to say it “exports data”. What format it uses matters. A file in a proprietary format that only the same system can read again is not a backup; it is a security copy that only works as long as you keep paying the license.

  • CSV or Excel for sales tables, ticket by ticket, with clear columns: date, time, revenue center, folio when it applies, net amount, tax, tip, payment method.
  • JSON or XML for more complex structures, such as the menu catalog with its modifiers, or corporate agreements with their rules.
  • PDF for anything that needs to stay exactly as it looks, such as signed shift closes or fiscal receipts.
  • Never accept that the only possible export is “a screenshot” or a printed report: that is not data another system can read, it is a photograph.

The question every provider should be asked

Before signing with any system for your hotel’s restaurant, ask to see a real export, not a promise of one. Ask them to show you a full month of sales, in the format they claim to offer, and open the file yourself in a spreadsheet. If the provider hesitates, stalls or offers to schedule a call to “walk you through it”, you already have your answer.

How often to actually back up

A backup that only exists in theory, stored “somewhere” that nobody has tested, is not a backup. Frequency depends on the data, but the discipline is always the same: automate what you can and verify what you automate.

  1. Sales and room charges: automatic daily export, right after the shift close, without anyone having to remember to request it.
  2. Shift closes by revenue center: saved as PDF the same day, with a copy outside the system that generated them, for example in the controller’s email.
  3. Catalog, recipes and prices: export every time the menu changes, plus a quarterly copy even without changes, as a safeguard.
  4. Inventory: weekly export, timed with the physical count, so the system can be checked against what is really in the storeroom.
  5. Corporate agreements: a signed copy of the commercial agreement and an export of its rules every time one is signed or renewed.

What to export before switching systems

Once the decision to switch providers is made, periodic backups are not enough: you need a full export, built specifically for migration. The complete checklist for switching point of sale systems without closing the restaurant is covered in this guide (A checklist for switching point of sale without closing the hotel restaurant). Here is the bare minimum that cannot be missing.

  • Sales history for at least the last twelve months, so the new system can be compared against the same period last year.
  • Full catalog with current prices and modifiers, so nobody has to retype the menu by hand on switch day.
  • Database of active corporate agreements, with their discount rules and validity dates.
  • Room charge history, useful if a guest disputes a charge after the migration.

Where the backup should live

Storing the backup in the same place the original system lives protects nothing: if that place fails, you lose the system and the backup at the same time. The rule serious systems teams follow is simple: at least one copy outside the original system and outside the physical property.

  • A cloud copy, separate from the point of sale provider, so a problem with the provider does not also take down the backup.
  • A local copy, on a machine at the hotel, so work can continue even without internet the day it is needed.
  • A clear owner responsible for checking that the automatic backup actually ran, not just for configuring it once and forgetting about it.

How this information is protected in transit and at rest, including who inside the hotel can see it, is explained on the security page (Security and control).

An illustrative example with numbers

The figures below are made up to show the calculation; they are not data from any property. Picture a hotel restaurant that generates 45 tickets a day on average, with an average ticket of 380.

ItemValue (illustrative example)
Average tickets per day45
Average ticket380
Approximate daily sales45 × 380 = 17,100
Days in a year365
Approximate annual sales without a reliable backup17,100 × 365 = 6,241,500
Illustrative example. The figures are invented to show the scale of what is at stake, not an industry average.

That number, over six million in annual sales in the example, is what is at risk if a poorly planned system switch leaves you without access to twelve months of history. It is not a number you pay again; it is a history you can no longer rebuild, and one you need to compare next year against this one, to defend a cost to the controller, or to answer a tax audit.

Signs your current backup does not work

Before you ever need it in an emergency, it is worth running an honest test. These are the signs that the backup you think you have is, in reality, decorative.

  • Nobody at the hotel has opened the backup file in the last three months to confirm it holds readable data.
  • The only way to export is to ask the provider’s support for a favor and wait for a reply by email.
  • The file they hand you comes in a format only the same system can open again.
  • Nobody knows for sure whether the automatic backup still runs after the last configuration change.
  • The backup lives only on the same server or the same account as the original system.
In short

The hotel restaurant’s data is yours, and it must be able to leave in an open format any other system can read. Back up sales and room charges daily, test the export before you need it, and keep at least one copy outside the system and outside the property.

What to do this week

  1. Ask the current system for a real export of last month’s sales and open it in a spreadsheet.
  2. Confirm whether the automatic backup of sales and room charges is active and who reviews it.
  3. Check what format the menu catalog exports in and whether it can be read outside the system.
  4. Ask where the backup physically lives and whether there is at least one copy outside the hotel.
  5. If you never have, restore a test copy to confirm it actually works.

Inn Restaurant lets you export sales, room charges, catalog and closes in open formats at any time, without a support ticket in between. If you want to see a real export during the fifteen minute demo (contact), just ask for one.

Your hotel’s restaurant already sells well. Now the hotel needs to know it.

Fifteen minutes, with your menu and your tables. Nothing to install.

See a 15-minute demo
We use the minimum to make the site work and to know which pages are useful. You can reject the rest.