Migrating history from the previous system: what to keep active, what to archive, and what to retain

When your hotel restaurant switches systems, someone will ask what happens to the years of history sitting in the old one. The right answer is neither “migrate everything” nor “start from zero”. It is sorting the history into three separate buckets, each with a clear rule for what to do with it.

Why migrating everything is as big a mistake as migrating nothing

Migrating all the history from the previous system, with no filter, drags into the new one the same categorization mistakes, the same discontinued dishes, and the same badly closed checks you had been carrying for years. A new system is the one real chance you will get to start with clean data; wasting it by copying the old mess as-is means giving up that chance before ever using it.

On the other hand, migrating nothing has its own cost. The controller loses the ability to compare this month against the same month last year, which is the most useful comparison there is because it strips out seasonality. And if a guest or a tax authority asks about a transaction from eight months ago, “we don’t have that data because we switched systems” is not an acceptable answer.

The first bucket: what moves into the active new system

This bucket is small on purpose. It is the data the new system needs to operate from day one without the team having to recapture basic information that already exists.

• The current menu, already with the correct categories defined (/blog/como-capturar-la-carta-en-el-sistema-nuevo-con-las-categorias), not the full menu with dishes discontinued years ago.
• Active corporate agreement client data, with their current terms, not agreements that already expired.
• The current team’s users with their roles, not the history of employees who no longer work there.
• The restaurant’s active tables and revenue centers, with their correct configuration.

What should not go here

Any data that needs cleanup before use does not belong in this bucket. If a dish has the wrong category in the old system, fix it before migrating, do not carry it over expecting to fix it later: that “later” almost never comes.

The second bucket: what gets archived for reference

This bucket is the sales history, shift closes and room charges from periods already closed. You do not need it available in the day-to-day new system, but you do need to be able to look it up when the controller builds the year-over-year comparative report or when someone asks about a past transaction.

1. Export the full sales and shift close history from the previous system in a readable format, such as a spreadsheet or an exportable database.
2. Verify the export includes the breakdown by revenue center, not just the hotel’s total.
3. Save the file somewhere accessible to the controller, not only on the computer of whoever did the migration.
4. Document which period each exported file covers, so nobody has to open each one hunting for the date.
5. Confirm with the previous provider that the export is complete before deactivating access to the old system.

The difference between this bucket and the first one is that categorization cleanliness does not matter here, because you will not be operating with this data, only looking it up. What matters is that the export is complete and readable a year from now, not in a format only the old system could open.

The third bucket: what is kept for legal obligations

This bucket is not optional and does not depend on your judgment. There are tax receipts, tax records and room charge documentation that your hotel must keep for the period your country’s tax authority requires, regardless of whether the system that generated them is still active.

Before deactivating the previous system, confirm with your accountant or tax advisor the exact retention period that applies in your country, because it varies. Keeping too much is never a problem; keeping too little is, and it gets discovered exactly when it can no longer be fixed.

It is worth asking for this confirmation in writing, not verbally in a hallway, because the deadline can change from one fiscal year to the next and different document types sometimes carry different deadlines within the same country. A short email from the accountant listing the deadlines by document type is more useful the day the authority asks than the memory of whoever did the migration two years earlier.

The legal backup for the guest

There is one type of data that deserves separate mention: the room charge (Room charge) records confirming that the guest authorized that consumption. If a guest disputes a charge months after their stay, and the system that generated that record no longer exists or has no backup, the hotel loses the dispute for lack of proof, regardless of whether the charge was legitimate.

This backup does not need to live in the active new system, but it does need to be accessible in a format someone can open without depending on the old system. A file exported in a standard format, saved with a backup copy, serves this purpose without needing to keep the previous system running forever.

An illustrative example of how history gets distributed

The figures below are made up to show the decision criteria; they do not correspond to any real property.

In the example, of the 205 dishes that existed in the old system, only 85 move into the active new system. That reduction is not a loss of information: it is the difference between a new system that starts clean and one that drags twenty years of unfiltered accumulation with it.

How to decide when in doubt

Some data will not clearly fit into any bucket. For those cases, a simple question helps decide: if I never see this data again after today, will I miss it to operate, to report, or to defend myself legally? If the answer is operate, it goes in the first bucket. If it is report or compare, it goes in the second. If it is defend against an authority or a guest, it goes in the third. If the answer is no in all three cases, you probably do not need to keep it at all.

What to do this week

1. List the types of data that exist in your current system: menu, clients, sales history, tax receipts, room charges.
2. Sort each type into one of the three buckets using the operate, report, or legally defend question.
3. Confirm with your accountant the exact tax retention period that applies in your country before archiving anything.
4. Export the second bucket’s history in a standard format and save it somewhere accessible to the controller.
5. Clean up the menu and the first bucket’s data before migrating it, not after.
6. Do not deactivate access to the previous system until all three exports are confirmed complete.

Inn Restaurant supports migration with a clear criterion for what to activate, what to archive, and what to retain for legal obligations, so switching systems does not mean losing history. If you are about to migrate your hotel restaurant, book a 15-minute demo at (contact).