3CX for Government: Escaping Legacy PBX Lock-In

Ask a council IT coordinator what’s wrong with their phone system, and the answer is rarely about features. It’s that adding an extension takes a vendor ticket, the handsets only work with one manufacturer’s system, the maintenance renewal goes up every year, and the migration path to anything modern runs through the same supplier who set the price. That is not a technology problem. That’s a procurement problem that was created a decade ago and gets re-signed every three years.

How councils end up locked in

Nobody chooses lock-in. It accumulates, usually in this order.

The original system was bought as a package: PBX, handsets, cabling, maintenance, all from one supplier, and, at the time, that was the sensible way to buy telephony. Then, the handsets became a sunk cost, so replacing the PBX meant replacing 300 phones as well. Next, the person who understood the configuration retired, and the documentation went with them. Finally, the vendor’s support contract became the only way to make routine changes, which converted an operating decision into a purchasing one.

By the time an end-of-life notice arrives, the organisation has no bargaining position left. The incumbent knows the switching cost, and that cost is exactly what they have spent a decade building.

The way out is not simply choosing a different vendor. A council that replaces one proprietary system with another has bought 12 more years of the same problem with a newer interface. The way out is writing a specification that makes lock-in structurally impossible next time.

The dependency test

Five questions answer it: 

1. Can your IT team add an extension without raising a vendor ticket? 
2. Can you buy handsets from more than one manufacturer? 
3. Does the system run on standard server hardware? 
4. Can you move it to different hosting? 
5. Do you hold the configuration documentation? 

Three or more no answers is lock-in.

Run it honestly, because each answer maps to a specific clause you’ll want later. The extension question measures operational autonomy, which is what determines whether your team spends its week on service requests. Next, the handset question measures whether your next hardware refresh is a competitive purchase or a captive one. The hardware question determines whether a server refresh becomes a phone system project.

The hosting and documentation questions are the two most often answered wrongly, because people assume the answer is yes until they check. Ask your provider to send the current configuration documentation. What comes back, and how long it takes, is the real answer.

What to write into the specification

This is where the next decade gets decided, and it costs nothing to get right. Seven clauses do most of the work.

The third clause is the one that changes daily life, and it’s the one incumbents resist most, because routine change requests are recurring revenue. The sixth and seventh are the ones your records and information manager will care about, and they should be in the specification rather than negotiated afterwards.

An open-standards platform running on standard hardware is what makes most of this achievable. A 3CX phone system can be deployed on-premises on existing virtualisation infrastructure or hosted, uses any SIP-compliant handset, and puts extension and call flow administration in the admin console rather than behind a support contract.

Are council call recordings public records?

For instance, in Queensland, call recordings made in the course of council business are public records under the Public Records Act 2023, and retention and disposal schedules are format-neutral, so audio is treated the same as a document. That means a system default that deletes recordings on a rolling cycle may amount to an unauthorised disposal.

This catches organisations out because phone systems ship with a storage-management default, not a records-management one. Thirty or ninety days is a disk space decision made by an engineer. Whether that period is lawful is a question for your retention and disposal schedule, and under the 2023 Act, the meaning of disposal is broad enough to include altering a record, with unlawful disposal an offence.

Here are three practical steps to follow: 

• First, decide what you record before go-live because call recording can be applied selectively by queue rather than universally, and recording less is often the cleaner compliance position. 
• Second, set retention deliberately and document who approved it.
• Third, remember that recordings and call logs may be captured by a Right to Information request, which means they need to be findable, not just retained.

Other states have their own equivalents and the detail differs, so confirm the specifics with your records manager or RTI area rather than treating this as settled. The general point holds everywhere: a call recording is a record, and the phone system’s default settings are not a records policy.

Can a council replace its phone system without an outage?

Yes, by building the new system in parallel with the live one and switching at a chosen moment rather than migrating in stages. Extensions, handsets, and call flows are configured and tested while the old PBX keeps running, so the cutover is a switch rather than a rebuild. Documented deployments have done this within a working day.

The parallel-build approach matters more in government than elsewhere, because a council switchboard carries obligations a business line doesn’t. Rates enquiries, development applications, animal control, road hazards, and the after-hours emergency number all have to keep working, and some of them are the public’s only route to an urgent response.

Two details do most of the work. Provision handsets before the cutover so the changeover is a reboot rather than a desk-by-desk rebuild. And keep the existing inbound services live until the new path has carried real traffic through a full business day, including the morning peak, because a rollback you can’t execute isn’t a rollback.

The trunk layer deserves its own line in the plan. Australian 3CX SIP trunks with a documented failover path affect uptime more than the choice between on-premise and hosted does, and number porting for a council with dozens of published numbers across depots, libraries and service centres is the task most likely to blow the timeline. Start it early.

Ask the incumbent in writing, before you go to market

The most useful next step isn’t a quote. It’s three questions to your current provider, in writing, because their answers become the evidence for your business case, and a written non-answer is evidence, too.

1. What is the documented end-of-support date for our current system, and what is the migration path to a fully IP platform? A vague answer here is the whole argument. A specific one tells you your timeline.
2. Can our staff add extensions, change hunt groups, and amend call flows ourselves, and if not, what does each change cost? Ask for the schedule of fees. Multiply by last year’s change volume, and you have a number for the submission.
3. Will you provide our full configuration documentation and administrative credentials, at no charge, within ten business days? This is the question that settles it. An organisation that owns its own configuration has options. One that doesn’t has a supplier.

File the answers. Whether you go to market this budget cycle or the next one, that correspondence is the foundation of the specification, and it’s worth more than any vendor presentation.

If those answers do point toward a replacement, three technical questions usually come next: whether your existing virtualisation platform can host the new system, what happens to the handset fleet you already own, and how many published numbers need porting across depots, libraries, and service centres. Com2 is a certified 3CX partner working with organisations across Australia, and those are quick questions to get answered. Call 1300 887 495 or get in touch.