# From Asterisk / FreeSWITCH > Run Asterisk or FreeSWITCH beside your workspace as a SIP peer. Then move trunks and numbers over on your own schedule. You do **not** remove Asterisk or FreeSWITCH to adopt FirstByte. 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. > **WARNING:** > **There is no automated Asterisk/FreeSWITCH import.** FirstByte 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. FirstByte'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 FirstByte 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 FirstByte 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](/modalities/voice/transport-telephony/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: ``` .sip.firstbyte.fast (SIP signalling, :5060) ``` Offer **G.711 (PCMU/PCMA)** on the trunk. It is the universal phone codec. It needs no transcode on either side. Configure your Asterisk/FreeSWITCH box as a **trunk inside the workspace**. Then the workspace can deliver calls *back* to extensions, queues, or legacy IVR that you did not migrate yet. This keeps day-one behaviour intact: a caller can reach a new AI agent and can still be transferred to a human on a legacy extension. Add the trunk with **Realm = Internal** and the SBC/Gateway IP set to your PBX. The engine matches a configured trunk peer by source IP. Thus your PBX does not have to register or digest-authenticate to be reachable. See the ACL note in [SIP Trunking](/modalities/voice/transport-telephony/sip-trunking). > **NOTE:** > On this page, **Asterisk** and **FreeSWITCH** refer to the external systems > that you migrate away from. FirstByte 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 FirstByte 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](/modalities/voice/observability/overview) for what the system captures per call. > **TIP:** > 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 `.sip.firstbyte.fast` 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](/modalities/voice/transport-telephony/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](/modalities/voice/transport-telephony/inbound) and [PBX & ACD](/modalities/voice/transport-telephony/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](/modalities/voice/transport-telephony/outbound) 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: | On Asterisk / FreeSWITCH | Native equivalent in FirstByte | | ------------------------------- | ------------------------------------------------------------------ | | SIP/PJSIP trunk profile | A workspace **trunk** ([SIP Trunking](/modalities/voice/transport-telephony/sip-trunking)) | | `extensions.conf` / XML dialplan| Inbound routing rules + **IVR/ACD programs** ([PBX & ACD](/modalities/voice/transport-telephony/pbx-acd)) | | Queues / agents (`queues.conf`) | **Skill queues** + agent endpoints ([PBX & ACD](/modalities/voice/transport-telephony/pbx-acd)) | | IVR menus (`Read`/`Background`) | IVR steps with prompt playback and digit collection | | Registered SIP phones | **Agent endpoints** — browser softphones or real SIP deskphones ([PBX & ACD](/modalities/voice/transport-telephony/pbx-acd)) | | AGI / dialplan apps / bots | An **AI agent** — bring your own ASR/LLM/TTS or speech-to-speech ([Runtime](/modalities/voice/runtime/overview)) | 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 FirstByte'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](/modalities/voice/benchmarks) for the exact scenario, hardware, and caveats before you quote it. > **NOTE:** > 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](/modalities/voice/migration/overview)** — The general phased-cutover playbook that this page specializes. - **[Migration checklist](/modalities/voice/migration/checklist)** — A step-by-step cutover checklist to work through. - **[SIP trunking](/modalities/voice/transport-telephony/sip-trunking)** — Wire the peer trunk field by field. - **[PBX & ACD](/modalities/voice/transport-telephony/pbx-acd)** — Rebuild queues, IVR, and agent routing natively.