Leaving a legacy PMS: the checklist

Work through the steps in order. Each ends with something you can tick. Print it, give it to one named person, and keep it with the old system's backup. It is vendor-neutral: use it for any move, including a move away from us. It is general information, not legal advice.

Before you start

Hotel

Old system

Planned cutover date

Owner of the move

Deputy

Who decides on rollback

• One person owns the move and has a deputy. Both can give a few hours a week for a month.
• The cutover is planned for a quiet fortnight, not your busiest weeks.
• You have found your contract with the old vendor and read the notice period, export rights and fees. (Nothing here states what any vendor's contract says. Read yours.)
• You have listed everything outside the PMS that depends on it: channel manager, payment terminals, accounting export, point of sale.

Step 1. Inventory what must move

Write this down before you talk to any vendor.

• Future reservations, each with the rate it was booked at. A booked price should arrive as booked, never recalculated.
• In-house guests and what each one owes.
• Guest profiles, including repeat-guest history if you want it.
• Rooms and room types.
• Open balances: deposits held, city-ledger and agency receivables.
• History you actually want. Guest history is cheap to carry. Statistics history is worth carrying 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.
• Booking sources and payment methods you use.
• Staff users and what each may do. Accounts and passwords often do not move, so list who needs which role.
• The reports you open every week. Name the five you could not do without.
• 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. Rate plans 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.

• You know whether you can copy the data yourself or only through the vendor, and in what format.
• You know what your contract says about notice, export rights and fees.
• You can take a full copy after the night audit, while nobody is using the system. A mid-day copy will not match.
• No guest data, especially passport data, goes to a new vendor before a data processing agreement is signed, and never by chat or email attachment.

Step 3. Decide how you will know it worked

Pick checks that are numbers you can see in both systems. Agree them before the import, not after.

• In-house count and the room list match.
• Reservation counts by status (booked, in-house, checked out, cancelled, no-show) match. A status code read the wrong way is the classic failure here: real in-house guests can look cancelled.
• Future reservations by arrival week for the next 90 days match, by count and by room-nights.
• Total booked value of future reservations matches within a tolerance you can explain line by line.
• Balances match: in-house folios, deposits held, city-ledger totals.
• Your front-desk lead has read twenty sample reservations: an OTA booking, a travel agent, a direct booking, a group, a long stay, a split bill, a prepaid.
• A TM30 dry run has been done for the foreign guests in the house, with missing values listed rather than guessed.
• No duplicates from booking emails or API feeds after import, checked on day one and day two.

If you carry statistics history, also compare 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 is to mirror and compare, with the old system as master. The new system is refreshed from the old one. Staff use it to practise and look things up, not for real work, because each refresh overwrites manual edits.

• Everyone knows the new system is practice only until cutover.
• 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.
• Staff are not asked to enter everything twice. That doubles the workload and creates its own errors.
• You have run at least one practice night audit on the new system.
• The parallel run stops only after three days in a row where every line matches or is explained.

Step 5. Paperwork continuity (Thailand)

• You know who files TM30 for foreign guests and how: a hotel notifies the local immigration office within 24 hours of a foreign guest taking up residence, according to the Thai Immigration Bureau.
• The new system produced the TM30 list for a day of real check-ins and you compared it with the old system's list.
• Nationality and passport fields that are blank or inconsistent are listed and fixed by staff, not guessed by software.
• Your daily routine is written down: capture at check-in, build the list from real check-ins, check it against the in-house list, file inside the 24 hours, keep proof, name a person for every shift.

Step 6. Cutover day and the way back

• You 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 awake can watch the new system's first audit.
• The old system is backed up and left untouched: read-only, shortcut removed. Keep it for a defined period (we suggest at least 90 days and until the first month-end is closed).
• Three days of arrivals, in-house and departures are printed the day before, as a paper fallback.
• The rollback rule is written down before you start, with the name of who decides. A reasonable trigger: the in-house count or the 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.
• The rollback window is agreed in advance. A clean rollback gets much harder once a night audit has run on the new system, so we would set it at about 24 hours after the first successful night audit. After that you fix forward.
• Every shift has a named person and a deputy, and one person has nothing else to do except watch the first night audit.

Step 7. The first week and the first month

• Day one and day two: no duplicate bookings from emails or feeds.
• Charges filed under a generic "extra charge" are mapped to proper categories. Left alone, they distort revenue by category.
• The first month-end is reconciled against the old system's reports, with your accountant.
• The first OTA statements are matched to bookings by reference. Exceptions stay open as tasks; they are not hidden by an adjustment.
• The old system is retired only after the defined keep period.

Questions for any vendor, old or new

• How do my OTA bookings arrive, and who sets that up? Ask exactly how your channel manager would connect and who does that work. It is a separate job from moving the PMS.
• Can I change a rate, a staff user and a report myself, without a ticket?
• Show me the daily close and each cashier's balance by payment method.
• After the close, can anyone edit yesterday without a trace?
• What is the whole price on one page, and what is not included?
• Can I export my data in a format a person can open, at any time?
• What exactly does it do for Thai immigration reporting, and what does it leave to me?

When not to switch yet

• Your revenue depends on a two-way channel-manager connection to the old system and the new one cannot match it.
• It is your busiest weeks. Pick a quiet fortnight.
• Nobody can spend a few hours a week for a month checking numbers. Software will not do that for you.

Where Orca Systems fits, honestly

Read the article this checklist comes from, including what went wrong in our own move. Before you decide, run The Friday Test on the system you have: nine changes you should be able to make yourself.