Migrating from on-prem PBX to cloud dialer without downtime

If your contact centre still runs on an on-prem PBX (Avaya, Cisco, Asterisk-on-a-box, Mitel), you have probably been told you should move to cloud. The pitch is real — operational savings, no hardware refresh cycle, faster feature delivery — but the migration is where teams get burned.

Most failed PBX migrations have the same shape: the team picks a cutover date, schedules a weekend, swaps all 50 agents at once, discovers seventeen edge cases by Monday morning, and rolls back. Three months later they try again.

The actual playbook is incremental. This post walks through it.

Pre-migration audit

Before picking a cloud dialer, document what your current PBX actually does. This sounds obvious but most teams skip it and discover three weeks in that some agent has a custom shortcut on extension 42 that nobody told them about.

Inventory:

• Number of DIDs / extensions / external lines
• Active campaigns + their dialing modes
• IVR flows (every menu, every condition)
• Call recording configuration
• CRM / ticketing integrations (HubSpot click-to-dial, Zoho contact lookup, etc.)
• Hardware (IP phones, headsets, gateway devices)
• Custom dialplans (Asterisk-specific) / custom scripts (AGI / ARI)
• Reports + dashboards used by operations
• Compliance configurations (NDNC scrub, DLT linkage, recording disclosures)
• Disaster recovery setup
• Failover phone numbers (the "if the main DID dies" backup)

This list always grows during the audit. Plan for it.

Carrier / SIP trunk situation

• Who is the current trunk provider? (Vilpower, Tata Tele, Airtel Business, etc.)
• Is the trunk contract month-to-month or annual?
• What is the termination notice period?
• Are the DIDs portable? (almost always yes in India under MNP for mobiles; DID portability for landline-range numbers is operator-specific)

If your trunk is on a 2-year annual contract that runs another 8 months, factor that into the cost analysis.

The phased rollout plan

The pattern that works:

Phase 0 — Decision + procurement (week 0)

• Sign with the new dialer vendor
• Provision a test environment
• Set up the parallel SIP trunk (you will run both PBX + cloud dialer side-by-side for several weeks)
• DLT re-registration if the new dialer uses a different PE

Phase 1 — Parallel pilot, 1 team (weeks 1-2)

• Move 1 campaign / 1 team (~5 agents) to the new dialer
• Use 1-2 fresh DIDs (do not port existing DIDs yet)
• Run for 2 weeks
• Compare connect rate, AHT, abandon rate against the same team's prior numbers on the old PBX
• Capture edge cases: integration gaps, agent UX complaints, missing reports

Phase 2 — Expand, port some DIDs (weeks 3-5)

• Move 2-3 more teams to the new dialer
• Port the first batch of DIDs from old PBX to new (~10-15 numbers). MNP / DID porting takes 7-14 days in India; submit early in this phase
• Validate inbound calls land correctly on the new system
• Confirm CRM integrations work end-to-end (click-to-dial, screen pop, post-call log)

Phase 3 — Full agent migration (weeks 5-8)

• Move all remaining agents
• Port remaining DIDs in batches of 5-10
• Maintain old PBX in standby mode (no active campaigns, but reachable for any DIDs not yet ported)
• Validate every IVR flow on the new platform

Phase 4 — Cutover + decommission (weeks 8-10)

• All DIDs ported
• Old PBX taken offline (but server / backups retained for 30 days)
• Final invoice from old vendor
• Hardware audit (return / repurpose IP phones)
• Documentation update

Total: 8-10 weeks. Faster is possible if you take more risk; slower is normal if you have unusual integrations.

Number porting (the long pole)

In India, DID porting workflow:

1. Notice to current carrier: 7 days minimum
2. Authorisation letter to receiving carrier: includes GSTIN, PE number, list of DIDs to port
3. TRAI/operator processing: 5-14 working days
4. Cutover window: usually a 4-hour window scheduled with both carriers; during this window calls may be flaky

Plan for 3 weeks per batch of DIDs. Do not start porting in Phase 4 — start in Phase 2 to allow buffer.

Some DIDs are not portable (operator-locked ranges). Identify these in the audit; for those, you keep the old trunk running or get new numbers on the cloud dialer.

CRM + integration migration

Most enterprise PBX setups have CRM integrations built up over years. Common gotchas:

