Guide
Switching PMS: the migration, step by step
The right fear is not «it will take time»: it is «we lose data and find out in March». You handle it by deciding in advance what comes along, what gets archived and what is left — instead of discovering it along the way.
First: is it actually worth it?
Switching PMS is a six-to-eight-week project that lands on the front desk. It makes sense for three reasons, and no others:
- the system leaves you repetitive work that can now be automated (messages, housekeeping plan, compliance);
- the data lives in separate places and you are the one holding it together, so every figure has to be double-checked before you trust it;
- the vendor is not there when you need them, or has stopped developing — which is the most concrete reason of all.
«The interface looks old» is not a reason: it is an annoyance, and living with it costs less than a migration. If you are not sure which of the three cases you are in, the check-up measures it in ten questions; if you have already decided and now have to pick the new one, the method is in how to choose a PMS.
The data
What comes along, and what does not
Not everything should be migrated, and that decision is what takes two weeks off the project. The rule: migrate what you need to operate, archive what you need to read back.
| Data | Migrate it | Why |
|---|---|---|
| Future bookings | yes | The one thing you cannot afford to lose: somebody is going to sleep in them |
| Guest records | yes | Needed for recognition and for compliance; without them every regular comes back a stranger |
| Rates and restrictions | yes | Rebuilt by hand once, and it is the chance to clear out the ones nobody uses |
| Stay history (2-3 years) | Only if you need the comparison | If you price on booking pace, without history your first year is blind |
| Issued tax documents | no | Retained as the law requires, not re-entered: an archived export is enough |
| Notes and logs on old bookings | no | They cost more than they are worth. Export to a file and keep it aside |
⚠️ Anything not migrated must be EXPORTED AND ARCHIVED before the old system goes dark. Access to the PMS you are leaving ends, and with it the data you assumed you could fetch «when needed».
The calendar that works
-
Weeks 1-2 — prepare, touching nothing
Full exports from the old system, a list of the live integrations (channel manager, booking engine, payments, statutory submissions) and for each one who reconnects it. The old PMS keeps working.
-
Week 3 — load and reconcile
The data goes into the new system and is checked against three numbers that must match: rooms occupied tomorrow, arrivals this week, total deposits taken. If those match, the rest matches.
-
Week 4 — run both in parallel
A few days with both systems open, entering new bookings into each. It is tedious and it is necessary: it is the only way to notice what is missing before the new system is the only copy.
-
Switch day — never with a full house
Pick a Tuesday in low season, not the Friday of a long weekend. Channel connections move that day, one at a time, and you check that the availability showing on the channels is the real one.
-
The two weeks after — keep the old one reachable
Read-only, if the contract allows it. It is the cheapest insurance there is: two weeks of access are worth more than any promise.
Before you start, measure
The check-up tells you how much work your current system leaves on your desk, area by area. It serves two purposes: working out whether the switch makes sense, and having a starting number to compare against in six months — which is the only way to know whether the migration paid off.
Free tool
PMS check-up
Ten questions, three minutes. A score out of 100, the detail by area and the two things worth acting on — sometimes it is not the PMS.
Questions people actually ask us
How long does it really take?
Six to eight weeks for a single property, only one of them intense. Anyone telling you «you will be live in three days» is counting the data load alone and dropping the parallel week, which is the one that protects you.
Do future bookings get lost?
They must not, and they are the first thing to verify: count them before and after, and the two numbers have to be identical. If the new vendor cannot import them automatically, re-enter them by hand — there are only a few dozen and it is worth it — but do the count either way.
What about the Booking and Expedia connections?
They move on switch day, and for a few hours the inventory needs watching by hand. The real risk is an overbooking in that window: you reduce it by closing a couple of rooms temporarily, which costs one night and saves ten.
How does the staff take it?
Badly, if they find out once it is done. Well, if someone from the front desk is in the project from week 1 and decides with you what to migrate. It is the variable that moves the most time, and it is not a technical one.
Can I change one piece instead of everything?
Often yes, and it is the better choice when the problem is contained: pricing and cost control are separate tools and connect to the PMS you already have. Replacing the PMS to fix a pricing problem is how you take all of the risk for half of the benefit.