Are you a Centrex user? Have you even heard of the term Centrex? For those of us who are new to the UC space in the last 15 years, you may or may not have heard of the word Centrex, or “Central Exchange,” a.k.a. the original “Cloud.” Centrex back in the 70s was the mainstream telephony solution for most larger enterprises. Centrex provided some interesting features that were really worthwhile at the time:
High availability was built-in to every Centrex, which resided in the Central Office (I was responsible for an 8,000-line Centrex at one time). Redundancy and automatic back-up to generator were part of the solution and uptime was extremely high at 99.999%
Extensions native to the Centrex were available just about anywhere, as long as you were connected via an Off Premise Extension (OPXs) and were willing to pay for the mileage charges associated with such (mileage-sensitive circuits are non-existent today, although we do have a client with OPXs as I write this), similar to remote workers in today’s environment
Integration to other Centrex's and premise PBXs were available via tie trunks (analog at the time, then eventually replaced by T-1 "channelized" circuits)
Centrex offered based features such as DID service, voice mail, call accounting, transfer, conference, and bridged line appearances - all team members who had bridged appearances could see who was on the line. "Sophisticated" features included "ring, no ring" on any given extension on any phone, user choice, and speed dial. Of course, there was no internal programming available back in the day for soft moves and changes - most everything required a change order, or MACD (Move, Add, Change, Delete)
Most Centrex’s provided some level of Call Center or ACD, Automatic Call Distributor with minimal features at best. They included call routing and reporting and little else outside those basics
Centrex offered minimal Capital Cost outlay (CAPEX), most for implementation and turn up, while all else, including Centrex extensions and features, as well as end points, were rented, or OPEX
Now since all TDM digital voice communications have been at end-of-support for over 60+ months, Centrex (TDM as well IP) and its ACD affiliate have slowly been eroding. We have one client with a 7,000-line Centrex and ACD utilized for close to 30 years with capacity issues and end-of-support. The vendor has recently advised the client that it cannot add any more Centrex lines, period. In my own experience of 30+ years in the industry, I have NEVER witnessed a Centrex at capacity.
Both TDM Centrex and IP Centrex and ACD require too much maintenance, physical space, physical interaction, and continued specialized training for a legacy technology on the part of the vendor. All parts have been refurbished for some time. Therein lie the reasons for Centrex retirement.
So What are the Risks?
The risks associated with staying with a grandfathered legacy technology such as Centrex are significant. They include, among others:
System End-of-Support and Spare Parts
Manufacturer announces End-of-Life of their telephony-based system (Centrex in this case)
Spare parts are refurbished and increasingly become less available, maintenance contract support and SLAs for mean-time-to repair over time become an issue, and costs may become a major issue
Notices from the providers give 12-24 months’ notice on end-of-support even to this day, meaning that any larger enterprise has little time to replace such a system, especially if 1,000+ end points and above (Microsoft recently announced 14 month end-of-support for 3rd party UM integration, for example)
Capacity Issues with Current Systems and Associated Costs
Systems at capacity require additional hardware investment for a temporary solution (on-premise or cloud) to extend the current Centrex out further, and some increases by as much as 40% of a new system, in my experience
Capacities are typically a BIG flag for not having a lot of time left for vendor support
Capacities and temporary add-ons create a more complex maintenance environment
Note that one can always create a premise "hybrid" solution with tie trunks between the Centrex and premise system
Newer systems added onto older system to temporarily solve capacity issues is not a good solution unless it is the going-forward replacement solution
No Investment by Telecom Manufacturers in Traditional TDM Centrex and Premise-Based Voice Systems
TDM, for all intents and purposes, has been dead for years now
Centrex users are now being given notice for end-of-support similarly
Consumer-Driven UC Capabilities Are Here In The Enterprise and NOT Available in legacy Centrex
Mobility/twinning, Unified Messaging, IM/chat, presence, LDAP and Active Directory integration, Collaboration, softphones, desktop audio conferencing, desktop video conferencing are driving the need to replace legacy Centrex. Even Caller ID is not available on some legacy Centrex systems, really!
Fewer Trained Technicians
Knowledge base "how to fix" has eroded significantly
Difficult to find vacation, sick replacements for staff with legacy expertise
Systems Age (we use 7+ years or more as a baseline)
Any Centrex or premise-based system requires either some type of an upgrade or replacement at 7+ years in place, and 10+ years is a clear indication of the deterioration of support for parts and technicians
Expect manufacturer notices, spare parts unavailability, upgrade unavailability, and fewer trained technicians over time
Risk of a Multi-Day Outage Increases
State of the systems poses greater risk to basic communications services - a single outage could last several days.
How would your organization communicate in the event of a multi-day outage? (Several financial enterprises encountered such after Hurricane Sandy in NY City metro area, now Hurricane Harvey in Texas)
What risk(s) would this pose to the safety of the staff and community?
"Good Money After Bad"
Conclusion (Part 1)
Yes, there is risk with your Centrex environment, and something to seriously consider. Interestingly though, the "hiccup" in migrating from a legacy Centrex to a new UCaaS or CaaS solution may not be as far a reach as one would think. Both are OPEX models and the biggest hurdle financially when migrating to the cloud.
If you are already on Centrex, then you paying into an OPEX model. Your financial model migration may not be as difficult to migrate to as would a traditional CAPEX UC model.
In Part 2 we will cover what an enterprise can do and how you can be proactive in the planning and replacement process for your legacy Centrex or legacy ACD.
This article was originally published on BCStrategies.