• Click-to-dial buttons in the CRM are usually configured per-PBX. Re-configure on the new dialer. Most cloud dialers (dialque included) provide SoftPhone browser extensions for major CRMs.
• Screen pop on inbound (looks up the caller in the CRM and shows their record): re-configure
• Call disposition mapping: ensure the new dialer's call outcomes map to your CRM's existing fields (Disposition, Outcome, Notes)
• Recording links: if recordings are linked from the CRM to the old PBX URL, those links will break. New recordings get new URLs; old recordings stay accessible via the old PBX as long as you keep the storage

Plan to spend 10-20 hours of integration engineering during Phase 1-2.

Agent training

The biggest soft-cost in a migration. Agents have muscle memory for the old softphone, the keyboard shortcuts, the way reports are pulled. They need 2-3 weeks of dual-running to internalise the new system.

What works:

• Train trainers first — 1-2 senior agents become power users on the new dialer
• Side-by-side training sessions — 2-hour blocks, 5-6 agents at a time, showing the new dialer doing exactly what the old one did
• Quick-reference cards — laminated card next to each agent's monitor showing keyboard shortcuts + common workflows
• 15-minute daily standup during Phase 1-2 to surface complaints

Skip these and Phase 1 will run 2 weeks longer with higher complaint volume.

DLT / NDNC re-registration

If the new dialer uses its own PE registration (rather than yours), you need to re-register templates, headers, and consent. Plan 2 weeks for this.

If the new dialer (dialque does this) ties to your existing PE, this step is mostly a one-day reconfiguration.

The cutover day playbook

Even with phased rollout, there is a final cutover day when the old PBX goes offline. Plan it:

• Wednesday or Thursday morning (avoid weekends — vendor support is harder to reach)
• 0800-1100 IST window — outside peak call volume
• Two engineers + one ops manager in a war room
• Pre-flight check the day before: every DID in the new dialer rings correctly, every campaign starts correctly, every report runs
• Rollback plan ready: if cutover fails, the old PBX can come back up within 2 hours
• Post-cutover monitoring: extra eyes on connect rate, abandon rate, agent error logs for the first 4 hours
• 30-day standby: old PBX hardware + storage kept available; recording archive accessible

Data migration

Most migrations skip data migration and just keep the old recordings on the old infrastructure (read-only). This is the simpler approach.

If you do want to migrate recordings + call logs:

• Export from old PBX as standard formats (WAV / MP3 for audio, CSV / JSON for logs)
• Bulk-load into the new dialer's recording store
• Update CRM record links to point to new URLs (this is the painful part)
• Test sampling: random sample of 50 recordings, verify playback + metadata

Volume: a 50-agent shop accumulates ~500GB of recordings per year. Plan for transfer time + S3 PUT costs.

Common mistakes

• Underestimating porting timelines — porting always takes longer than the carrier quote
• Forgetting custom dialplans — that Asterisk dialplan rule from 2018 that routes calls from a specific area code to a specific team is in version control nowhere, only in the live system
• Big-bang cutover — moving all 50 agents in one weekend; one bug brings down all 50 simultaneously
• No rollback plan — assuming the new dialer will work perfectly on day 1
• Skipping the audit — discovering on day 47 that the old PBX has a custom integration with the warehouse system

Frequently asked questions

Can I do this in less than 8 weeks?

If the existing setup is simple (single campaign, no custom integrations), 4 weeks is feasible. Above ~30 agents or any custom integration, plan for 8-10 weeks.

Do I lose recordings during migration?

No. Old recordings stay accessible via the old PBX as long as you keep its storage. New recordings live in the new system. CRM links to old recordings keep working.

What if my carrier won't release DIDs?

Document the trunk contract notice period. If they are blocking porting beyond the contractual timeline, file a TRAI complaint — operators are required by regulation to honour porting requests.

How much agent productivity is lost during migration?

Expect 10-20% productivity drop in Phase 1-2 (the dual-running weeks), normalising by Phase 4. The total cost is real but small relative to the long-term operational savings.

Should I migrate before or after a heavy season?

After. Never migrate two weeks before Diwali / quarter-end / your peak campaign. Run the migration in your quietest month.

PBX migration is operations work, not a software upgrade. The teams that succeed treat it like a 2-month project with weekly milestones, not like a weekend deploy. Phase it, port DIDs early, train trainers first, keep the old system in standby for 30 days after cutover, and you will land at the new platform without losing a day of revenue.