SIP trunking connects a PBX you already own to the phone network over your internet circuit — you keep the system, the handsets, and the dial plan. Hosted PBX replaces the phone system entirely with a cloud platform the provider operates. If your PBX works and has life left in it, trunking is the smaller, cheaper change. If it is end-of-life, unsupported, or holding you back, hosted is where you are going anyway.
This is one of the few telecom decisions where the answer is usually obvious once you look at the equipment. The question is not which technology is better; it is whether the phone system you own is worth keeping.
The financial shape differs too: trunking keeps capital you have already spent working, while hosted converts telephony into a per-user operating cost with no hardware refresh at the end of it.
| Criterion | SIP trunking | Hosted PBX |
|---|---|---|
| Your phone system | Kept — on your premises | Replaced by the provider's platform |
| Handsets | Usually kept | Replaced or reprovisioned; softphones common |
| Who runs the platform | You do | The provider does |
| Feature upgrades | When you upgrade the PBX | Continuous, on the provider's platform |
| Cost shape | Per channel, plus your existing hardware | Per user, per month |
| Multi-site behaviour | Depends on how your PBX handles sites | Native across locations |
| Remote and mobile working | Depends on PBX capability | Built in |
| Disaster behaviour | On-site system is a single point of failure | Platform survives a site outage; calls reroute |
| Equipment kept on site | The PBX itself, a gateway or SBC, handsets, and power protection for them | Handsets and a switch that can power them |
| Security responsibility | Yours — hardening the PBX and SBC, and the toll-fraud exposure with it | Shared — the platform is the provider's, credentials and endpoints remain yours |
| Deployment effort | Trunk cutover, dial-plan work, and testing against the existing PBX | Provisioning handsets, porting numbers, and training users |
| Where a failure lands | On your PBX, which you can inspect and restart | On a provider platform, which you can only report |
A supported, well-configured PBX that meets your needs is an asset, and replacing it to move to the cloud is spending money to reach the same functionality. Retiring PRI circuits in favour of SIP trunks frequently cuts the monthly bill substantially on its own, adds channel flexibility, and requires no retraining. If the PBX has three or four years of supported life left, trunking is usually the better financial decision.
An unsupported system, a failed hardware component with no replacement path, a workforce that now works from several places, or a multi-site organization tired of maintaining a system per location. Hosted PBX also removes the on-site system as a single point of failure: if the office loses power or connectivity, calls can reroute rather than simply failing.
Enough upstream capacity for concurrent calls — voice is undemanding on throughput and unforgiving on jitter — and prioritisation so a large upload does not degrade a call. This is the reason voice quality problems are so often network problems. Running voice over the same dedicated fiber circuit as your data, from the provider who operates that circuit, removes the vendor boundary that makes those problems hard to resolve.
Whichever you choose, existing numbers port to the new service. It is a scheduling and paperwork exercise before it is a technical one: accurate current bills, a letter of authorisation, a correct service address, and a port date coordinated with the losing carrier. Existing service should stay live until the ported numbers are confirmed working.
This is the practical difference that surfaces during an incident. With SIP trunking the responsibility boundary is the trunk: the provider is accountable for delivering calls to it, and everything behind it — the PBX, the dial plan, the handsets, the LAN — is yours. With hosted PBX the boundary moves out to the network connection, and the platform behaviour becomes the provider's problem. Neither removes the need to know your own network, because in both models a call quality complaint is far more often a LAN, firewall, or circuit issue than a platform one.
Voice fraud is unglamorous and expensive: an exposed SIP port, a weak extension password or a default credential, and calls are placed to premium destinations at volume overnight. With SIP trunking, the exposed surface is your PBX or SBC and the hardening is your responsibility — restrict which addresses may register, disable unused international destinations, and set a spend cap with the carrier. With hosted PBX, the platform is hardened by the provider, but a compromised user credential still places calls. Ask either way what the fraud ceiling is and who absorbs the charges, and put the answer in the agreement rather than discovering it in a monthly invoice.
Voice is unusually sensitive to variance rather than to bandwidth. A call needs very little capacity and a great deal of consistency: jitter and packet loss degrade audio long before a link runs out of throughput, which is why voice quality often falls apart on a connection that speed tests well. Whichever platform you choose, the questions are the same — is there capacity reserved for voice, does the network prioritize it, and what happens to in-progress calls when the primary connection fails. A failover plan that reroutes calls to mobiles is a legitimate answer, provided it has been tested.
If the PBX is modern, paid for, and doing something specific that the organization depends on, SIP trunking keeps that investment and usually costs less per seat. If the PBX is approaching end of support, or the person who understood it has left, hosted is the better destination and the migration is easier to justify while the old system still works than after it fails. We would rather have that conversation eighteen months early than during an outage.
Six questions that settle this choice faster than a feature table. The answer to each one tells you something the specifications do not.
A supported system with life left in it is the main argument for SIP trunking. An unsupported one is a migration waiting to be scheduled.
Distributed and remote-heavy organizations get more from a hosted platform, because the platform is already where the users are.
If that person is leaving, retired, or a contractor you call twice a year, the operational case for keeping a PBX is weaker than it looks.
Decide which numbers must reroute and where. Then test it, on both models.
Paging, door entry, alarm lines, fax and call recording are the usual survivors. Inventory them before assuming a platform swap is clean.
Ask this explicitly of any provider on either model. The absence of a clear answer is itself an answer.
Yes, and it is a common path. Trunking extends the life of existing equipment while removing PRI costs; when the PBX eventually retires, the numbers move to a hosted platform. Nothing about choosing trunking now makes hosted harder later.
If it is SIP-capable, directly. If it is older, a session border controller bridges it. Compatibility should be confirmed before the order rather than discovered at cutover, which is the expensive way to find out.
Base it on concurrent calls at the busiest hour, not headcount — most organizations need far fewer than they assume. Unlike PRI, channels adjust without adding physical circuits, so accurate sizing carries no penalty.
With hosted PBX, calls can be rerouted at the platform to mobiles or another site, because the system is not in your building. With on-premise SIP trunking, inbound rerouting depends on what your provider supports. Ask specifically — it is the difference between an outage and an inconvenience.
Describe what the connection has to carry and where. An engineer will tell you which service actually fits — including when the cheaper option is the right one.
Service availability depends on location, network proximity, capacity, and engineering review. Share an address and we will confirm what can be delivered there.