Hotel PBX systems can move their call control to the cloud without making every guestroom phone an IP handset. They can also use modern IP phones while keeping call control on the property. That distinction matters in an upgrade: where calls are controlled, how rooms are connected, and how service survives an outage are related decisions, but they are not the same decision.
For a hotel owner comparing a hosted service with a replacement on-premises PBX, the useful comparison is the complete operating design. A low monthly price does not describe the room-phone gateways, property-management integration, carrier service or backup power. Equally, a new local server does not automatically preserve every feature the old system provided.
Cloud versus on-premises describes call control
A hosted PBX runs its central call-control software outside the hotel. An on-premises PBX runs that software on local equipment or a local virtual server. Both approaches may offer transfers, ring groups, voicemail and remote administration. Neither label, by itself, describes the guestroom cabling.
Mitel’s hospitality communications overview describes on-premises, public-cloud, private-cloud and hybrid deployment models. These are architecture options, not a universal ranking from old to new. A property with usable room wiring and a recently renovated front desk may make a different transition from a new-build hotel installing its infrastructure for the first time.
JET approaches hotel PBX and phone solutions as part of the property’s wider technology environment. A useful upgrade design separates the room-phone layer, call-control layer, outside calling service and hotel applications. This keeps a decision about server location from quietly becoming an unnecessary whole-building replacement.
The same room phone can sit behind different architectures
Many guestroom telephones use analog connections. With an appropriate, supported gateway, analog extensions can connect to an IP-based PBX. That may allow suitable existing phones and copper pairs to remain while the system behind them changes. It is a compatibility option, not a promise that every old handset can be retained.
Yeastar’s hotel-phone overview describes mixed analog and IP hotel infrastructure and gateway connections. The practical implications include handset compatibility, ringing, message-waiting behavior, extension mapping and the condition of the installed wiring. A connector that physically fits does not prove that every guest-facing function behaves correctly.
Conversely, IP room phones introduce their own network and power requirements. Their choice should follow the desired guest experience and infrastructure design, not the assumption that a hosted service always requires replacing every room phone. In a renovation, keeping suitable room equipment can reduce disruption; a new-build design may reasonably favor a different approach.
Outage behavior is a separate design choice
Hosted calling normally needs a working path to its provider. A local PBX can maintain some internal calling without that internet path, but external calls may still depend on a carrier circuit, SIP trunk or other connection. Both designs need power for their relevant equipment. “Cloud stops working” and “local always works” are both incomplete descriptions.
Cisco’s Webex Calling site-survivability documentation provides a concrete example: compatible endpoints can use a configured local survivability gateway for backup call control when the cloud connection fails. This requires supported equipment and configuration, and the available fallback features differ from normal cloud operation. It is not a default property of every hosted PBX.
For a hotel comparison, separate three outcomes: room-to-front-desk calling, calls to outside numbers, and hotel application functions. They may not fail or recover together. A second internet connection, local survivability equipment and backup power solve different parts of that problem. The relevant question is which service remains available under each specific failure, not which architecture has the most reassuring label.
Ask each bidder for the same outage acceptance evidence
Turn the resilience proposal into four documented scenarios before choosing an architecture. Have the qualified telephony team define safe test conditions, a maintenance window and a rollback plan; do not disconnect live hotel services simply to see what happens.
- The primary internet path fails. Identify which room and staff endpoints retain call control, whether active calls survive, and where new calls route. Record time to usable service and test room-to-front-desk calling separately from an incoming outside call and an outgoing non-emergency call.
- The external carrier path is unavailable. Show which alternative circuit or trunk carries outside calls, who provides it and which equipment and connectivity it still depends on. A local dial tone or successful room-to-room call does not establish that the hotel can receive or place outside calls.
- Local equipment loses normal power. List the power dependencies for room-phone gateways, network switches, routers, call-control equipment and carrier equipment. Ask for the designed backup duration and the evidence supporting it at the proposed load. Identify any equipment left outside the backup-power scope.
- Normal service returns. Verify that endpoints return to the intended call-control system and that front-desk transfers, queues and hotel application workflows recover. Record who checks recovery and who closes the incident; an internet link returning is not the same as every hotel phone function returning.
Keep one acceptance row per scenario with the affected equipment, expected calling functions, unavailable features, observed interruption, responsible provider and pass/fail result. Compare bidders on the same rows rather than accepting a general “failover included” statement.
The details are product-specific. Cisco’s Webex Calling survivability guidance requires supported endpoints and a configured local gateway; external calling depends on available PSTN circuits or SIP trunks, and some features differ in survivability mode. Do not apply that example to another platform or assume retained third-party room phones are covered. Require the proposed vendor to document support for the hotel’s exact endpoint and gateway models.
Emergency calling, elevator phones, fire-alarm communications and other special-purpose services need a separate qualified review and coordinated validation. These ordinary-call scenarios do not demonstrate regulatory compliance, and emergency test calls should never be made without the appropriate prior coordination.
PMS integration is not implied by a dial tone
For a specific analog-retention example, our Mitel MiVoice Business gateway comparison separates AG4124/AG4172 connections from the hotel’s PMS integration.
A working telephone can place a call without knowing whether a room is checked in, checked out or moved to another guest. Those states belong to hotel applications and their integrations. Wake-up services, guest-name display, voicemail clearing and room-status updates can depend on the PBX edition, middleware, PMS interface and licensed features.
DuVoice’s hotel PBX explanation separates basic calling from PMS-connected guest services. That is an important distinction when comparing proposals: a business calling platform with mobile apps is not automatically a complete replacement for a hotel’s existing telephony workflow.
The comparison should describe one actual guest stay: check-in, a room move, a wake-up request and check-out. This exposes integration differences more clearly than a list of general communications features. It also avoids treating every hotel as though it uses identical PMS software or identical front-desk procedures.
Test the guest-stay workflow before accepting the PMS interface
Ask the PMS, middleware and PBX providers to demonstrate the proposed configuration together, using test reservations and rooms held out of service. Record the software versions, licensed functions and responsible support team. Mark unsupported functions explicitly rather than treating “PMS integration included” as a complete scope.
Oracle’s OPERA Cloud property-interface guidance illustrates why configuration matters: arrival, room-move and departure events send room and reservation details to interfaces. Its PBX options also distinguish guest-name display and whether OPERA or the phone-system vendor handles wake-up calls. Other PMS products and interface versions need their own supported workflow.
- Check-in and room identification. Call the front desk from the test room. Confirm the correct room and, where enabled, the intended guest display name. Include a shared-room reservation if the hotel uses one; agree which name should appear rather than assuming every occupant is displayed.
- Room move. Move the test reservation in the PMS, then call from both rooms. Check the new room’s identity and verify that the old room no longer presents the previous guest’s information. Agree what should happen to pending wake-up requests and voicemail instead of assuming they transfer.
- Wake-up outcome. Test a completed call and an unanswered call. Document which system schedules the call, the retry behavior and where staff see a failed result. Agree the front-desk follow-up procedure before handover.
- Checkout and the next arrival. Confirm the agreed reset of guest-name display, calling permissions, voicemail access and outstanding wake-up requests where supported. Check in a second test guest to verify that the prior stay’s information and requests do not carry over.
For each step, retain the expected result, observed result and named owner of any correction. Separately ask the vendors to demonstrate their supported reconciliation process after an interface interruption in a controlled test. A restored connection alone does not prove that room assignments and guest-service states match across systems.
Can the existing hotel PBX stay when AI answers calls?
Possibly—but scope the connection before approving an AI subscription. Retaining room phones is different from retaining call control, and neither proves that an AI service can return a caller to the right hotel team. Ask for five pieces of acceptance evidence:
- A supported connection map. Record the PBX model, software release, required licenses and the maintainer’s confirmed support horizon. Show where AI enters the call path and identify any gateway, session border controller or middleware. Name who configures and supports each connection.
- A demonstrated return to staff. Test the actual department extensions and queues, including busy, unanswered and failed transfers. “SIP compatible” is not enough: Retell’s telephony documentation, for example, distinguishes SIP trunking from dial-to-SIP-URI integration; the latter requires custom transfer logic rather than its built-in transfer feature. Verify the method proposed for this hotel.
- An explicit guest-data boundary. If AI needs guest names or room context, identify the authorized source, required fields, middleware and update events. Oracle’s property-interface documentation describes arrival, room-move and departure events sending room and reservation details. A working voice connection alone is not evidence that an AI service receives that information. Agree access, retention and the response when data is missing or stale.
- A busy-period test. Use measured call arrivals, durations and simultaneous calls—not room count alone—to agree capacity. Exercise the complete hotel-to-AI-to-staff path, including overflow and service failure. Record the fallback destination, restoration procedure and party authorized to disable AI routing.
- A separate integration budget. Itemize interface licensing, gateway or middleware work, configuration, testing and training separately from subscription or seat charges. Then identify AI usage, carrier and transfer charges, ongoing integration support, and maintenance of the retained PBX. Compare these on the same hotel technology total-cost basis.
Use one acceptance row per call scenario: origin, AI entry point, staff destination, failure route, responsible provider and observed result. Keep emergency and special-purpose calling outside an ordinary AI-answering pilot unless separately reviewed and validated by the qualified telephony team.
Compare the operating model, then plan the transition
Hosted services typically move more platform operation into an ongoing service arrangement. On-premises systems retain more local infrastructure responsibility. Neither is automatically the lower-cost option. Compare the same period and scope: subscriptions, room and staff extensions, gateways, carrier service, implementation, support, updates, spare equipment and resilience.
A multi-property group may value centralized administration. A property with strong local support and specialized integrations may value direct control. An existing analog room-phone estate may make a hybrid transition attractive. These are best-fit situations, not vendor endorsements or guaranteed savings.
Once the architecture is chosen, the hotel PBX cutover planning guide addresses the separate migration task. Retain an extension map, validate room functions and document the rollback boundary. Emergency and special-purpose lines require qualified review under applicable requirements; ordinary guestroom compatibility is not evidence that those services can be moved unchanged.
The upgrade outcome should be a clear description of what stays, what moves and how calling behaves in normal and degraded conditions. If your property is comparing hosted and on-premises options, request a hotel phone-system architecture review with JET.