How to switch hotel PMS without losing your data

Most hoteliers stay on a system they have outgrown because changing it looks frightening. That fear is reasonable — a botched migration can lose bookings — but it is manageable. The hotels that struggle are almost always the ones that treated the switch as a software installation rather than a small project.

Here is a sequence that works.

Before you sign anything

Get the migration scope in writing. Ask precisely what moves: future bookings, past bookings, guest records, folios, invoices, rates, room types, blocks. Most vendors move future reservations and guests. Many do not move historical financials, and you need to know that before you commit, not after.

Get your own data out first. Whatever the new vendor promises, export everything from the old system yourself, now, while you still have access and goodwill. Bookings, guests, invoices, rate plans — CSV is fine. If the old vendor charges for an export, pay it; it is cheap insurance.

Confirm how long you keep read access to the old system. A year is sensible. You will need it for a VAT query or a guest dispute long after you have stopped using it day to day.

Pick the date carefully

Go live in your quietest fortnight, never in the run-up to a busy season. Avoid month-end, because you do not want the first VAT return and the migration in the same week.

Pick a date where your strongest staff member is present for the first five days. The new system will be learned by whoever is on shift in week one, and their habits become everyone's habits.

Freeze, then move

Agree a cutover point — typically close of business on a specific day. After that point, every new booking goes into the new system only. The temptation to "run both for a while" is the single most common cause of trouble: two live calendars will disagree within days, and you will not notice until a guest arrives.

If you must overlap, make the old system read-only. Not "we'll try not to use it" — actually read-only.

Channels are the risky part

This is where switches go wrong. Your OTA listings are connected to the old system's channel manager. They have to be disconnected and reconnected to the new one, and in between there is a window where nobody is updating availability.

Plan it deliberately:

• Get room type and rate plan mappings agreed before cutover day, not on it. A mismatched mapping sells the wrong room at the wrong price.
• Close availability on the OTAs for the cutover window if it is more than an hour or two. A closed hotel for one afternoon is cheaper than an oversold one.
• After reconnecting, compare what each OTA is showing against what the PMS thinks it published — every room type, every date, for at least the next sixty days. Do not assume; check. If the two disagree by even one room, find out why before you open up.
• Watch the first few OTA bookings land and confirm each one arrives with the right room type, rate and dates.

If you are unclear how availability reaches the OTAs at all, what a channel manager actually does is worth ten minutes first.

Check these on day one

• Every future booking is present, in the right room, on the right dates, at the right rate.
• Deposits already taken are recorded against the right bookings.
• Room blocks and maintenance rooms carried across — a blocked room that arrives as sellable will be sold.
• Your website's booking engine points at the new system.
• Confirmation emails go out with the right branding and the right hotel details.
• Tax rates are correct, including any reduced-rate long-stay handling. See VAT on hotel accommodation.

Train on the awkward cases

Everyone can be shown how to take a simple booking. What causes stress in week two is the unusual work: splitting a booking across two rooms, moving a guest mid-stay, refunding a deposit, issuing a credit note, handling a group. Make the vendor walk your team through those specifically, and write down the steps for the ones you do rarely.

Allow for the dip

The first fortnight will be slower than the old system, even if the new one is better. That is unavoidable — muscle memory has to rebuild. Tell your team to expect it so nobody concludes on day three that the switch was a mistake.

Judge the decision at ninety days, not at nine.

A short pre-flight list

1. Own export of all data, taken before cutover.
2. Migration scope agreed in writing.
3. Quiet date chosen, strong staff rostered.
4. Channel mappings agreed in advance.
5. Old system read-only from cutover, readable for a year.
6. Day-one verification list printed and worked through.

Do those six and a PMS migration is an ordinary week with extra paperwork, rather than the horror story people warn you about.

InnCloud handles migration and setup as part of onboarding, with UK-based support through the first weeks. Start a free trial or talk to us about moving.