Switching PMS or event system: what nobody tells you in the demo

Switching PMS or event system: what nobody tells you in the demo

Most demos show you the product. Almost none show you the transition to get there. That's unfortunate, because that's where most system switches actually go wrong — not because the new system is bad, but because someone underestimated how much work it takes to get from the old one to the new one without operations noticing.

We've written before about which questions to ask before choosing a vendor, and about why a proper API is the precondition for everything good you're being promised. This post is about what happens after you've signed — the phase no salesperson talks about as much, because it doesn't sell anything.

Migration isn't one task. It's three.

It's easy to think of a system switch as one big transition: one day you run the old system, the next day you run the new one. In practice there are three separate things that need solving, and they require different kinds of competence.

Data has to move — reservations, guest profiles, rates, room codes, history. Processes have to be redrawn — how an offer actually moves from inquiry to signed contract in the new system, not just in the old one. And people have to be trained — not just on what the buttons do, but on how the new routines fit together with everything else they do during a shift.

Most vendors are good at the first one. Fewer are good at the second. The third is often left up to you, because no vendor can know exactly how your reception actually works on an ordinary Tuesday.

The trap: you migrate everything, because it's there

It's tempting to think more history is better — bring everything over from the old system, so you lose nothing. In practice, this is one of the most common reasons migrations drag out and end up costing more than planned.

Ask instead: what do we actually need available in the new system from day one, and what's fine to archive somewhere we can look up if needed? Five years of guest history with comment fields full of notes from three different receptionists, written in three different formats across three different systems, is rarely worth migrating line by line. It's worth cleaning up, or simply leaving in an archive, while you start the new system with clean, correct data you can actually trust.

This is also a good moment for something most people put off until it's too late: cleaning up data that was already wrong in the old system. Duplicate guest profiles, room codes that no longer match the physical building after a renovation, price categories nobody remembers the reason for. It's tedious work. It's also considerably cheaper to do before the migration than after.

The trap: you underestimate training time, because the system is "intuitive"

We've heard this in nearly every sales pitch: "the system is so intuitive that training takes an hour." That might be true for the basic functions. It's rarely true for what actually happens in a busy reception — a cancellation in the middle of a group check-in, a rate discrepancy that needs manual correction, a guest calling about an invoice from last year.

A realistic plan includes time for staff to use the system on real tasks, with an experienced colleague or super-user available, before it goes live for real. This matters especially if your staff includes a lot of temporary and seasonal workers, who don't get the same months of built-up experience through use that a permanent employee would.

One concrete piece of advice: identify 2-3 internal "super-users" before the migration, give them extra training time, and let them be the first point of contact for other staff in the early weeks. This takes pressure off both the vendor's support line and your own management, and builds internal knowledge you keep long after the implementation project ends.

The trap: you switch mid-season because the contract says so

This sounds obvious written down, yet it still happens constantly: a contract gets signed, a go-live date gets agreed based on when the vendor has capacity available, and nobody stops to ask whether that specific date actually fits the hotel's own operation.

A conference hotel with a heavy summer season shouldn't go live with a new PMS in June. A venue with a busy Christmas party season should think twice before November. This isn't only about giving staff time to learn something new — it's because any errors in the migration, like date mistakes in a room block or missing rate codes, only surface once the system is actually used under real operational pressure. It's far better to find them during a quiet period than in the middle of the busiest week of the year.

The trap: you assume running in parallel means safety

Many choose, for good reason, to run the old and new system side by side for a period. That's often wise. But running in parallel isn't automatically safe — it's only safe if you've decided in advance how you'll handle discrepancies between the two systems while you're running both.

What do you do when a booking gets registered in the new system but not the old one, and a guest calls asking about something you can't find because you looked in the wrong system? Who's responsible for updating both systems during the transition, and how long does that period actually last — is it a fixed date, or "until we feel confident," which can easily turn into a period with no real endpoint?

Set a concrete end date for parallel running before you start, not a feeling you're supposed to reach. That's the only way to avoid the transition period becoming a permanent state where you're effectively running two systems indefinitely.

The trap: you check the export from the old system too late

We've written about this before in the context of API access, but it's worth repeating specifically in a migration context: check what the old system can actually export, before you plan what's going into the new one. It's not uncommon for an old system to simply be unable to export everything you assumed it could, especially if it's an older system without a proper API. In that case, data has to be pulled out manually, or not at all — and you should know that early in the project, not two weeks before the planned go-live.

The trap: you forget everything that isn't the PMS itself

A system switch is rarely limited to the booking system. It usually also affects the key card system, the restaurant's point-of-sale system, minibar tracking, and any external channels like channel managers or payment providers. Make a list of everything that currently talks to the old system, before you sign anything new — not after. This is the most common source of unexpected delays and extra costs we've seen, because an integration nobody mentioned during procurement suddenly has to be built or bought separately.

What actually determines whether a switch goes well

If we boil it down to something concrete: a system switch that goes well usually has one thing in common. Someone internally — not just at the vendor — owns the project, knows both the old and the new system well enough to ask critical questions, and has been given real time for it alongside their regular duties. A system switch that becomes an extra task on top of an already full role rarely gets done thoroughly enough, no matter how good the intentions are.

There's also no shame in asking the vendor for a realistic plan, with margins, instead of the optimistic one that looks good in a proposal document. A vendor who's honest that migration takes longer than they'd like to admit is usually one you come out of it better with than one who promises everything's ready in three weeks.