Toshiba left the business. Nortel has been gone for years. Avaya has been through Chapter 11 twice, Mitel has been through it too, and NEC has wound down its phone business outside Japan. Meanwhile the copper lines feeding it are being retired and repriced, and the rules about how it must handle 911 have changed. The system still works - that is exactly why nobody has looked at it.
This is why a phone system that has been fine for a decade suddenly is not. The equipment ageing is the slowest of the three - the other two have dates attached to them that somebody else chose.
Bankruptcies, acquisitions and outright exits have left a lot of installed systems with no manufacturer behind them. No firmware, no security fixes, replacement cards sourced second-hand, and proprietary handsets that cannot be bought new when one dies.
Analog lines and PRI circuits are being withdrawn, and where they survive the pricing has been deregulated. Plenty of businesses are now paying more per month for a handful of legacy lines than a whole modern system would cost to run.
Federal rules now require multi-line phone systems to dial 911 directly with no prefix, to notify someone on site when it happens, and to pass a usable location. Many older systems do none of the three.
Two federal rules changed what a business phone system has to do. Kari's Law requires that someone can dial 911 directly - without pressing 9 first - and that the system notifies a designated person on site when a 911 call is placed, so responders can be met at the door. RAY BAUM'S Act requires that a usable, dispatchable location goes with the call, not just a street address for a building with four floors and six suites.
An older PBX programmed in an era when dialling 9 for an outside line was universal will often fail the first test outright. That is a genuine liability question as well as a compliance one, and it is worth putting in front of whoever handles your insurance and your legal advice rather than taking our word for it.
Almost everyone who calls on you about this will offer the same thing: hosted seats, priced per user, per month, forever. It is a real option and sometimes it is the right one - but it is worth seeing it for what it is before you sign.
Per-seat hosted telephony replaces a system you owned with a subscription you rent. The bill scales with headcount rather than with usage, so growing costs you more for capacity you already had. The configuration lives in someone else's portal. And the exit is deliberately awkward - your numbers, your call flows and your recordings all sit on the far side of a support ticket.
That is the same pattern as the firewall subscription and the hypervisor licence. A phone system is just the place it is least often noticed, because the monthly figure per user looks small until you multiply it by your headcount and then by five years.
There is a third option. Own the platform, keep your numbers on portable SIP trunks you can move between carriers, and pay for what you actually use. We deploy it, we maintain it, and you are not renting your own extension list.
Hosted per-seat is not a bad product - for a small team with no IT presence and no complex call handling it is often genuinely the right answer. The comparison that matters is what each one costs you in five years and what happens when you want to leave.
| Keep the ageing PBX | Hosted per-seat UC | Owned platform, maintained by us | |
|---|---|---|---|
| Cost shape | Low until something fails, then a large unplanned bill. | Predictable, per user, per month, indefinitely. Grows with headcount. | A deployment cost, then maintenance. Scales with capacity, not headcount. |
| Vendor risk | Manufacturer may be gone. Parts second-hand. | Provider owns the platform, the portal and your configuration. | Open platform on standard hardware. Multiple carriers, multiple handset makers. |
| Your numbers | Tied to legacy circuits being withdrawn. | Ported to the provider. Moving again means porting again. | On SIP trunks you control. Carrier changes do not mean a system change. |
| Handsets | Proprietary. Often unobtainable new. | Usually provider-supplied or locked to their service. | Standard SIP. Buy from anyone, replace individually. |
| 911 compliance | Frequently non-compliant with current rules. | Generally handled, but confirm location handling per site. | Direct dialling, on-site notification and dispatchable location configured and documented. |
| Analog stragglers | Already wired in - the one thing it does well. | Usually your problem to solve separately. | Surveyed and migrated deliberately as part of the project. |
| If the internet drops | Keeps working on copper, until the copper goes. | Calls fail over to mobiles if configured. | Failover designed in - second circuit, trunk failover, or both. |
| Support | A third-party maintainer, or one contractor who knows it. | A provider queue. | Us, alongside the rest of your infrastructure. |
| Leaving | Forced, eventually, on the vendor's or carrier's timing. | Port out and rebuild the configuration elsewhere. | The platform, the numbers and the documentation are already yours. |
Phone migrations fail in two places: the number port, and the handful of analog things nobody remembered were on the phone system. Both get their own step here, well before anything is switched.
Extensions, call flows, menus, hunt groups, voicemail, recordings, and every line and circuit you are paying for. The billing review on its own frequently finds circuits nobody has used in years - that alone has paid for the assessment more than once.
Elevator phones, fire alarm panels, fax lines, door entry, gate intercoms, overhead paging, alarm dialers, the credit card terminal in the back office. These are the things that get discovered at 6pm on cutover day. We walk the building and list them, and each one gets a decided answer - migrate, keep a dedicated line, or replace with a cellular unit.
How calls should be answered, routed, escalated and recorded - agreed with the people who actually answer the phones, not just with IT. This is the point where most businesses fix the menu everyone has complained about for years.
The new platform goes in alongside the old one with temporary numbers, and gets tested properly - internally, externally, on mobiles, to and from the sites you call most. Your existing system keeps answering every real call throughout.
Direct dialling from every phone type, on-site notification firing, and the dispatchable location that gets transmitted - verified per site and documented, in coordination with your provider. This is tested, not assumed.
Least critical numbers first, main lines last, each batch confirmed working before the next is submitted. Porting runs on the carriers' timetable, so it is planned around a date rather than squeezed into an evening.
We do not decommission anything on cutover night. The old PBX stays powered and configured, and until a number has fully ported it can still be pointed back. Nothing is unplugged until you have lived with the new system and said so.
Written call flows, an administrator who is not us, a short session for whoever answers the phones, and the configuration exported and stored with the rest of your documentation. Then we maintain it alongside everything else.
No. Numbers are ported, which is a regulated process - they remain yours throughout. The risk in porting is timing rather than loss, which is why we port in stages, keep the old system live, and never submit a port for your main line first.
They get surveyed and decided on before anything moves - this is step two for a reason. Some genuinely need to stay on a dedicated analog line, some are better served by a cellular device, and some can move. What they must not be is discovered after the fact. Life-safety devices in particular have their own inspection requirements, so we coordinate rather than improvise.
Proprietary digital handsets from an old PBX will not carry over - they only speak to that system. Existing standard SIP handsets usually can, if they are not locked to a provider. We will tell you honestly which of your phones have a future, and phased handset replacement is a normal way to spread the cost.
It should not be, but it depends entirely on the network underneath - which is a large part of why we do this alongside the rest of your infrastructure. Voice traffic gets its own segment and priority, and we size and test the circuit before committing. A phone system deployed onto an unprepared flat network is where the reputation for bad VoIP came from.
This is a design question and it gets answered up front. Options include a second circuit with automatic failover, trunk-level failover that reroutes inbound calls to mobiles or another site, or keeping one analog line for a specific purpose. Most sites end up with a combination. It is also a good moment to look at the edge as a whole - see how we handle the network edge.
Sometimes, yes - and we will say so. If your staff already live in Teams, your call handling is simple, and you are prepared to add calling plans or a SIP connection, it can be a sound answer. It is a weaker fit where you have complex routing, reception and paging needs, a lot of shared or common-area phones, or sites where the analog estate is significant. The honest version is that it depends on how you actually answer calls, which is what the assessment establishes.
Less than they fear, because the new system is running and tested for weeks before it takes a real call. The visible change is the handset on the desk and a short walkthrough. The one thing we insist on is involving whoever answers the phones in the call flow design - they know things about how calls actually arrive that no system export will tell you.
A deployment cost driven by site count, handsets and call flow complexity, then ongoing maintenance as part of the co-managed arrangement. It is usually set against what you are already paying for legacy lines and maintenance contracts, which is frequently more than people expect once the billing review is done. We will put real numbers against your current invoices rather than quote a range.
Hypervisor licensing. Firewall subscriptions. Backup seat counts. Per-endpoint tooling. Per-extension telephony. Individually they are line items - together they are a business you do not control, renewing on somebody else's schedule at somebody else's price.
We replace them with platforms you own, standardized and documented. Fewer renewals, more capability, and the freedom to change course whenever you choose.
Starting with what you are actually paying today.
Tell us what system you have, roughly how many extensions and sites, and what you spend on lines and maintenance. We will tell you what is forcing the timeline, what the options cost over five years, and whether replacing it is urgent or simply sensible.
We do not share your details, and we will not add you to a drip campaign.