Hotel PMS Development Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the pilot expand to the whole portfolio before it has proven anything?

The release that works is one property and one narrow scope. A reservation core with a housekeeping mobile application and a direct booking engine, running at a pilot hotel, in 12 to 16 weeks for $60,000 to $130,000 in our delivery experience.

Two forces push against that. The first is licence renewal timing. If the group's current contract renews in March, somebody sensibly points out that every property still on the old system in April costs money, and the pilot quietly becomes a portfolio deadline. The second is that other general managers do not want to be second, because being second means running the old process while a colleague gets the new one.

The result is a schedule where cutover dates were set by a contract rather than by evidence, and where the pilot cannot slip even if it finds something serious. That is precisely backwards. The pilot exists to find serious things.

The discipline that holds is to separate the two decisions explicitly. The pilot has an exit criterion, not a date: a defined number of consecutive clean night audits, a month end close that reconciles, and a group departure billed correctly. The rollout has dates, and they start after the criterion is met. If the licence renewal creates pressure, negotiate a short extension on the old contract rather than compressing the only phase that de risks everything else. An extension is a known cost. A bad cutover at four properties is not.

What goes wrong when you migrate reservations, folios and guest profiles?

Hotel migration has an unusual property: you are not only moving history, you are moving a live forward book that guests are still adding to.

Future reservations are the hard part. Bookings for six months ahead exist in the old system, in the channel manager and at the online travel agencies, and they keep arriving during the migration window. Move them too early and new bookings land in the old system. Move them too late and you have a manual reconciliation on cutover night. Rate plan mapping makes it worse, since a rate code in the old system carries conditions, inclusions and cancellation terms that may be documented only in a rate manual.

Group blocks are the second risk. A block with a rooming list, a cutoff date and a contracted rate is a set of rules, not a set of reservations, and migrating the resulting rooms without the rules means unsold inventory never releases correctly.

Folio history is the third, and it is where teams over invest. You rarely need historic folios live in the new system. You need them producible on request for guest queries, tax audits and chargebacks.

The approach that works is to migrate the forward book and current in house guests properly, with rate plans re expressed rather than copied, and to keep folio history in a read only archive that front office can search. Freeze structural changes such as new rate plans and new group blocks for a defined window before cutover, and reconcile the arrivals list for the next fourteen days manually on cutover night. That manual check is an hour and it prevents the failure everyone remembers.

Why do channel, lock and point of sale (POS) integrations break after go live?

Each of these breaks differently and each needs its own answer.

Distribution breaks around inventory truth. The whole point of building is that the property management system owns one inventory ledger including blocks and allotments, but during transition you may briefly have two systems that both believe they lead. That is when an overbooking happens, and the cost of walking a guest is not just the comped room at the competitor and the ride over, it is the review. Sequence this so that inventory authority moves once, at a defined moment, rather than gradually.

Door locks break around encoding rather than data. Systems from ASSA ABLOY, Salto and dormakaba each have their own encoding workflow, and a key that encodes correctly at the front desk but fails at a specific door is usually a configuration difference at that door rather than a software bug. Test on real doors across every floor and every room type, including connecting rooms and back of house, before go live.

Point of sale breaks around posting. A charge posted to a room that has since checked out, or to a folio that has been split, needs a defined behaviour, and outlets keep trading during your cutover.

The common fixes are monitoring that alerts on absence rather than only on errors, since a feed that stops sending produces no error, and a daily reconciliation between what each interface delivered and what the property management system recorded. Give the night auditor a single interface health view, because they are the person awake when things stop.

What happens when payments and card scope are not designed in from the start?

This is the failure that is cheapest to avoid and most expensive to correct, because it is architectural.

The correct position is that a card number never touches your servers. Payments are tokenised by your processor, whether that is Shift4, Adyen or Stripe, and the system stores only tokens against the folio. That keeps your obligation under the Payment Card Industry Data Security Standard at the self assessment level rather than dragging your whole estate into scope. Build it the other way, even temporarily, even in a test environment loaded with real data, and you have changed your compliance position.

