On-premises IP PBX vs Cloud telephony.
An on-premises IP PBX keeps the call platform inside the building, so internal calling, analogue endpoints and local integrations survive a circuit outage — which is why operational voice in hotels, hospitals and plants usually stays on-site.
Quick answer — when to choose On-premises IP PBX or Cloud telephony
Quick answer
An on-premises IP PBX keeps the call platform inside the building, so internal calling, analogue endpoints and local integrations survive a circuit outage — which is why operational voice in hotels, hospitals and plants usually stays on-site. Cloud telephony removes the on-site platform entirely and suits distributed, mobile users with no in-house team to own it, but it makes every call dependent on the connectivity and the local network's behaviour. Hybrid arrangements are common: cloud for general users, an on-site platform for the endpoints that must not fail.
When to use
You are deciding where the call platform should live for a site whose voice has an operational job, not just a desk-phone job.
When not to use
The real problem is call quality on an unassessed network — that is a LAN and connectivity question, and moving the platform will not fix it.
Option A
On-premises IP PBX
The call platform lives in the building, so extension-to-extension calling and local integrations keep working even when the internet does not.
Choose On-premises IP PBX when
- Internal calling must survive a circuit failure — hotels, hospitals, plants, campuses with real operational voice
- Analogue endpoints remain in service — lift phones, gate points, alarm diallers, legacy handsets
- Voice integrates locally with room status, nurse call, paging or door systems
Option B
Cloud telephony
The call platform is a subscribed service, so there is no on-site call server to own, patch or replace, and users move between sites and devices freely.
Choose Cloud telephony when
- Users are distributed or mobile and the office is not where the work happens
- There is no in-house team to own a call platform's lifecycle, patching and backups
- Sites are small and opening or closing one should not mean installing hardware
Side by side
The fields that decide it
| Dimension | On-premises IP PBX | Cloud telephony |
|---|---|---|
| Internal calling during an outage | Continues — the platform is on site | Stops unless a local survivability path exists |
| Analogue endpoints | Supported directly through gateways or cards | Needs gateways retained on site anyway |
| Local system integration | Direct to room status, nurse call, paging, door entry | Depends on what the service exposes |
| Who owns the lifecycle | Your team or your integrator — patching, backups, spares | The provider, within the terms of the service |
| Network dependency | LAN quality for internal calls; circuits for external | Every call depends on connectivity and the LAN |
| Multi-site and mobile users | Needs design across sites | Native — users move between devices and locations |
Survivability options, analogue support and integration capability vary widely between platforms and service tiers — confirm against the specific offering before committing.
Before the drawings freeze
What changes at design stage
What changes at design stage
- List the endpoints that must keep working when the internet does not — lift phones, gate points, alarm diallers, reception, clinical areas — before choosing where the platform lives.
- Assess the LAN first: quality of service, switch capability and power for handsets decide whether either option performs, so the assessment precedes the platform choice.
- Size external circuits against peak concurrent calls rather than extension count, which is the sizing error that shows up on the busiest morning.
- Decide the integration list early — room status, nurse call, paging and door entry are far easier to design in than to bolt on.
Infrastructure implications
- Handsets are powered devices on the same switching as everything else, so the power budget and switch capacity belong in the network design.
- An on-site platform needs its supply arrangement thought through — voice that fails with the mains is not operational voice.
- Analogue stragglers still need physical ports somewhere on site, whichever option is chosen; they rarely disappear as early as the plan assumes.
- Where sites are linked, the inter-site path and its behaviour under failure is part of the voice design, not just an IT concern.
Getting it built
Coordination & integration
Coordination for architects & consultants
- Agree with the operator which conversations are operational and which are ordinary; that list, not headcount, drives the architecture.
- Coordinate handset positions, reception layout and public phone points with the architect and the interior design.
- Confirm who owns numbering, porting and the provider relationship, and what happens to it if the service changes.
- Where voice interfaces with life-safety or clinical systems, agree that scope with the relevant consultant and against the approved design.
Integration considerations
- Room status, nurse call, paging and door entry integrations have to be confirmed against what the chosen platform actually exposes, not assumed.
- Emergency and alarm-dialling paths need to be identified explicitly and tested — they are the calls that matter and the ones least often exercised.
- Voice traffic needs its own treatment on the network; sharing a flat network with cameras, guests and building systems is where call quality goes.
- Directory, provisioning and user lifecycle should be planned with the IT team so leavers and joiners do not become a manual telephony task.
Typical project fit
Where each is the right answer
Decision summary
- Hotel with front desk, room status and back-of-house voice
- On-premises platform so internal calling and room integration survive a circuit failure, with analogue points retained where they exist.
- Distributed professional firm with mobile staff and small offices
- Cloud telephony — no on-site platform to own, users move freely, and opening a site does not mean installing hardware.
- Campus with operational voice in some buildings and desk users in others
- Hybrid — cloud for general users, an on-site platform for the endpoints and integrations that must not fail, with the split written down.
From the field
Common mistakes
- Migrating to IP before the network has been assessed, then blaming the platform for a quality problem the LAN was always going to cause.
- Sizing external circuits from extension count instead of peak concurrent calls.
- Assuming the analogue stragglers will be gone by cutover — lifts, gates and alarm diallers usually outlive the migration plan.
- Choosing cloud for a site whose internal calling has an operational job, without a survivability path for the endpoints that must not fail.
- Leaving the emergency and alarm-dialling paths untested until the first time somebody needs them.
TechnoGuru engineering perspective
How we specify it
We start from the endpoint list, not the platform. Any site where internal calling has an operational job — a hotel front desk, a ward, a plant, a gate — has endpoints that must keep working when the circuit does not, and that usually means a platform on site even where general users sit in the cloud. Before either option is committed, we assess the LAN, because call quality follows the network and no platform choice repairs a flat, unmanaged one. Hybrid is a legitimate answer when the split is written down rather than drifted into.
Where this connects
Services, sectors, tools & proof
Relevant services
Relevant tools & calculators
Related comparisons
Further reading
Selected proof
Owner-approved, publicly-verifiable project references. No quantities, pricing, layouts or restricted detail are shown.
Brand ecosystems that appear in this decision
TechnoGuru works with, specifies, supplies, installs or integrates these brand ecosystems depending on project fit, availability and client requirements.
· How we approach this on a live brief
On a real networking & it brief the choice between On-premises IP PBX and Cloud telephony usually turns on a few of the fields above, not every row in the table. Share the drawings, the BOQ or the constraints and a project lead will name the one we would specify for the building — with the engineering reason set out in writing.
· Frequently asked
On-premises IP PBX vs cloud telephony —
what people ask first.
Is an on-premises PBX obsolete?
No — it is situational. Where internal calling has an operational job and has to survive a circuit outage, or where analogue endpoints and local integrations remain in service, an on-site platform is still the defensible answer. Where users are distributed and there is no team to own a platform's lifecycle, cloud is the better fit. The endpoints decide, not the trend.
What happens to lift phones, gate points and alarm diallers?
They still need physical ports on site under either option, usually through gateways. They tend to outlive migration plans, so the honest approach is to list them at design stage, decide where each one terminates, and test the emergency and alarm-dialling paths at handover rather than assuming they work.
Why does the network assessment come first?
Because call quality follows the LAN. Handsets are powered devices sharing the same switching as everything else, and voice on a flat network with cameras, guests and building systems will sound poor regardless of where the platform lives. Assessing quality of service, switch capability and power budget before the platform choice avoids blaming the wrong layer.
What do you need to advise on telephony?
The endpoint list split by what must survive an outage, the analogue points still in service, the integrations required, peak concurrent calls rather than extension count, the current network's condition, and who will own the platform after handover. From those we advise an architecture and route the commercial question to a written estimate after drawings.
· Begin
Review a voice architecture
after a look at the drawings.
Share drawings, a BOQ, a project brief or site information and a project lead will return an engineering reading — not a sales pitch — within two working days.