Why consolidating multi-site PBXs on open source PBX is a different build
An operations leader who runs a mix of branch PBXs and wants one central Asterisk platform should know early that the build hinges on three things: dial plan design, behavior when the WAN fails, and a dispatchable 911 location for every site. The software is the easiest part. Asterisk with FreePBX as the administrative layer can be self-hosted in your own data center or cloud account, but the project succeeds or fails on how calls are routed between sites, what each branch does when its link to the core drops, and how the migration is sequenced across numbers, trunks and handsets.
Start by inventorying every existing branch system, its trunks, its numbering and its emergency addresses before any design work. Decide which branches keep local trunks for survivability and which route everything through the central platform, and confirm how each legacy system handles calls during an outage. Design the dial plan so that internal extensions, site prefixes and outbound routes are unambiguous across sites, and document the 911 location for each site as a separate, testable record. Confirm with your telecom counsel and carriers which 911 obligations apply to each location and which carrier features you need to meet them.
The real work is the migration sequence. Port numbers in an order that matches the cutover plan, not the order in which the old systems were bought, and confirm each carrier's porting lead times with them in writing. Run parallel dial plans in a lab, then move one pilot site at a time, with a rollback path for each cutover window. Ask any implementation partner to show the written test plan for WAN failure, 911 routing and per-site location before the first branch moves, since those tests are what your auditors and your emergency response partners will ask to see.
Which requirements the consolidated design must meet
This table maps each requirement that shapes a multi-site Asterisk design to its source and to what it changes in the build. Read it as a checklist to settle before dial plan and cutover work begins, since several rows (911 location, CDR retention, porting windows) set constraints that are hard to retrofit later.
| Requirement | Source and what it asks | What it means for the build |
|---|---|---|
| 911 calling from multi-line systems | Kari's Law and RAY BAUM's Act, covered in the sibling 911 compliance topic, require direct 911 dialing and central notification, and dispatchable location for staff phones | Every site needs a dispatchable location record, direct 911 routing from each trunk, and a notification path to a staffed point; confirm the rules with counsel and your 911 service provider |
| Dispatchable location per site | Location must identify the caller's building and floor or area so responders can find them; the rules apply to fixed and non-fixed phones | Maintain a location table per site and per extension, updated on every move; test by placing calls from each site before cutover and document the results |
| Audit controls on call records | 45 CFR 164.312(b) requires audit controls that record and examine activity in systems containing ePHI, relevant where call records or voicemail hold patient data | Enable CDR and Asterisk logging to a central store, define who reviews them, and keep voicemail and recordings inside the same access controls as the rest of the clinical system |
| Protection of voice traffic in transit | 45 CFR 164.312(e)(1) requires technical measures against unauthorized access to ePHI sent over electronic networks, applicable only where calls carry ePHI | Use encrypted signaling and media (TLS and SRTP) across WAN links and trunks, and restrict management interfaces to the internal network |
| Retention of business communications | 17 CFR 240.17a-4(b)(4) requires broker-dealers to keep copies of business communications for at least three years, applicable only to regulated firms | Set retention for CDRs and recordings per site in the client's own storage, with tested restore and legal hold; confirm whether a branch's calls fall under the rule |
| WAN failure and local survival | Business continuity expectation, not a single statute; branch calls must still reach 911 and internal extensions when the WAN link drops | Plan local survivability at each branch (for example, a local Asterisk node or fallback trunk) and test 911 routing during a simulated WAN outage |
| Local trunks and carrier porting windows | Carrier porting schedules and local number requirements set when numbers can move; confirm lead times with each carrier | Port numbers in a sequence that keeps branch outbound and 911 routing working, and plan a fallback for numbers that cannot move on the cutover date |
How central Asterisk keeps branches working when the WAN fails
Branch survivability starts with a clear split between call control and call media. In a consolidated design, the central Asterisk cluster holds the dial plan, extensions, voicemail and trunk policy, but each branch keeps its own media path and its own route to the public telephone network. When the WAN link fails, phones at that branch should still register to a local survivable element, place calls out through a local PSTN gateway or SIP trunk, and dial local emergency and internal numbers without waiting for the central server. Before design sign-off, the team should write down, for every branch, which devices can operate in fallback, which numbers they can present, and which features disappear (voicemail access, central directories, shared queues, call recording).
The fallback path depends on hardware and firmware that you must confirm rather than assume. Ask each gateway and handset vendor whether the model supports local survivability or a fallback registrar, which SIP registration timers it uses, how it handles failover between a primary and secondary trunk, and whether its behavior is documented for your firmware version. Asterisk and FreePBX can be configured to support this pattern, but the exact failover behavior of a given branch depends on the gateway, the phone and the network path between them. Do not accept a generic statement about failover speed. Ask the vendor for their documented behavior and then measure it in a lab that matches your branch hardware.
Test registration and failover as a scripted exercise, not a single demonstration. A practical test plan cuts the WAN link at each branch in turn, confirms that phones re-register or switch to the local path, places inbound and outbound calls, checks that emergency calls route to the local PSTN path, and restores the link to confirm that calls return to central control without duplicate registrations. Record the results with timestamps, the Asterisk logs and the gateway logs for each run, because the same evidence supports your 911 documentation and your operational runbook. Repeat the test after every firmware change, dial plan change or carrier change, and plan a recurring check that your partner can run during support.
Which open-source PBX components fit a consolidation
A branch-to-central consolidation needs one call engine, one administration layer and a few supporting systems to track the work. The cards below separate what runs calls from what manages the migration, so each component has a clear job and a clear check before it is selected.
Asterisk as the call engine
Asterisk handles SIP registration, trunk routing, the dial plan and media for every site from one central core. For a consolidation, the central instance carries the routing logic that branch PBXs currently hold separately, so design decisions about contexts, inbound routing and outbound least-cost paths sit in one place. Confirm the Asterisk release line, its security support window and its long-term support status against the current published policy before you select a version, because the lifecycle determines how long your dial plan can run unchanged.
FreePBX as the administration layer
FreePBX provides the web interface for extensions, ring groups, inbound routes, trunks and call flows on top of Asterisk. It reduces the risk of hand-editing configuration across several sites, but it adds its own release cycle and module set. Check that the FreePBX version you choose is compatible with the Asterisk release you run, and test every module your sites rely on, such as emergency routing or paging, in a staging environment before cutover.
Zammad for porting tickets
Number porting across several carriers involves losing-carrier letters of authorization, service dates, rejected port requests and per-site reconciliation. Zammad, an AGPL-3.0 helpdesk, can hold each port request as a ticket with its own history, so the team sees which numbers are scheduled, pending or complete. Confirm that the helpdesk can hold the attachments and approval records your carriers require, and restrict access to the ticket queue because port requests contain account data.
GLPI or iTop for circuits
Each consolidated site has circuits, SIP trunks, routers, handsets and emergency location records that must match what the PBX believes. GLPI or iTop can store these as configuration items with owners, contract dates and relationships, which keeps the 911 location record and the trunk inventory in step during cutover. Confirm how each platform handles the relationship between a trunk, a site and a number block, and decide who updates the record when a site moves.
Monitoring and call records
A central PBX that fails takes every site with it, so each branch needs call-quality, registration and trunk status visible to the operations team during and after cutover. Choose monitoring tools that can alert on lost SIP registrations, trunk failures and rising jitter, and keep call detail records in a store your records policy covers. Confirm retention periods with your compliance team, since they set how long call data must remain available.
How a phased cutover moves branches without outages
The sequence inventories every branch, designs and tests the dial plan, 911 location and survivability before any number moves, then cuts sites over one at a time with a rollback path and documented evidence at each stage. Each phase closes with a defined output the client keeps.
Inventory every branch PBX, trunk and number
DeployOpen works with the client's telecom and network staff to record every legacy PBX, its make and software version, every SIP or PRI trunk, carrier contract, and every direct inward dial and toll-free block, mapped to the site it serves. Extensions, ring groups, hunt groups, IVR menus, paging zones and analog devices such as fax lines and elevator phones are listed too, since these are the items most often missed. The phase is complete when the client signs off a single inventory workbook that reconciles numbers against carrier records. Ask the carrier for a current number report before this sign-off, because porting depends on it.
Normalize the dial plan across sites
Using the inventory, the team designs one central dial plan in Asterisk and FreePBX that defines extension numbering, site prefixes, outbound routing, emergency and international rules, and how calls between branches traverse the network. Conflicting extension ranges and duplicate numbers across legacy systems are resolved here, with the client deciding which numbers stay and which change. The output is a written dial plan specification and a configuration set held in version control, plus a table showing old dialed patterns mapped to new ones so users and integrations can be told what changes.
Design 911 location and the test plan per site
Each site receives a documented emergency calling design: the trunk and路由 used for 911, the dispatchable location sent with each call, the notification path to on-site staff, and how fixed and non-fixed phones are handled. Where a branch uses a shared carrier or a remote endpoint, the design states which location source applies. The test plan lists the scripted 911 test calls and the expected location and notification results for every site. The phase closes when the client approves the design and the test plan, and the rules for the states and rules that apply are confirmed with the client's counsel, since obligations depend on jurisdiction and the Kari's Law and RAY BAUM's Act requirements.
Prove survivability in the lab
The team builds a lab replica of the central Asterisk platform and a branch survivability path, then simulates WAN loss, carrier failover, and central server failure. Each test records whether internal calls continue, whether local trunks carry outbound and emergency calls, and how long registration recovers when links return. Failures found here change the design before any production traffic moves. The output is a signed test report that lists each scenario, the observed result, and the fix applied, which the client can retain for its audit file.
Port numbers in order and prove a pilot site
Numbers are ported in the sequence agreed in the inventory, starting with a low-risk pilot branch whose users and call flows are well understood. Porting requests are submitted by the client, with DeployOpen preparing the account details, service addresses and carrier forms, and the team confirms each port date with the carrier before cutover. The pilot runs a defined period of live traffic with the client's staff reporting problems, and the cutover of later sites waits until the pilot passes its agreed acceptance checks. The output is a porting log and a pilot acceptance record.
Cut over branches in phases with rollback
Remaining branches move in groups the client approves, each with a published change window, a cutover checklist, and a named rollback owner. Before each change, the legacy routing is preserved so that the previous configuration can be restored if inbound calls, 911 tests, or trunk registration fail. After each cutover, the team runs the site's 911 test script and verifies inbound, outbound and internal calls against the test plan. A site is closed only when its checklist is signed. The output is a cutover record per site with the test results and the rollback status.
Decommission legacy PBXs and capture evidence
Once every site has run stable on the central platform for the agreed period, legacy PBXs are powered down, their trunks are cancelled with carriers, and their configurations are exported and retained according to the client's records policy. Call detail records, recording settings, and access logs are checked against the retention rules that apply to the client's sector. The final package contains the inventory, dial plan, 911 designs and test results, survivability report, porting log, cutover records and decommissioning certificates. Compliance teams can use this package as evidence, though auditors and certification bodies, not DeployOpen, decide whether it meets a given requirement.
Evidence to keep for 911, porting and audit reviews
This table lists the records a multi-site Asterisk or FreePBX rollout should keep, which component usually produces each one, and what the owner should confirm. Use it to set up evidence collection before cutover, not after a review starts. Regulators and auditors decide what is sufficient, so confirm retention periods and formats with counsel or your assessor.
| Evidence item | Produced by | What to keep and confirm |
|---|---|---|
| Dial plan documentation | Version control and change records | Versioned dial plan per site and central context, with approval records for each release. Confirm who signs off on changes. |
| Per-site 911 location records | FreePBX or Asterisk configuration plus the emergency location provider | Registered dispatchable location for each phone or site, with dates of update. Confirm the format your 911 provider and counsel expect. |
| Test call logs | Asterisk logs, CDRs and the test record kept by the implementer | Dated results of 911 and emergency routing tests per site, including failover tests when the WAN drops. Confirm required test frequency. |
| Number porting order and carrier confirmations | Ticketing system and carrier correspondence | Porting sequence, firm order and loss dates, and carrier confirmations for each number block. Keep the cutover sequence tied to these records. |
| CDR and access logs | Asterisk CDR module, FreePBX admin audit trail and host logs | Call detail records and administrator access logs retained centrally with time sync. Confirm retention periods with counsel and your auditor. |
| Change records for trunks and routing | Ticketing system and the asset register | Each trunk, DID and routing change with requester, approver, timestamp and rollback plan. Link changes to phased cutover waves. |
| Site and device inventory | Asset register or CMDB | Phones, gateways and sites with owner, location and status, reconciled against trunk and extension lists before each wave. |
What buyers ask before consolidating branch PBXs
How much does consolidating branch PBXs onto open-source telephony cost?
The total depends on the number of sites, users, trunks and numbers, and on how much work the existing estate needs. Cost falls into a few groups: the servers or cloud hosting that run Asterisk and FreePBX, SIP trunks and phone numbers billed by a carrier, handsets or softphone licenses, and labor for design, porting, cutover and testing. Hosting and trunks recur monthly, while design, build and cutover are one-time. Software is typically license-free, but commercial modules and vendor support are separate line items to confirm. Ask any partner for a quote that lists each component, who pays for it, and which items recur. DeployOpen does not publish prices; a quote follows from a written scope.
How long does a multi-site phone consolidation take?
The pace is set mainly by site count, number porting lead times and carrier changes, not by building the Asterisk servers. Each site's numbers must be ported or kept on a schedule the carrier confirms, and a porting request can stall on address mismatches or account details. Trunk migrations, new 911 location records and handset provisioning add their own dependencies. Ask the carrier for current porting lead times in writing, group sites into waves, and confirm which waves depend on carrier work. A fixed-scope plan should state the phases and the dependencies that could move dates.
What information must our team provide before a consolidation starts?
The most important inputs are a site inventory, carrier contacts and account authority, and validated 911 address data for each site. The inventory should list every PBX, extension, analog line, fax, elevator or alarm circuit, paging device and call flow that exists today. Carrier contacts must be able to approve porting and trunk changes. Named decision makers need to approve the dial plan, the cutover windows and the rollback criteria. Missing address data or unknown call flows are common causes of delay, so collect them before scoping.
Can our internal IT staff run a multi-site PBX consolidation alone?
Some organizations can, provided they have people with working experience in SIP trunking, Asterisk or FreePBX configuration, carrier porting and emergency calling rules. The work includes dial plan design, survivability design, 911 configuration and testing, and a phased cutover with rollback. Teams without that experience often underestimate porting and testing. A common middle path is to have an implementation partner design and test the core while internal staff run day-to-day operations. Whichever path is chosen, the scope document should name who does each task and who signs off.
What happens to call data, recordings and voicemail during consolidation?
Call detail records, recordings and voicemail stay in the infrastructure you provide, because a self-hosted Asterisk or FreePBX system stores them on your servers or storage. The consolidation plan should state where each data type is stored during and after cutover, who can access it, and how long it is kept. If you carry records under a regulation, such as broker-dealer or healthcare retention rules, confirm the required retention periods with your compliance lead before migration. Archive or export existing branch records before decommissioning old PBXs so history is not lost.
How does rollback work if a site cutover fails?
Each site cutover should have written rollback criteria and a tested path back to the previous system. Typical steps include keeping the legacy PBX powered and its trunks connected until the new site is stable, redirecting DID numbers back to the old trunk, and restoring the previous dial plan from a saved configuration. Rollback must be rehearsed in a lab or pilot site, and the time it takes depends on carrier routing changes that may not reverse instantly. Ask the partner to document the decision point, the person authorized to call rollback and the verification steps after each wave.
How does 911 location get handled per site after consolidation?
Each site needs its own validated dispatchable location, and the central Asterisk system must send the correct location with every emergency call from that site. Emergency calls must route to the proper public safety answering point, and the design must work even if the WAN fails. Confirm current requirements for multi-line telephone systems with counsel and the local authority, and test calls from each site before cutover. Document the test results and location records as part of the rollout evidence.
What keeps branches working when the WAN link fails?
Survivability depends on whether branch phones can still register and place calls when the link to the central server is down. Common approaches include local survivable gateways, a branch-local Asterisk fallback, or carrier-side failover to a secondary route. Each option has trade-offs in cost, features and maintenance. Ask the partner to show which features work during an outage, how calls to 911 behave, and how the branch recovers when the link returns. Test the failover path under real conditions before cutover.
Questions to ask an implementation partner before signing
Start with the dial plan, because every other answer depends on it. Ask the partner how they will design one dial plan across all sites: which contexts map to each branch, how extension ranges and internal dialing work between sites, how outbound routes choose a trunk and fail over, and where the design keeps local emergency and local calling behavior when a site loses its central link. Ask them to show a sample extensions.conf structure or equivalent, how they will test inbound and outbound routes for every site before cutover, and who signs off the numbering plan. A partner who cannot explain how a call from Branch B reaches a number in Branch A without hair-pinning through a failed WAN has not designed a multi-site system yet.
Next, ask how survivability is tested rather than assumed. The test they should run is a WAN cut at each branch during a pilot, with the expected result written down before the test starts. Ask which components keep service alive during the outage (local gateways, survivable registration, local trunks or a secondary carrier path), what happens to inbound numbers during the outage, and whether the test covers the phones, the softphones on the branch network and the voicemail and recording functions. Ask for the test plan and the acceptance criteria, and whether they will rerun the test after each change to routing or firmware. Number porting follows the same logic: ask for their porting order, the losing carrier's requirements, how they schedule ports per site so that a failed port does not take down a whole branch, and which numbers they will keep on the old system until the new route is proven.
Finally, confirm the operational commitments in writing. Ask how they document 911 location per site and test it, including the registered address for each phone, the rules for moving desk phones or softphones between locations, and the evidence they will hand over. Ask how they plan Asterisk and FreePBX upgrades against the vendor lifecycle, which versions they will deploy, how they test dial plan changes before each upgrade, and what they commit to for security patches. Ask what monitoring they install and hand over (trunk and registration status, call quality, certificate expiry, disk and database health), who receives the alerts and who owns them after go-live, and how after-hours support works, including response expectations, escalation to carriers, and whether those are contractual. Request a fixed scope with written deliverables, milestones and acceptance tests before any work starts, and confirm which items are one-time and which are covered by a support retainer.
How deployment location changes the consolidation design
Running the central Asterisk platform in your own data center gives you direct control over the hardware, the network edge and the physical path to each branch. Most consolidations here keep the primary call control in one facility and use a second site or a secondary node for failover, so the design depends on how many carriers you can reach and how diverse your WAN paths are.
- Trunk connectivity: Confirm which SIP trunk providers can terminate at each facility and whether you can hold two separate carrier circuits with different physical routes.
- Failover paths: Define how branch phones re-register to a second call server or a local survivable gateway when the WAN link to the data center fails.
- Log retention: Set call detail record and SIP trace retention in your own storage, and align it with your records policy and any 911 test evidence you must keep.
- Patching: Schedule Asterisk and FreePBX maintenance windows around your change board, and test dial plans on a staging system before each release.
Before you commit, ask your partner to document the trunk diversity, the failover behavior during a WAN outage and the retention settings in writing.
A private cloud deployment runs Asterisk inside accounts you control, such as a virtual network in a public cloud provider or a private cloud platform in your own tenancy. The server is elastic and easier to replicate across regions, but the trunk and branch paths now cross a virtual network edge, so routing, public addressing and firewall rules need the same care as on premises.
- Trunk connectivity: Check whether the provider's network allows static public addresses and whether your SIP carriers accept traffic from those addresses.
- Failover paths: Plan for a second instance in another availability zone or region, and test how branch devices and softphones move between them.
- Log retention: Confirm that call logs and SIP traces land in storage you own, with access logging and retention enforced through your own accounts rather than defaults.
- Patching: Keep images and packages under your change control, and rebuild instances from tested templates instead of patching live servers.
Ask the partner which parts of the stack are managed by the cloud provider, which you manage, and how a failed instance is restored during a regional incident.
Air-gapped and restricted networks limit or remove internet access, so the PBX cannot rely on cloud carriers or external update services in the normal way. Trunks usually terminate on a session border controller or a gateway at the edge, connected to a carrier or a government network, and every software update has to be staged and verified inside the enclave.
- Trunk connectivity: Identify the approved carrier or private interconnect, and confirm how numbers, emergency routing and any gateway hardware are supplied and supported inside the restricted zone.
- Failover paths: Keep survivable call control local to each site, since a central failure may not be reachable from a restricted branch at all.
- Log retention: Store logs and records on enclave media with controlled export, and document how evidence is moved out for audit without weakening isolation.
- Patching: Build an offline repository of packages, container images and dial plan backups, then verify and sign each release before it enters the network.
Confirm with your security authority and your telephony carrier how emergency calls and location data are routed from the enclave, because those requirements can differ from a standard office design.
How DeployOpen scopes and builds a multi-site PBX consolidation
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens and supports self-hosted open-source platforms inside the client's own infrastructure. For a multi-site PBX consolidation, that means the central Asterisk and FreePBX servers, the branch connections, the SIP trunks and the monitoring run in your cloud accounts, data centers or private networks, not in a vendor's hosted tenancy. Most engagements are fixed-scope. Before any configuration work starts, the site list, dial plan scope, cutover waves, 911 test plan and acceptance criteria are written down, and the deliverables and timelines are agreed in that document. Ask any partner to show you the written scope for a comparable multi-site project before you sign, and check that it names which sites are in each wave and who approves each cutover.
DeployOpen also prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. For telephony, that evidence usually includes dial plan documentation, 911 location records per site, call detail retention settings, access control configuration and test results from each cutover wave. Independent auditors and certification bodies decide whether that evidence meets a given requirement. Confirm with your own assessor, before design starts, which records they will ask for and in what format, so the partner builds them into the project rather than reconstructing them afterward.
Ongoing work after cutover is available as a retainer for support, upgrades and continuous testing, and it is priced separately from the build. Ask for a quote that separates one-time implementation effort from recurring support, and confirm the response expectations in writing, since DeployOpen does not publish a price list and any service levels must come from the signed scope. Also confirm who owns the Asterisk release lifecycle decision, because a multi-site estate that moves to a new major release mid-consolidation doubles the regression testing you will pay for.
