The case for hosted dialler SaaS — 8x8, GoToConnect, RingCentral — is convenience. The case against, after eighteen months of use at any meaningful scale, is the invoice. UK contact centres running 10+ outbound agents on those platforms are typically paying £80–150 per agent per month before minutes, and that is before the integration tax of trying to make a hosted dialler talk to anything outside its own ecosystem.
Self-hosted or managed ViciDial collapses that line item to between a quarter and a fifth of the cost — for a stack with materially more flexibility — and Telebyte has run the migration enough times that the playbook is well-defined. This article documents what is actually involved, where the project genuinely is risky, and where the perceived risks turn out to be mythical.
The cost picture
Numbers vary by deployment, but a fair like-for-like for a UK 25-agent outbound floor looks like this:
| Cost line | Hosted SaaS (8x8 / GoToConnect / RingCentral) | Self-hosted ViciDial | Managed ViciDial | |---|---|---|---| | Platform licence | £80–150 / agent / month | £0 (open source) | £1,200/mo flat for ~25 agents | | Server / infrastructure | included | £80–150/mo VPS | included in managed | | SIP trunk minutes | bundled, ~£0.012/min | direct from provider, ~£0.004/min | direct, pass-through | | Recording storage | bundled, capped | £25/mo object storage | included to a cap | | Annual platform spend (25 agents) | £24,000–45,000 | £960–1,800 (infra only) | £10,200 | | Plus minutes | substantial | substantially lower | substantially lower |
The platform-licence delta dominates the calculation. For a 25-agent outbound floor running typical UK volumes, migrating from hosted SaaS to managed ViciDial saves between £14,000 and £35,000 per year of operating cost, depending on which hosted platform is being left and what minute volumes are involved. Self-hosting saves more again, at the cost of needing in-house Linux capability.
These numbers are not edge cases. They are the steady-state cost picture every Telebyte migration project produces.
What actually has to migrate
A hosted-to-self-hosted dialler migration is more than swapping the platform. The migration touches:
- Phone numbers — the inbound and outbound DDIs the operation uses today. These belong to the operator, not to the SaaS vendor; they can and should be ported.
- Agent licences and accounts — typically rebuilt fresh on the new platform; the old agent IDs do not survive the migration.
- Call recordings — the historical archive on the SaaS platform needs to be downloaded and migrated to the new recording store, or formally archived to compliant cold storage with a retrieval procedure.
- CRM integration — every integration between the dialler and the operation's CRM has to be reworked against the new platform's API or the new platform's direct database access.
- Reports and dashboards — any custom reporting on the hosted platform has to be rebuilt on the new dialler's schema.
- Disposition codes and campaign configuration — typically mappable cleanly but worth auditing during the project rather than after.
- Agent training — the new agent UI is different; expect a week of acclimatisation.
The migration plan needs to address every one of those. A migration that ignores one of them is the migration that produces an unhappy launch.
The realistic timeline
A well-run hosted-to-ViciDial migration runs over four to eight weeks of preparation followed by a single migration weekend. The phases:
Weeks 1–2: discovery and design. Map the current hosted setup — campaigns, dispositions, lists, recording archive, integrations, reports. Define the target ViciDial configuration in writing. Confirm the new SIP carrier, agree the porting plan with the carrier and the losing SaaS vendor, agree the recording-archive disposition.
Weeks 3–4: build and dual-run. Stand up the ViciDial environment. Configure campaigns, dispositions, lists. Build the CRM integration against the new platform. Pilot with two to five real agents handling a low-volume campaign while the main operation continues on the SaaS platform.
Weeks 5–6: cutover preparation. Train agents on the new UI. Migrate or freeze the call-recording archive. Schedule the number-porting date. Communicate the cutover to all stakeholders.
Migration weekend. Numbers port (typically Friday afternoon for a Monday morning go-live). The main operation moves to ViciDial. The old hosted account moves to read-only.
Week 7–8: stabilise. Run both platforms in parallel for two weeks (the SaaS account read-only, for historical record retrieval). Resolve any post-migration issues. Cancel the SaaS account.
For a 25-agent operation, Telebyte's typical migration runs eight calendar weeks end-to-end and the cutover weekend produces zero production downtime, by design.
Where the project actually carries risk
Most of the risk in a hosted-to-self-hosted dialler migration is concentrated in two places. Everything else is process, and process is well-understood.
Risk one: number porting
UK number porting is governed by Ofcom and standardised, but the losing party (the SaaS vendor) has every commercial reason to slow the process down. Telebyte has seen porting delays of two to six weeks because the losing carrier has dragged its feet on accepting the port-out request.
The mitigations:
- Submit the port request as early as possible. Once the new SIP carrier is chosen and the agreement is signed, submit the porting request. Eight weeks of lead time is comfortable; four weeks is tight; less than two weeks is risky.
- Keep the old hosted account active until porting completes. The temptation to cancel early to stop the meter is real and should be resisted. A premature cancellation that races a slow port produces a black hole where neither carrier owns the number.
- Have a fallback CLI strategy. Even on the worst porting timelines, the new ViciDial install can present any CLI the SIP carrier accepts. The inbound numbers may take longer; the outbound CLI flexibility is immediate.
Risk two: the call-recording archive
The historical recording archive on the SaaS platform is the operator's data, but the SaaS platform's export tooling is rarely designed to make a bulk export easy. The patterns Telebyte has used to handle this:
- Bulk download via the SaaS platform's API, where one exists. Most platforms have one, but the rate limits and the download formats vary widely. Expect to budget a week of engineering time for the export script alone.
- Compliance-driven archival. If the operator's retention policy is "keep recordings for seven years", the SaaS recordings can be cold-storage archived on the SaaS platform itself (if the licence terms allow) or downloaded once and stored in encrypted S3-compatible object storage. They do not need to live on the new ViciDial system.
- Selective migration. If only some recordings are needed live on the new platform — typically the most recent twelve months — the migration scope can be reduced.
The decision about what to do with the archive is the single most important compliance decision in the project and the place where most migrations go off-piste. It is worth thirty hours of compliance team attention up front.
What does not break
A short list of perceived risks that turn out, in Telebyte's experience, to be non-issues:
- Call quality. A properly-configured ViciDial installation with a credible UK SIP carrier produces call quality indistinguishable from the SaaS platforms. The "but the hosted vendor has better infrastructure" argument does not survive contact with reality.
- Reliability. A well-provisioned single ViciDial box hits four nines of availability without effort. Multi-box deployments hit five nines. The hosted SaaS platforms are good but not magical.
- Compliance. Self-hosted ViciDial gives the operator more compliance control, not less. The recording retention, encryption, indexing, and access posture are all under operator control rather than at the mercy of a vendor's product roadmap.
- Agent productivity. The ViciDial agent UI is less polished than the hosted SaaS UIs, but after a week of acclimatisation, agent dial-per-hour rates either match the previous platform or, more commonly, exceed it because the dialler controls are tighter.
The thing that does take adjustment is the operator's relationship with the dialler. On hosted SaaS, the operator opens a ticket and waits for the vendor; on self-hosted or managed ViciDial, the operator either fixes it themselves or escalates to a managed-services partner. That is a different operational posture and worth thinking about explicitly.
When to managed-host rather than self-host
For operations that have decided to leave hosted SaaS but lack in-house Linux capability, the right destination is usually not "build it ourselves" but "buy it from someone who manages a ViciDial install for a living". Telebyte's Managed Dialler tier exists for that case. The economics are still materially better than the hosted SaaS pricing (typically a third to a half of the hosted SaaS cost), the operational simplicity is preserved, and the operator gets the ViciDial feature set without owning the Linux box.
For operations that already have a Linux engineer and want full operational control, self-hosting is straightforward and dominates the cost calculation. The earlier article on hosting ViciDial on Contabo is the working playbook for that path.
The migration day-zero checklist
Before signing off any hosted-to-ViciDial migration, Telebyte's standard checklist:
- New ViciDial environment installed, hardened, monitored, backed up
- New SIP carrier contract signed, trunks configured and tested
- Inbound numbers ported, callable
- Outbound CLI configured and tested with the carrier
- Agent training delivered, two-day shadow rota planned
- Recording archive disposition agreed and executed
- CRM integration tested end-to-end on the new platform
- Compliance policy updated to reference the new platform
- Old hosted account moved to read-only, cancellation date in the calendar
- 14-day post-migration support arrangement in place
If any of those boxes are unticked, the migration is not ready. The temptation to cut over with an ungoverned check missing is the temptation to spend the following month firefighting.
A worked-example timeline
For an operator considering whether to migrate, a fair indicative timeline assuming the operator agrees to engage a managed partner:
- Day 0 — initial conversation; rough scope agreed.
- Day 7 — quotation issued; SIP carrier shortlisted.
- Day 14 — contracts signed; porting request submitted.
- Day 21 — new ViciDial environment provisioned and configured.
- Day 35 — pilot agents live on a low-volume campaign.
- Day 49 — agent training complete; recording-archive plan executed.
- Day 56 — main cutover weekend; all production traffic on ViciDial Monday morning.
- Day 70 — old hosted account cancelled; stabilisation complete.
Ten weeks from "should we migrate?" to "we have migrated", with the operation never offline for more than a normal Sunday-night maintenance window.
Most operations that have stayed on hosted SaaS for three or more years discover, in retrospect, that the only reason they stayed was inertia. The cost-of-staying numbers do not survive a careful look.
Post-migration KPIs that prove it worked
A successful migration produces measurable improvements within thirty days. The metrics worth tracking against the pre-migration baseline:
- Dials per agent per hour. A well-tuned ViciDial campaign typically increases this by 10–25 per cent versus the hosted SaaS baseline, because the predictive engine on ViciDial has more knobs than most hosted platforms expose. Agents get more connected calls in the same shift.
- Drop ratio. Ofcom guidance puts the abandoned-call ceiling at three per cent. ViciDial's drop-ratio controls are fine-grained; well-configured campaigns sit at one to two per cent, comfortably inside the ceiling and well below where hosted SaaS platforms often default.
- Cost per connected call. The denominator here is the all-in cost — platform plus minutes plus infrastructure. A successful migration produces a 50 to 70 per cent reduction within the first quarter.
- Time from agent login to first call. A measure of campaign-readiness and the hopper-feeder pipeline. Anything above ninety seconds at peak indicates a configuration problem worth fixing.
- Recording retrieval time. With the indexing posture in the FCA call-recording checklist in place, retrieving any specific call from the last seven years should take seconds, not minutes. If it takes minutes, the indexing is wrong.
- Agent satisfaction. Less easy to measure but worth asking. Post-migration surveys consistently surface "the interface looks dated but the controls work better" within four weeks of cutover. That is the expected pattern.
A migration that does not produce material movement on those metrics within sixty days needs a configuration review. The platform is working; the campaign tuning probably is not.
Considering a migration off hosted dialler SaaS? Tell Telebyte what you're running today — Telebyte produces a no-pitch like-for-like cost analysis as part of every initial conversation.