The places it goes wrong are specific and mundane. Group and travel agency billing where somebody wants to store a card for a virtual account. A no show charge policy that needs a card weeks after arrival. Guest requests taken by phone where an agent types a number into a notes field, which happens in every hotel and which the system should make impossible rather than discourage.

Settlement reconciliation is the second half. Every settlement line from the processor should match back to a folio payment automatically, with differences surfaced daily. Most month end archaeology in hotels is exactly this mismatch, and it is entirely preventable.

Ask your processor early what tokenisation and reconciliation interfaces they support, and confirm your own obligations with a qualified assessor rather than with a developer. The architecture decision should be made in week one and never revisited under schedule pressure.

Should you build custom or configure what you already own?

Configure if you are under roughly five properties with standard operations. Mews or Cloudbeds at that scale costs less per year than one developer, the marketplace covers most needs, and your problems are configuration problems rather than product problems. Building there is vanity and we will say so.

Before deciding, do two things. Ask your current vendor for a written list of what your licence already includes that you are not using, because groups routinely pay for a mobile housekeeping module or a central profile capability nobody switched on. And price the alternative honestly: a modern cloud product plus one integration project is often cheaper than a build, and if your real complaint is interface fees on a legacy platform, moving to a better citizen may solve it.

Build when the signals stack. You are spending six figures annually across the portfolio on licences, interface fees and channel manager subscriptions. You have operational differentiators that packaged products flatly cannot model, such as extended stay logic, owner revenue splits on condominium units or a loyalty mechanic, so you run them in spreadsheets alongside the system. Every acquisition means another painful migration onto a rented platform. Our position is that an independent group at eight or more properties with growth plans is usually better served owning its core system, because build economics improve with each property added while subscription economics get worse.

How do hidden costs get into the quote?

• Channel connectivity. Direct connections to major online travel agencies carry their own certification processes on their timelines, which is a schedule risk as much as a cost.
• Hardware interfaces. Door locks, point of sale, telephony, key encoders and payment terminals each add development weeks, and each needs testing on real hardware across every room type.
• Migration. A project inside the project. It deserves its own budget line, its own owner and its own rehearsal, and it is the item most often folded into a single word in a proposal.
• Parallel running. Property staff working two systems during the pilot is real payroll, usually overtime, and nobody budgets it.
• Training across shifts. Front office, housekeeping, night audit and food and beverage all need training, and night audit needs it at night. Ask who is paying for that.
• Running cost. Roughly 15 to 20 percent of build cost per year, weighted toward distribution and payment interface maintenance, both of which change on other people's schedules.

What separates a build that works from one that fails here?

Whether the people who build it have stood at a front desk. Ask a prospective developer what happens to room status when a guest checks out, what out of order means versus out of service, and what the night audit actually does. Teams who have watched a 7am departure rush design very different software from teams who have only read interface documentation, and the difference shows in the number of clicks between a walk in and a key in hand.

The second marker is that the pilot runs through a genuinely busy period before rollout. A quiet Tuesday proves nothing. You want a full house, a group departure, a walk in at 11pm and a night audit with an outlet that posted late.

The third is a written rollback plan that the general manager has read. What happens if the business date will not roll, who is called, what the front desk does at 7am, and how the property returns to the previous system if needed. Nobody wants to write it and everybody sleeps better once it exists.

The fourth is that housekeeping is treated as a first class part of the release rather than an accessory. Room status is the operational heartbeat of a hotel, and the paper board survives systems that make an attendant with a cart do anything more than two taps.

The fifth is ownership. The contract assigns intellectual property to you as work for hire, and you have repository access from the first week rather than a handover at the end. If a developer proposes licensing their platform to you instead, you are buying another form of lock in rather than a custom build.