Knowledge
Moving from 3CX to a Yeastar P-Series: what carries over and what is rebuilt
Yeastar publishes a migration guide from 3CX to the P-Series and a PBX Migration Tool that converts a 3CX user export into Yeastar extensions. The users, their settings and their departments import. The trunks, the inbound and outbound routes and the emergency numbers are rebuilt by hand, deliberately, because they are the parts that have to be right. Handsets are re-provisioned to the new system. Here is the sequence, what each step carries, and how we run it. We do not disparage 3CX; organisations move for their own reasons, usually licensing or support, and the job is to move them cleanly.
By Dar Zuch, Yeastar Certified Expert · Last reviewed 4 November 2026
What migrates, and how
| 3CX element | On the P-Series | Mechanism |
|---|---|---|
| Users and extensions | Extensions, with user profile and settings | Export from 3CX (V18) to a file; the PBX Migration Tool converts it to the P-Series import format; import in the Yeastar management portal |
| Departments | Extension groups | Mapped by the tool during import |
| SIP trunks | SIP trunks | Recreated manually in the Yeastar portal, one per 3CX trunk, then the trunk is removed from 3CX so registration moves cleanly |
| Inbound routes | Inbound routes | Replicated by hand from the 3CX configuration |
| Outbound routes and dial plan | Outbound routes | Replicated by hand, including the prefixes and the extensions permitted to use each route |
| Emergency numbers | Emergency numbers, with notification contacts | Mapped by hand, and tested; the guide has a dedicated section for it |
| IVRs, queues, ring groups, time conditions | The same objects | Rebuilt from documentation of the 3CX configuration |
| Voicemail and recordings | Not migrated as data | Retained from 3CX where retention requires it; new voicemail boxes on the P-Series |
| IP phones | Re-provisioned | Yeastar auto-provisioning on the same subnet, with documented steps for remote networks and different subnets |
Yeastar’s guide frames the whole process as a checklist: back up 3CX, prepare the P-Series, import users, build trunks and routes, migrate phones, verify, then enable the trunks on the new system.
Why the trunks and routes are rebuilt rather than imported
Two reasons, and we agree with both. First, trunk credentials and registration belong to a carrier relationship and should be created fresh, not copied. Second, routes are where dial-plan mistakes hide: an outbound route that lets a lobby phone call international numbers, an emergency number that needs a prefix on the old system. Rebuilding them is the moment to fix them. On every migration we document the 3CX routes first, then build the Yeastar routes against the documentation, then test each one, including 911 from a sample of extensions.
Handsets
Yealink, Fanvil, Snom and other provisioned handsets are re-pointed at the P-Series. On the same subnet the P-Series discovers and provisions them; across subnets or at remote sites the guide gives the provisioning-server steps. Handsets that 3CX provisioned with its own templates lose nothing a user will notice: the extension, the display name and the line keys are provisioned again from the P-Series template.
Licensing, in plain terms
A 3CX system is licensed by simultaneous calls on an annual subscription. A P-Series appliance is licensed by users: the unit with the Standard plan is a one-time purchase, and the Enterprise or Ultimate plan, the hotel module and remote management renew. The plans page has the structure. For most organisations that have been watching the 3CX renewal, the shape is the main thing that changes, and we lay both shapes side by side on the quote.
How we run it
- Health Check on the 3CX system: inventory, port map, trunk and route documentation, the 911 path as it is today.
- P-Series built in Calgary with the imported users, the rebuilt trunks and routes, and the handset templates, and tested on our bench.
- Cutover in a window you choose, with the 3CX kept running until the new trunks register and every route is tested. Numbers port where the carrier changes.
- Documentation handed over, and a support agreement if you want one.
Frequently asked questions
Does the migration tool work from 3CX V20?
Yeastar’s guide is written for 3CX V18. For V20 we confirm the export format with Yeastar before quoting; the manual parts of the migration are the same.
Will our call recordings move?
Recordings and voicemail are not migrated as data. Where retention matters, the 3CX archive is kept, and the P-Series starts its own.
Can we keep our 3CX trunks?
Yes, recreated on the P-Series with the same provider. Or move to ours, which is what the support agreements assume, because then one party sees the whole path.
How long does it take?
It depends on the number of routes and the handset count more than the user count, because those are the manual parts. We measure it in the Health Check.
Migration steps from Yeastar’s PBX migration guide and PBX Migration Tool documentation, checked 4 November 2026.
Start with a Telephony Health Check
A fixed-fee review of what you have, what 911 does, whether the life-safety circuits work, and where the money leaks. $1,500 for a single site, $2,500 for a campus, plus GST, with a written report either way.
or call (403) 698-0700