An IP PBX runs your phone system over the IP network. How it works, what your network has to provide, and how on-premise and cloud PBX split the cost and the responsibility.
Monday morning, the head office is taking the calls, the sales branch has lost track of two queues, and half the team is dialling from a laptop at home. The old PABX still works. Every change to it needs a ticket, a site visit, or the one person who remembers how it was configured. For a company that's growing, that arrangement slows the business down as much as it loads the IT team.
An IP PBX moves the phone system onto the IP network and treats it like any other piece of software. The decision in front of you covers network design, hosting, security, service continuity and the admin work each change costs. You can keep an IP PBX on site, run a hybrid setup, or hand the infrastructure to a cloud PBX hosted in the European Union.
This guide is written for IT integrators, telecom resellers and growing small and mid-sized businesses weighing those three models. It sets out how the system works, what its total cost of ownership actually contains, and how a multi-site migration runs without dropping calls.
An IP PBX is a private branch exchange that runs over the IP network. It connects IP desk phones, softphones and telephony apps, carries the voice as data packets, and uses SIP to set up and manage each call session. The switching logic lives in software on a server or in a datacentre.
Think of a railway junction. The signal box reads where a train is headed and sets the points. An IP PBX reads an inbound call, applies the rule that matches it, and sends it to an extension, a queue, an IVR menu or voicemail. The operator side of that same exchange is covered in what a SIP trunk does.
A legacy PABX keeps telephony on its own infrastructure, with dedicated cabling and handsets wired back to a dedicated exchange. An IP PBX uses the data network for the same job, so an extension becomes a user record instead of a pair of copper wires.
A hybrid PBX runs both. That's how most sites actually cross over, because existing handsets and trunks stay in service while IP extensions arrive alongside them.
The phased path matters for cost. A company can keep part of its estate, put IP handsets where the pain is sharpest, then move the call-handling rules into the converged platform once the network is ready. Nothing forces a single cut-over night.
An IP handset on its own doesn't improve a call. Voice shares the network with backups, video meetings, file transfers and ordinary browsing, so congestion, a missing quality-of-service policy or an unmonitored link turns into clipping, echo or a metallic voice. When calls sound wrong, the fault usually sits in the network and not in the phone.
A design that holds up includes:
Traffic separation. Voice and data shouldn't share one flat network as undifferentiated traffic.
Bandwidth monitoring. Someone has to watch available capacity and catch degradation before users report it.
Access hardening. The IP PBX needs protection against registration spoofing, toll fraud and interception.
Documented routing. Opening hours, overflow and fallback rules have to stay readable to whoever is on call.
An IP PBX earns the same availability requirements as any other critical part of the information system. What to measure, and at what threshold, is set out in our piece on VoIP call quality.
An on-premise IP PBX and a cloud PBX deliver comparable features and divide the responsibility differently. Own the platform and you own the hardware, the patching, the backups and the recovery plan. Subscribe to one and a provider operates it in a remote datacentre, while you keep your users, your call rules and the quality of your own access links.
Total cost of ownership settles this question, and it runs wider than the billing model. It absorbs the hardware, the licences, the maintenance contract, the backups, the upgrades, the monitoring, the skills you keep on hand, and the hours each change takes.
| Criterion | On-premise IP PBX | EU-hosted cloud PBX |
| Upfront investment | Buying and installing the infrastructure, with a renewal cycle to budget for | A subscription plus any local handsets, with no exchange to run on site |
| Administration | Sits directly with your IT team or your integrator | Feature administration is centralised; the provider operates the platform itself |
| Updates | Planned, tested and applied by you or your supplier | Included in the service, on the terms the contract states |
| Multi-site | Deployment and interconnection designed site by site | Managed centrally, provided each site has suitable connectivity |
| Scalability | Bounded by installed capacity, licences and hardware | Adding users and rules is generally quicker; check the contract for the limits |
| Continuity | Rests on local redundancy, your links, your power and your recovery plan | Rests on the provider's architecture, its service commitments and your internet access |
| Data and compliance | Direct control of the environment, with all security and maintenance to organise yourself | Hosting and processing need examining, with EU datacentres and written guarantees preferred |
| Lock-in | Tied to your own infrastructure and to the skills available in house | Tied to the provider, its exit terms and the portability of your data |
A business with one part-time IT person tends to gain most from the hosted model, because the repetitive tasks go somewhere else. A larger firm with private network constraints, physical access control or deep integration requirements may prefer the system on site, especially where the skills and the redundancy already exist. The feature lists look alike on a datasheet. The operating load is where the two models part company, and what a cloud PBX is describes the hosted side in more detail.
A cloud PBX pays off when you want one set of call rules across several sites, faster changes, or no specialised hardware to maintain. It shifts part of the operation to a provider, which puts the weight on three parts of the contract: hosting transparency, service commitments and exit terms. Network, security and continuity stay on your side either way.
Portability belongs in the evaluation before signature. The EU Data Act gives business customers of cloud services rights around switching provider and porting their data, together with the technical information and interfaces that a move requires. For a phone system, apply that to the concrete assets: the numbers, the call recordings, the directories, the configuration files and the call logs. Ask how each one leaves, in which format, and who does the work.
A call from a browser tab, an IP desk phone in a meeting room and a mobile on a train can all land on the same IP PBX. SIP organises how the system, the operator and the endpoints open and close each session. WebRTC lets someone call from a compatible browser with no dedicated handset on the desk. Together they widen where the phone system reaches, and they widen the surface you have to defend.
Voice, call metadata and recordings each need classifying by sensitivity, by purpose, and by who is allowed to listen. An IP telephony platform with weak isolation exposes an organisation the same way a badly protected server does.
Separating voice from data traffic contains an incident and keeps the diagnosis readable. The firewall filters which sessions are permitted. Unique passwords, separate accounts and narrow administration rights close the easy abuse paths. Updates stay on a schedule even while the platform behaves.
An exposed or multi-site deployment earns more than that. A session border controller, intrusion detection tuned for voice traffic and stronger authentication on administrative access add the extra controls. SIP TLS protects the signalling when it's configured properly. Media encryption needs checking separately with your integrator, because browser and handset support varies.
Architecture principle: a phone system's security reaches well past its admin interface. It covers the access paths, the traffic, the endpoints, the logs, the backups and the recovery procedure.
These choices also set the operating load. An on-premise IP PBX leaves maintenance, updates and part of the monitoring with you. A hosted platform absorbs some of that, and the scope it absorbs is contractual rather than self-evident.
GDPR compliance follows from what you do with the data, and a server address is one input among several. The work is an inventory of what's processed, defined authorisations, written terms with your processors, retention limits, and security measures you can show an auditor. Hosting inside the European Union simplifies the transfer analysis, and the contractual and technical guarantees still have to exist on paper.
European sovereignty also means reading which law applies to the provider, how you get your data out, and who can reach it technically. Voxbi hosts in EU datacentres for exactly those reasons. Buyers in the public sector or in regulated industries often carry an extra certification requirement from their own supervisor, and that requirement belongs in the specification before any shortlist exists.
A growing company usually starts with a simple front desk, then adds a sales team, a support line and different opening hours per function. With an IP PBX, lines stop being organised around physical desks. Calls follow groups, queues and on-call rules that are written down, and the office manager changes the structure without booking an engineer.
In a multi-site firm the problem is scatter. Each branch has its own numbers, its own habits and its own overflow rules. A central platform can standardise the scenarios while keeping a local greeting and local hours per site, with shared visibility for the people authorised to see it. Telephony starts working as a coordination tool at that point: a colleague can be reached according to status, a ringing call can be picked up by another team, and the IT team investigates incidents against one configuration.
Growing company. Pool the lines, build queues, and add users without rebuilding the installation.
Multi-site firm. Centralise the call rules, keep local numbers, and organise overflow between branches.
Hotel. Separate reception, reservations and internal services, with hours and priorities that follow the business.
Healthcare site. Protect sensitive conversations, organise call groups, and document continuity for the critical functions.
A hotel gains most from central administration, because reception hours and overflow rules change often. A healthcare site puts its attention on authorisations, retention periods and fallback procedures instead. The same feature, a call queue, gets configured differently depending on what a failure would cost.
Public bodies and schools hit a different constraint. Staff rotate, sites are numerous, and budgets have to stay predictable. A system administered by role, with clear rules and documentation a newcomer can follow, reduces the dependency on the one person who knows how it was built.
A migration starts with the inventory and not with the order form. You list the numbers, users, groups, opening hours, greeting scenarios, application dependencies and fallback paths. That map is where the forgotten rule surfaces, the one that would otherwise break a queue on cut-over night.
Audit what's running. Write down the numbers, extensions, queues, schedules and overflow rules, then compare real behaviour against the official configuration. The two diverge more often than anyone expects.
Prepare the network. Check connectivity, segmentation and quality of service at every site, and test representative call paths before any traffic moves.
Build the target platform. Create the users, extensions, queues, IVR menus and time-based scenarios in the new environment, and coordinate number portability with the operator.
Train the people. Receptionists, managers and administrators walk through their own screens, including everyday calls, transfers and the incident procedure.
Cut over in stages. Migrate by department or by site, watch the call statistics after each wave, and keep a rollback plan in writing.
Voxbi runs as a cloud PBX hosted in EU datacentres and administered from a browser in Voxbi Cockpit, with users, queues and call scenarios in one place and integrations for Microsoft Teams and Odoo. Numbers and carrier services come from Mixvoip on the telco side. Your integrator still has to validate the contractual scope, the responsibility split and the retention rules your sector imposes. The full sequence, with the timings, sits in our cloud PBX migration guide.
Control doesn't end on porting day. Queue statistics, missed calls, access rights and recovery procedures all need watching once the platform is in production. A migration without downtime means the risky changes were tested, scheduled and reversible.
The decision rests on a short checklist with hard answers behind each line.
Business needs. Reception, queues, IVR, mobility, multi-site, and the integrations you actually use.
Hosting model. Local control, cloud PBX, or a hybrid path across both.
Total cost. Hardware, licences, maintenance, administration, network and recovery.
Security. Segmentation, firewalling, updates, rights, encryption and monitoring.
Sovereignty. EU hosting, applicable law, portability and documentation.
Headroom. One admin model that serves ten users and several thousand.
The question underneath all six is how much of this complexity you want to keep in house and how much you want to hand to a European cloud PBX. A certified Voxbi integrator can qualify the use cases, test the network and stage the cut-over against your risk level.
Voxbi is a cloud phone system hosted in Europe, administered from a browser, covering users, queues, call scenarios and business integrations. Answer the six checks above for your own sites, then write to hello@voxbi.com to scope a staged move off your existing IP PBX.
VoLTE carries mobile calls as IP packets over the 4G network. Here's how the call path works, how it compares with VoWiFi and CSFB, and what to check before 2G and 3G go off air.
A SIP trunk connects your phone system to the public network over IP. How SIP trunking works, what it costs, and how to migrate without losing service.
How the public switched telephone network works, which equipment still depends on it, and how it compares with VoIP, SIP and WebRTC.
Talk to us or to a certified Voxbi partner.
