IMPLEMENTATION
From pilot to production, without a big-bang cutover.
Regulators set the dates; your engineers set the pace. Bulwark goes in beside what you run today, takes over the communications that carry compliance risk first, then migrates site by site — with a way back at every step.
0 · Pilot
1 · Parallel run
2 · Site waves
3 · Integrate
4 · Harden & scale
Day 1Month 1Month 2Month 3+
✓ Compliance controls live from Phase 1 — audit trail, retention, encrypted media, alerting with roll-call.
Compliance value lands in Phase 1, not at the end
The controls an auditor asks about don't depend on how many phones you've moved. They're on from the first node.
Evidence from week oneTamper-evident audit, retention you set and encrypted media start with the first node, for the communications that matter most.
Risk moves first, not phonesEmergency alerts, security and operations voice, and duty-room hotlines move before anyone's desk phone does.
No cliff edgeYour current PBX keeps running until each site signs off. Nothing is switched off on a single night.
Five phases, and what your engineers do in each
Durations are indicative; they depend on how many sites, users and integrations you have.
0
Pilot
1 dayOne node on an isolated network segment, with zero access to production. The goal is a single proof: calls and alerts keep working with the internet unplugged.
Your engineers
- Boot the appliance ISO, or run the one-file signed installer on a Debian server
- Answer the guided setup wizard: two administrators, two-factor, hostname, start a new cluster
- Register a few test phones and the browser softphone
- Pull the uplink, place calls, and fire a test alert
Done when
Calls and alerts work offline, in front of your team.If it goes wrong
Wipe the node. Nothing in production was touched.1
Parallel run — critical comms first
Weeks 1–4Compliance controls liveBulwark runs beside your current PBX and takes the communications that carry the most risk: emergency alerts and muster, security and operations voice, duty-room hotlines and the incident bridge.
Your engineers
- Create extensions and groups for the critical teams
- Draw geofences for buildings, wards, blocks or plants
- Set recording and retention to your regulator's windows
- Link Bulwark and your current PBX with a SIP trunk or a Cisco/generic gateway preset so they can call each other
- Run the first drill
Done when
A drill completes with a roll-call report, and the audit trail, retention and encryption are live.If it goes wrong
Your current PBX is untouched; everyday calling never moved.2
Site-by-site migration
Weeks 4–12, in wavesEveryday calling moves one site at a time. Each wave is small enough to roll back and big enough to learn from.
Your engineers
- Provision phones from the console with zero-touch templates
- Connect trunks: SIP, PRI gateways, FXO/FXS
- Rebuild hunt groups, ACD queues, IVR and voicemail
- Cut numbers over one site at a time
- Watch call and queue dashboards in Grafana
Done when
The site signs off after a clean week of traffic.If it goes wrong
Routes revert to the old PBX, which stays live until sign-off.3
Integrate
Alongside phase 2Connect Bulwark to the systems around it, each on its own least-privilege credential.
Your engineers
- Issue scoped API clients with auto-rotating tokens
- Wire SIEM to the IP firewall, and HR to provisioning
- Add CRM screen-pop, helpdesk tickets and Power BI reports
Done when
Every integration runs on its own scoped credential, with each write in the audit log.If it goes wrong
Disable one client; nothing else is affected.4
Harden & scale
OngoingGrow to an active-active cluster across sites, and produce the DR and audit evidence your regulator asks for.
Your engineers
- Join nodes 2–4 with a one-time cluster key; all run active-active
- Put a node at the DR site
- Run the STIG-aligned hardening script; enable full-disk encryption and FIPS mode where required
- Run the DR drill your regulator expects, such as RBI's six-monthly drill
Done when
You hold drill evidence and audit exports for the next inspection.If it goes wrong
Remove a node; the others keep serving calls.What it's like for your engineers
One signed artifact, a guided wizard, and updates that roll themselves back if anything fails.
$ gpg --verify voiphorizon-1.0.run.sig
Good signature from "VOIP Horizon release"
$ sudo ./voiphorizon-1.0-linux-amd64.run
Installing bundled engines
✓ FreeSWITCH, Kamailio, rtpengine
✓ PostgreSQL, Redis, ejabberd
Setup wizard
Administrators 2 created
Two-factor on
Cluster start new
Recovery kit shown once — store it
Admin console: https://pbx.local:8443
Install offline from one file. Nothing is downloaded at your site; the bundle carries every engine.
$ sudo voiphorizon-update ./update-1.1.run
Installed 1.0 → target 1.1
✓ Backup taken
✓ Staged and checksummed
✓ Binaries swapped atomically
✓ Database migrated forward
✓ Health check passed
# on any failure: automatic rollback
# offline sites: carry in signed media
Update by applying the package on top. It knows the installed version, backs up first, and rolls back on failure.
Cluster · join node-02
one-time cluster key accepted
✓ Identity issued to node-02
✓ Config replicated
✓ Capacity envelope checked
node-01 active
node-02 active DR site
Weaker node? Needs explicit accept.
# 4-node cap per cluster
Scale by joining nodes. Every node serves calls; the system warns before you overload the weakest one.
One service per module
Each module runs as its own service — restart presence or provisioning without dropping calls in progress.
Honest capacity
The console works out a safe envelope from your hardware and warns before you exceed it.
Break-glass recovery
A recovery kit from install day, and an offline admin-recovery path for the server owner.
Everything has an API
What you can do in the console, scripts can do with scoped, audited credentials.
Who does what
A typical split. We adjust it to how much your team wants to own.
| Phase | VoipHorizon | Your team |
|---|---|---|
| 0 · Pilot | Brings the signed image, stands up the node, runs the offline proof with you | An isolated network segment, a few test phones, the decision-makers in the room |
| 1 · Parallel run | Interop with your current PBX, alert and muster design, first drill | Critical-team lists, building and zone maps, retention requirements from compliance |
| 2 · Site waves | Migration runbooks for Cisco, Avaya and 3CX estates; dial plans, queues and IVR | Numbering and trunk contracts, cutover windows, site sign-off |
| 3 · Integrate | API guidance and recipes; build alongside you if needed | Owners of CRM, SIEM, HR and helpdesk systems |
| 4 · Harden & scale | Cluster design, hardening baseline, DR drill plan | DR site, change control, regulator reporting |
Start with one day and one isolated segment
We prove offline survival in front of your team, then plan the waves around your deadlines.