Ask a host why they're still on a spreadsheet, or still paying for a platform they've half outgrown, and it's rarely "I like it here." It's usually something closer to: switching means starting from zero, and a few years of booking history and expense records aren't worth losing to save some admin time. That's a reasonable thing to worry about. It's also mostly avoidable, if the new tool actually lets your old records in.
What actually needs to come with you
Not everything does. Some of it isn't worth bringing, and some of it can't be, no matter which tool you move to:
- Booking history — guest names, check-in/check-out dates, which platform each one came through. Worth bringing, and usually the part people worry about losing.
- Expense records and receipts — what was spent, when, and on what. Worth bringing, especially anything from the current tax year.
- Payout history — what actually landed from Airbnb/Booking.com/Vrbo. Nice to have, but this one's recoverable later regardless, since Airbnb and Booking.com both keep their own payout history indefinitely.
- Whatever's specific to the old tool — automation rules, message templates, saved views. This genuinely doesn't transfer anywhere, ever, and isn't really "your data" so much as configuration of the old tool. Rebuilding this is real, but it's an hour of setup, not a data-loss problem.
Bringing booking history in
Most hosts' booking history exists as a spreadsheet, or an export from wherever they're switching from — and it's essentially never in a clean, single format. Different column orders, dates written as "12/10/2026" in one row and "12th Oct" in another, a stray "nights" column left over from the original layout. A tool that only accepts one specific format effectively means retyping everything by hand, which defeats the point.
Hosts Assist's booking import doesn't assume a fixed layout. Paste rows copied straight from a spreadsheet — guest name, a check-in date, a check-out date, and the platform, in whatever order your columns happen to be in — and it works out which columns are which, and reads the dates in more or less any format: 12/10/2026, 12 Oct 2026, October 12, 2026, with or without a weekday, with or without the year. Each row gets checked for overlaps against what's already there before anything actually imports, so a duplicate paste doesn't create duplicate bookings.
Bringing expense records in
Same idea for expenses: upload a CSV with a Date and Amount column (plus payee/category if you have them), and the dates get read the same flexible way — whatever format your bank or the old platform exported them in. Every row gets a before-you-commit preview, so anything that didn't parse cleanly shows up as an error to fix rather than silently importing wrong.
Don't have clean records to import at all? That's fine too — start fresh from today and let history be history. Most of the actual value is in what gets tracked going forward, not in the archive.
What if it doesn't need to be perfect
An import doesn't need to recover every field the old system had — it needs the handful of things you'd actually miss. A booking's dates and who it was for. What something cost and roughly when. Nobody re-derives a year-old occupancy rate from imported data; they look at the numbers going forward. Treat the import as "get the last year or two of history in reasonable shape," not "perfectly replicate everything," and it stops being the blocker it feels like upfront.
Getting your data back out, any time
The other half of "not losing data" is not being stuck once you're in. Every bookings and expenses table has its own CSV export. Settings has a one-click full backup — every booking, expense, and payout for a property, as a single downloadable file — for whenever you want a complete copy, not just a per-page export. Nothing about switching in requires trusting that switching back out will be possible later.
| Common blocker | What actually happens here |
|---|---|
| Old dates aren't in the "right" format | Accepted in more or less any format — numeric, written month, with or without a year |
| Spreadsheet columns aren't in the expected order | Column order isn't assumed — the import works out what's what |
| Only a partial history, or none at all | Import what you have; start the rest fresh from today |
| Worried about getting locked in again | CSV export on every table, plus a one-click full backup, any time |
The actual timeline
For most hosts this is an evening, not a project: paste in the booking history that's worth keeping, upload an expenses CSV if there is one, turn on calendar sync so new bookings start arriving automatically, and the switch is done. The old spreadsheet or platform doesn't need to be deleted or cancelled the same day, either — nothing about starting here forces an immediate cutover.