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.
| Data | Why it matters | How often to back it up |
|---|---|---|
| Sales by ticket, with date and revenue center | It is your fiscal and business history; without it you cannot rebuild a month | Daily |
| Room charges with their folio | Links restaurant consumption to the guest who generated it | Daily |
| Menu catalog, prices and recipes | It is the business knowledge: without it, migrating means retyping everything by hand | Every menu change |
| Shift closes by revenue center | It is the accounting evidence the controller and the auditor will ask for | Daily |
| Inventory and warehouse movements | Explains waste, costs and purchases; without history, costing turns into guesswork | Weekly |
| Corporate agreements and discount rules | These are live commercial agreements; losing them causes disputes with companies | Every agreement change |
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.
- Sales and room charges: automatic daily export, right after the shift close, without anyone having to remember to request it.
- 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.
- Catalog, recipes and prices: export every time the menu changes, plus a quarterly copy even without changes, as a safeguard.
- Inventory: weekly export, timed with the physical count, so the system can be checked against what is really in the storeroom.
- 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.
| Item | Value (illustrative example) |
|---|---|
| Average tickets per day | 45 |
| Average ticket | 380 |
| Approximate daily sales | 45 × 380 = 17,100 |
| Days in a year | 365 |
| Approximate annual sales without a reliable backup | 17,100 × 365 = 6,241,500 |
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.
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
- Ask the current system for a real export of last month’s sales and open it in a spreadsheet.
- Confirm whether the automatic backup of sales and room charges is active and who reviews it.
- Check what format the menu catalog exports in and whether it can be read outside the system.
- Ask where the backup physically lives and whether there is at least one copy outside the hotel.
- 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.
More guides
How to evaluate the security of a point of sale for a hotel before you sign
Before you sign with a vendor for your hotel restaurant, three questions matter more than price: where permissions live, whether the audit log can be edited and what is encrypted. Here is the guide to asking them well.
The first thirty days with the new system in the hotel restaurant: what to measure each week
The day of the switch is not what determines whether the new system worked. It is the month that follows. Here is what to check week by week in your hotel restaurant to reach the first monthly report with confidence.
How to capture the menu in the new system with the categories you will report on
Capturing the menu in the hotel restaurant is not just typing names and prices. It is deciding, from day one, how the report will look six months from now. Here is the right order so you do not have to redo it all later.
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.