Current Location ：
Running Two Phone Systems: Integration Risks Between IP-PBX and Cloud PBX
Two phone platforms in one business is rarely a deliberate architecture. It usually arrives through a merger, an acquisition, a departmental purchase, or a pilot that was never unwound. The systems then coexist, and the overlap creates problems that are invisible until something fails, because each system works correctly on its own. The risk is not that either platform is broken; it is that the boundaries between them are undocumented.
Map the Boundaries Before Anything Else
| Boundary | Question to answer | Typical ambiguity |
|---|---|---|
| Number routing | Which system owns which numbers, and what happens to calls between them? | Numbers configured on both systems, routing by unpredictable order |
| Trunk interconnect | Is there a direct trunk, or do calls traverse the PSTN? | Undocumented direct trunk treated as PSTN, incurring cost and delay |
| Recording | Which system records which calls? | Some calls recorded twice, others not at all |
| Compliance | Which system holds the recording retention policy? | Policy applies to one platform only |
| Emergency calling | Which emergency configuration applies at each site? | Conflicting configurations with no single owner |
| Numbering | Which system is the system of record for extension numbers? | Duplicate extensions existing on both platforms |
| Support | Who is responsible for a fault spanning both? | Each vendor points at the other |
The Direct Trunk Is Usually the Right Interconnect
Connecting the two platforms with a direct SIP trunk is almost always preferable to routing intersystem calls through the PSTN. A direct trunk avoids per-minute cost, avoids the delay of an extra signalling path, and preserves caller ID in both directions. The cost is that you must document the interconnect as a designed interface with a defined numbering range and a test plan, rather than letting it emerge from configuration attempts.
Call Routing Between Systems
The pattern that works is a clear ownership rule: each number lives on exactly one system, and intersystem calls use an agreed dialling plan for the other system's range. Ambiguity here is what produces call loops, where one system forwards to the other and back, or unreachable extensions that neither system can explain. Where an extension number exists on both platforms, treat it as an incident and resolve it before anything else.
Recording and Compliance Exposure
Two platforms usually means two recording stores, two retention configurations, and two access control models. If calls can move between systems, then whether a call was recorded, where the recording lives, and who can retrieve it may depend on which platform handled the call. For organisations with recording obligations, this is a compliance gap rather than an inconvenience, and it should be closed before the overlap persists.
Migration Is the Real Fix
The overlap is a transitional state, and treating it as permanent doubles the operational load. A staged migration consolidates onto one platform: one site or department at a time, with a clear target and a decommissioning step for the platform being retired. Sites in the overlap should have an explicit end date, because a migration without an end date becomes permanent duplication by default.
Checklist for an Estate Already in Overlap
- List every number and every extension, and mark which platform owns each
- Identify duplicate extension numbers existing on both platforms and resolve them
- Document the trunk interconnect, including whether it is direct or via the PSTN
- State which platform records which call type, and where the recording is stored
- Confirm a single emergency calling configuration per site
- Assign an owner for faults that span both platforms
- Set a migration target and an end date for the overlap
Redstone Approach
Redstone IP-PBX platforms interop with cloud PBX platforms over SIP trunks with configurable dialling plans, so intersystem routing can be defined explicitly rather than left to configuration order. Redstone can also support staged migration, moving sites or departments onto a single platform with a decommissioning plan for the platform being retired, closing recording and compliance gaps that duplication creates.
Redstone provides hybrid estate integration planning including trunk configuration, dialling plan design, recording consolidation, and staged migration sequencing.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
