You do not remove Asterisk or FreeSWITCH to adopt ClutchCall. The two systems speak plain SIP and RTP to each other. Thus your existing PBX becomes an ordinary SIP peer — a trunk — of your workspace. From there, you migrate the way every safe telephony cutover works. You run both systems side by side. You move one route at a time. You keep a rollback that is a single DNS or dialplan change.
There is no automated Asterisk/FreeSWITCH import. ClutchCall does not read your sip.conf/pjsip.conf, extensions.conf, or FreeSWITCH XML dialplans. It does not translate them for you. The migration is a manual, phased re-pointing of trunks and numbers. You also rebuild your call flows as workspace IVR/ACD programs and AI agents. This page describes that phased approach. What works today is SIP interop. The “one-click migrator” is not a product.

​
What actually works today

SIP peering — shipped

Point Asterisk/FreeSWITCH at your workspace’s SIP endpoint (or the reverse). Calls flow in both directions over standard SIP + G.711 RTP. This is a supported, live capability.

Phased cutover — the method

Bridge the two systems. Move numbers and outbound routes step by step. Decommission the old boxes when traffic drains. There is no flag day.
ClutchCall’s gateway is a back-to-back user agent (B2BUA) with its own built-in registrar. Thus an Asterisk or FreeSWITCH box connects to it exactly like a carrier SBC would. You do not need a separate SIP registration or routing proxy in between. If you can peer two PBXes together with a SIP trunk, you can peer your existing deployment with a workspace.

​
The migration in one picture

1

Peer the two systems

Add ClutchCall as a SIP trunk on your Asterisk/FreeSWITCH box. Or add your box as a trunk in the workspace. Prove that a test call flows each way. Nothing in production changes yet.
2

Run side by side

Send a small slice of traffic into the workspace: one DID, one queue, or your internal test extensions. Everything else stays on the old system. Watch call quality, answer ratio, and MOS in the reports.
3

Move trunks and numbers

Re-point carrier trunks and DIDs onto the workspace, one route at a time. Each move is reversible on its own.
4

Rebuild flows natively

Recreate the dialplans, IVR menus, and queues that you still want. Build them as workspace IVR/ACD programs and AI agents. This is where the value is. It is manual, deliberate work, not an import.
5

Decommission

When the old boxes carry no production traffic, retire them.

​
Step 1 — Peer Asterisk / FreeSWITCH as a SIP trunk

You can peer in two directions. Most migrations use both, at different phases.
Configure ClutchCall as an outbound SIP trunk on your existing box. Then Asterisk/FreeSWITCH can give selected calls to the workspace. This lets you front an AI agent or a new IVR flow while your existing number plan stays in charge of routing.On the workspace side, create a trunk whose peer is your PBX’s signalling address. Set Realm = Internal (it is your own equipment, not a per-minute carrier). Follow SIP Trunking for the full field walkthrough. On the Asterisk/FreeSWITCH side, define a normal SIP/PJSIP trunk that points at your workspace’s SIP endpoint:
Offer G.711 (PCMU/PCMA) on the trunk. It is the universal phone codec. It needs no transcode on either side.
On this page, Asterisk and FreeSWITCH refer to the external systems that you migrate away from. ClutchCall is not built on either. Its gateway is an independent implementation. The dialplans, extensions.conf logic, and FreeSWITCH XML that you have today are configuration for those external products. They do not carry over. You rebuild the equivalent behaviour natively.

​
Step 2 — Run both systems side by side

You peer first so that you can validate ClutchCall with real traffic while your old deployment stays authoritative. Good first slices to move:
  • Internal test extensions. Dial from a softphone, through the peer trunk, into a workspace test agent.
  • One low-volume DID. Use a support line or an after-hours number where a regression is survivable.
  • Overflow only. Let the workspace take the calls that the legacy queue rejects.
While you run in parallel, watch the same signals that you would trust on any PBX: per-trunk answer ratio, average call duration, and an estimated MOS from the media plane. All are visible in the workspace reports. See Observability for what the system captures per call.
Keep the old system as the rollback for as long as it costs you nothing. Each DID and outbound route moves on its own. Thus a rollback is only a re-point of one number or one dialplan entry. You never have to reverse the whole migration at once.

​
Step 3 — Move trunks and numbers

When a route behaves well in parallel, make the workspace authoritative for it.
1

Re-point the carrier trunk

Update your carrier/SBC to send that DID’s INVITEs to <workspace-id>.sip.clutchcall.dev instead of your old PBX. Or, if you prefer not to touch the carrier yet, keep the carrier pointed at the old box. Let the old box forward the DID over the peer trunk from Step 1. Both work. The direct re-point removes a hop.
2

Register the number in the workspace

Add the DID to your workspace inventory. Bind it to a trunk, an AI agent, or an IVR/ACD flow. See Number Provisioning.
3

Route the inbound call

Decide what answers: an AI agent, a play-and-hangup announcement, or a full IVR/skill queue. See Inbound Calls and PBX & ACD.
4

Verify, then move the next route

Check that the DID behaves end to end. Then repeat for the next number or outbound pattern. One route at a time keeps every change small and reversible.
For outbound, re-point your dial patterns to originate over a workspace trunk. The Outbound Calls page covers click-to-call and paced campaigns.

​
Step 4 — Rebuild call flows natively

This part is deliberately not an import. Your Asterisk dialplan or FreeSWITCH XML encodes years of accreted behaviour. A migration is the moment to keep what matters and drop what does not. Map the concepts by hand: The IVR/menu concepts map cleanly. The dialplan scripting does not. There is no automated translator. Treat each flow as a small rebuild.

​
Why teams do this

ClutchCall’s gateway is a modular, shard-per-core engine with an in-process RTP media plane. Thus it carries far more concurrent audio per CPU than a traditional channel-driver PBX. In one media-plane benchmark on identical hardware, the workspace engine sustained roughly 3.7× more calls per unit of CPU than Asterisk 20.6 (chan_pjsip). See Benchmarks for the exact scenario, hardware, and caveats before you quote it.
That figure is a media-plane measurement under a specific G.711 playback scenario. It is not a promise about your workload. Both systems in that test were capped on call-setup, not media. Validate against your own traffic during the side-by-side phase before you plan capacity around it.

​
Next steps

Migration overview

The general phased-cutover playbook that this page specializes.

Migration checklist

A step-by-step cutover checklist to work through.

SIP trunking

Wire the peer trunk field by field.

PBX & ACD

Rebuild queues, IVR, and agent routing natively.