Switching from another PMS: what moves over

This content is not available in your language yet.


Why	Know in advance what will be in the system after the switch — and what you will have to restore by hand — before your guests notice.
Who	Hotels moving over from another property management system (PMS), or still considering the move.
What you’ll get	You know which data arrives on its own, which needs verifying on day one, and which is set up from scratch.
Limitations	The migration is done by the HotelsCalendar support team: there is no file-import button in the interface, and what can be migrated depends on your old system.

The move is a joint effort: your data is migrated from the old system by the HotelsCalendar support team, together with you. There is no import-from-file button in the interface, so the first step is a single one — write to us and we will agree on the scope of the migration and the date.

And here is the main thing to know in advance: every migrated rate plan arrives with RO as its meal type (room only — accommodation only, no meals). If breakfast was included in the price in your old system, you set the meal type back in the rate plans by hand after the switch. A missed correction is the most common source of guest complaints after a migration: a rate that used to include breakfast keeps selling without it. Below is the full list of what gets migrated, what needs verifying, and what is set up anew.

Who does the migration, and when

The migration is performed by the HotelsCalendar support team, together with you. There is no spreadsheet template to fill in on your own either: every system structures its data differently, so the scope is always agreed individually.

Write to us: which system you are moving from and when you plan to switch. If you are still evaluating the system, ask in advance — for your particular case we will tell you what can be migrated and what you will need to set up by hand.
Agree on the scope: the room inventory, rate plans and prices, bookings for a period — and the date of the switch.
By the agreed date the data is already in the system — what remains is verification and manual restoration of what is not migrated (more on that below).

Result: the scope and the date are agreed, the migration is on support — verification is on you.

What gets migrated

Room types arrive automatically, together with the rooms themselves, as do rate plans and prices for the next 120 days. Each item has a nuance, so a short verification follows the migration.

The room inventory. Rooms are created by count, not by name: the names are generated by the system. After the switch they are renamed to the real ones:

Open “Rooms” and check the number of rooms in each room type against your actual inventory.
Rename the generated rooms to match how the rooms are actually called in your hotel — this is the name that will be picked at check-in.
Make sure every room stayed within its room type.

Result: the Planner shows the hotel’s real rooms, not technical placeholders.

Rate plans and prices. Rate plans are migrated together with their prices — but with two corrections to make right away: the meal type (arrives as RO — see above) and the cancellation policy (the next section). Prices beyond the 120-day mark are covered in their own section below.

Guests. The guest database starts from zero: guest profiles and stay history are not migrated from the old system. Profiles will build up as you work — from manual bookings, website bookings, and channel bookings.

Cancellation policies: verify before turning channels on

In migrated rate plans the cancellation policy is replaced with a default value — the terms you had in the old system are not carried over. The correction is urgent because channels sell rate plans together with their cancellation terms: until the terms are verified, channels stay off.

Open “Rates” and go through the migrated rate plans.
Compare the cancellation terms with what you are selling right now — in your channel listings and on your own website.
Restore the right terms in every rate plan.

Result: the cancellation terms in your rate plans match what you sell — the channels can go on.

Shortfalls and debts on old bookings

Balances of old bookings are not restored by the migration: if a guest still owes money for a past stay, the debt will not appear in the new system on its own. Record it by hand:

Open the booking card, the “Payments” tab.
Click “Add payment” and record the shortfall in the “New payment” form: the amount, the date, the “Pending” status.

Result: the debts are visible in the system and are settled the usual way.

Services: set them up anew

Your old system’s service catalog is not migrated: transfers, parking, late check-out and the rest are created anew in the “Service catalog” section. From there, services are added to bookings as usual — on the “Extras” tab of the booking card. Set the catalog up right after the switch: without it, services can neither be added to a booking nor sold at the desk.

Prices beyond the 120-day mark

Prices arrive for the next 120 days — beyond that horizon there are none. Dates without a price do not sell: not through the booking module on your website, and not through the channels. The failure is deferred and silent — the system will not remind you, and you will notice it when the season is right at the door. So fill the prices in right after the switch:

Open the “Price Manager” and use a bulk update to cover the period beyond the migration horizon.
Then fine-tune the high seasons, holidays, and local events date by date.

Result: prices exist for your whole selling horizon — the season will not start on empty dates.

Old bookings: direct ones by hand, channel ones with support

Right after the switch the Planner will not hold all of your bookings at once — that is expected, not data loss. Future arrivals return to the system by two routes.

Direct bookings — ones taken by phone or email — do not end up in the new system; re-create them by hand:

Collect the future direct bookings from the old system or from your records.
Re-create each one on the Planner — by clicking a cell on the arrival date — or through the new-booking wizard.

Result: every future date with a direct guest has a booking and an assigned room.

Channel bookings from the past period are migrated by the support team as well — agree on the period in advance, when the scope is being settled. Fresh bookings will start arriving in the Planner on their own as soon as a channel is switched on: the mechanics are described in the Channel Manager section.

Verification after the switch

The check takes half an hour to an hour and happens before the channels go on:

Meals: in rate plans where guests expect breakfast, the meal type is no longer RO, and meal prices are set in the “Price Manager” (the ”+ Meals” mode).
Rooms: names and counts match the real inventory.
Cancellation policies: every rate plan carries the terms you actually sell.
Taxes: the VAT rates for accommodation and meals and the city tax rules are set up — under “Settings”, in the taxes section.
Services: the catalog has been created anew (the section above).
Address and coordinates: open the property profile under “Settings” and check that the address is found on the map and the coordinates are in place.

If something does not add up, write to support: the migration is managed by the same team, and a follow-up migration is agreed just like the first one.

And one important distinction: a migration is a one-off operation, not a synchronization. There is no automatic link with the old system after the switch: changes made there after the migration date never reach HotelsCalendar. So do not put off the verification — and run your day on one system.

Once the check is done, turn the channels on and put the widget on your website: the channel goes on when you are ready.