Skip to main content

Resources

Guide

Moving off spreadsheets without losing history

7 minute read

The spreadsheet is not the enemy. It got your park this far, and it holds something no new system has on day one: your history. Occupancy last July. What the busy weekends really did. Which monthly guests always pay late. If you move to management software and lose that history, you spend a year flying blind while the new system relearns what you already knew. Here is how to move without losing it.

Step 1: export everything before you change anything

Before touching a new system, get every booking you have into plain files. From a reservation system, use its export function. From a spreadsheet, save a copy as CSV. You want, at minimum: guest name, site, arrival date, departure date, and the amount. Payment records from your card processor are a separate export. Do this first, while everything still works and nothing is mid-migration.

Step 2: clean the data in three passes

Do not try to fix everything at once. Make three passes, one problem each. Pass one is dates: every stay needs a real arrival and departure, in one format. Pass two is sites: one name per site, spelled one way. If the spreadsheet says A1, A-1, and Site A1 in different rows, pick one. Pass three is money: one column, numbers only, and decide once whether it is the stay total or the nightly rate.

Expect 5% to 15% of old rows to be broken in some way. That is normal. Fix what you can in an hour, flag the rest, and move on. A row with a guess in it should say so in a note rather than pretending.

Step 3: freeze the spreadsheet, do not delete it

When the history is imported, make the spreadsheet read-only and put the date in the filename. It is now an archive, not a working document. You will reach for it maybe three times in the next year, and each time you will be glad it is exactly as it was.

Step 4: run both for two weeks

For the first two weeks, keep taking bookings the old way while the new system reads along. Then compare: does the new system show the same arrivals tomorrow that the book shows? The same money this week? Two clean weeks means the history and the habits both survived the move. Only then stop updating the old way.

What a good import should give you back

  • Last year and this year, comparable on one screen
  • Every imported booking traceable back to its source row
  • A count of rows that could not be imported, with reasons, not a silent success
  • Your averages (rate, occupancy, length of stay) computed from day one

Be suspicious of any import that reports no problems. Real park data always has a few. A system that admits them is one you can trust with the rest.

Where we fit in

BrimScout starts from exactly this kind of file: you upload a reservation export (CSV) and the system reads it without writing anything back. Your free trial begins when that data has arrived and looks usable, and the import tells you honestly which rows it could not use. See the result on the live demo.

See how BrimScout would run your park.

Book a short demo and we will walk through a normal day at your park together, or start a free trial with your own booking history.

14 days. No credit card required. Your trial begins when your park data is ready.