Leaving Hotsoft or any legacy PMS: what to check before you switch

Many owners who want to leave an old property management system (PMS) stay another year. The reason is rarely the software. It is the fear: losing the history, breaking the night audit, missing a TM30 filing, being unable to bill anyone on the day it goes wrong.

We replaced Hotsoft with our own system at Royal Ivory Nana Hotel, a 91-room hotel in Bangkok, in 2026. This is the list of what we would check again, in the order the work happens. It is vendor-neutral on purpose: use it on any move, including a move away from us.

First, an honest limit

We have done one migration: our own, from Hotsoft, with direct access to our own data, ending in a cutover on 23 July 2026. Treat our experience as one data point, not a track record. If someone tells you any system can be moved in a day, ask them how many they have moved.

What went wrong along the way is the most useful part of this article, so here it is:

• A status code was read the wrong way. Real in-house guests looked cancelled, so the new system's in-house count was far below the old one's. It was fixed by establishing what the code meant from the data.
• A field's label did not match its contents. Labels are not evidence; the data is.
• Booking emails arriving during the parallel run created duplicates of bookings already imported, until the matching was fixed.
• Some charges were filed under a generic "extra charge" (minibar was one), which distorts revenue by category until you map them.
• Passport data was inconsistent. Nationalities were stored as a mix of three-letter codes and full country names, and gender was blank for some guests.

Every item on the lists below exists because of something like that.

Step 1: Inventory what must move

Write down, before you talk to any vendor:

• Future reservations, with the rate each was booked at (a booked price should arrive as booked, never recalculated).
• In-house guests and what they owe.
• Guest profiles, including repeat-guest history if you want it.
• Rooms and room types.
• Open balances: deposits held, city-ledger and agency receivables.
• History, if you want it. Guest history is cheap to carry. Statistics history is worth it only if it can be reconciled against the old system's own reports. Line-by-line financial history is rarely worth moving; keep the old system or its exports as the archive.
• What may not move. Ask about each of these: rate plans and seasons, user accounts and passwords, card numbers, the old audit log, report layouts, and anything tied to other systems such as a POS or accounting export. Rate plans in particular are often computed by the old system's own logic, so an automatic translation can silently produce a wrong price. Plan to re-create them by hand from your printed rate card, and check that existing bookings keep the rate they were booked at.

Step 2: Find out whether you can get your data out

Do this before you commit to anything else.

• Can you copy the data yourself, or only through the vendor, and in what format?
• What does your own contract say about notice, export rights and fees? We do not state what any vendor's contract says; read yours.
• Can you take a full copy after the night audit, while nobody is using the system? A mid-day copy will not match.

Then a legal point. Thailand's Personal Data Protection Act came fully into force on 1 June 2022. When a data controller (here, the hotel) engages a processor, a data processing agreement must be in place, and transfers abroad need adequate protection (Tilleke & Gibbins, 1 November 2022). In practice: do not send guest data, especially passport data, to a new vendor before that agreement is signed, and never by chat or email attachment. General information, not legal advice; ask your own counsel.

Step 3: Decide how you will know it worked

Pick checks that are numbers you can see in both systems. The ones we use:

1. In-house count and the room list match.
2. Reservation counts by status (booked, in-house, checked out, cancelled, no-show) match. This is the check our status-code error would have failed.
3. Future reservations by arrival week for the next 90 days match, by count and by room-nights.
4. Total booked value of future reservations matches within a tolerance you can explain line by line.
5. Balances: in-house folios, deposits held, city-ledger totals.
6. Twenty sample reservations read by your front-desk lead: an OTA booking, a travel agent, a direct booking, a group, a long stay, a split bill, a prepaid.
7. A TM30 dry run for the foreign guests in the house, with missing values listed rather than guessed.
8. No duplicates from booking emails or API feeds after import, checked on day one and day two.

If you carry statistics history, add rooms sold, occupancy, average rate and revenue for the last 30 days and the same period last year, against the old system's own report.

Step 4: Run in parallel before you cut over

The safest pattern we know is mirror and compare, with the old system as master. The new system is refreshed from the old one; staff use it for practice and for looking things up, not for real work, because each refresh overwrites. At our hotel, manual edits made in the new system were lost to the next refresh until we agreed that rule. Each day, someone compares a short list in both systems: in-house, tomorrow's arrivals and departures, last night's room revenue, payments by method, balances, occupancy and the TM30 names.

Do not make staff enter everything twice; it doubles the workload and creates errors of its own. Stop the parallel run after three days in a row where every line matches or is explained, plus at least one practice night audit on the new system.

Step 5: Plan the cutover and the way back

• Cut over at a business-date boundary, not mid-day: after the old system's audit and before the morning rush, or in the evening if someone is awake to watch the new system's first audit.
• Back up the old system and leave it untouched. Make it read-only, remove the shortcut, and keep it for a defined period (we suggest at least 90 days and until the first month-end is closed).
• Print three days of arrivals, in-house and departures the day before, as a paper fallback.
• Write down the rollback rule before you start, and who decides. A reasonable trigger: the in-house count or balance total does not match and cannot be explained within two hours, or the first night audit fails twice. The decision belongs to the hotel's owner, not the vendor.
• Decide the rollback window in advance. A clean rollback gets much harder once a night audit has run on the new system, so we would set the window at about 24 hours after the first successful night audit. After that you fix forward.

When not to switch

• When your revenue depends on a two-way channel-manager connection to the old system and the new one cannot match it. With any new system, ask exactly how your channel manager would connect and who does that work; it is a separate job from moving the PMS itself.
• In your busiest weeks. Pick a quiet fortnight.
• When nobody can spend a few hours a week for a month checking numbers. Software will not do that for you.

Back to all articles