Migrating from an on-prem PBX (Elastix, AsteriskNow, legacy boxes) to a LYLIX VPS PBX

Moving a PBX from a physical box in a closet to a hosted VPS is one of the most common LYLIX onboardings. The good news: with FreePBX® or FusionPBX® on both ends, most of the migration is config transfer rather than ground-up rebuild. This article covers the realistic sequence, what doesn't migrate, and the cutover day playbook.

What you're moving from

The legacy boxes we see most often:

• Elastix — discontinued; was a wrapper around FreePBX. Old installs are usually CentOS 5 or 6.
• AsteriskNow — also discontinued; was an early bundling of FreePBX + Asterisk on CentOS.
• Original Schmoozecom PBX (FreePBX Distro) on various CentOS versions.
• Trixbox — long discontinued, occasionally still seen.
• Bare Asterisk — hand-rolled; usually decades old.

If you can identify the version, you can pick a destination that matches closely enough that backup-restore is feasible.

What migrates cleanly

• Extensions and their passwords.
• Inbound/outbound routes.
• SIP trunks (you'll re-enter passwords).
• IVR menus and announcements.
• Voicemail boxes (and the recordings, with extra steps).
• Queues and their member lists.
• Time conditions and groups.
• System recordings (music on hold, custom prompts).
• CDR history (with extra steps).

What doesn't migrate cleanly

• Phone provisioning files. If the legacy box's EPM (or hand-rolled provisioning) had per-MAC configs, you migrate the templates but reprovision each phone to the new PBX's URL.
• Commercial module activations. The deployment ID changes; you re-activate against the new install.
• OS-level customisations. Custom dialplan files outside /etc/asterisk/extensions_custom.conf, custom cron jobs, custom scripts in /var/lib/asterisk/agi-bin/. These need manual transfer.
• Old version-specific features. Removed modules don't come back. Old IVR features that depended on a now-removed module need redesign.

Pre-migration checklist

• Inventory the legacy install. FreePBX version, Asterisk version, OS, installed modules, commercial modules, phone count, trunk count, DIDs.
• Pick the destination FreePBX version. Match the major version of the source if possible. Migrate first, upgrade later.
• Order the LYLIX VPS with appropriate sizing. PBX VPSes don't need a lot of CPU for moderate call volume but benefit from quick storage. See VPS plan sizing.
• Note carrier IPs. Some carriers allowlist by source IP. You'll need to add the new VPS IP to their allowlist before cutover.
• Plan the DID port window. If you're also moving DIDs to a new carrier at the same time (don't, if you can avoid it), the port itself can take 2-6 weeks.

The migration sequence

1. Provision the new LYLIX PBX VPS. Pick the FreePBX (or FusionPBX) distro that matches your source.
2. Take a backup of the legacy PBX via Backup & Restore. Settings → Backup & Restore → Backup → Default Template (or one that captures everything).
3. Transfer the backup tarball to the new PBX via SCP.
4. Restore on the new PBX. Settings → Backup & Restore → Restore → upload the tarball → apply. Reload after restore.
5. Re-enter trunk passwords. The restore usually carries them but it's worth verifying every trunk. Trunks → each trunk → outbound and inbound registration password.
6. Add the new VPS IP to each carrier's allowlist. Until the carrier accepts traffic from the new IP, registrations fail.
7. Test extensions registering and trunks connecting on the new PBX before any cutover. Use a single test phone manually pointed at the new PBX first.
8. Re-activate commercial modules against the new Deployment ID.
9. Test call paths internally and via trunks. Internal extension to extension, outbound to a known number, inbound to a known DID.

Cutover day playbook

Plan a low-traffic window (off-hours, weekend).

1. Take a fresh backup of the legacy PBX just before cutover — captures last-minute config changes.
2. Stop new calls on the legacy PBX. Disable its inbound routes or pause its trunks.
3. Apply the fresh backup to the new PBX — this is the final state sync.
4. Repoint trunks at the new PBX. Each carrier's portal: update the SIP destination IP from legacy to LYLIX VPS.
5. Reprovision phones. Bulk update the provisioning URL via EPM or your provisioning server. Reboot the fleet; they pick up new SIP server.
6. Test core paths. Internal call, outbound to a cell phone, inbound to a known DID, voicemail.
7. Monitor for 30 minutes while traffic ramps back up. Watch the CDR.
8. Leave the legacy PBX running but isolated for at least a week in case you need to revert or pull anything missed.

What can go wrong

• One carrier's allowlist still has only the old IP. That trunk fails after cutover. Have all carriers' portals open during cutover and verify.
• Phones fail to reprovision. Old provisioning URL is in flash and bulk reboot didn't pick up the new URL. Manual reset on the affected phone.
• Voicemail boxes lost their recordings. Backup & Restore captures voicemail box config but you'd need to verify the recordings template was included. Test before cutover.
• CDR history doesn't show. CDR DB schema differences between major versions. May need to migrate the CDR DB separately with a column-level sync.

When backup-restore won't work

If the source PBX is too old (FreePBX 12 or earlier, or ancient Elastix) or too custom for a clean restore:

• Rebuild on the new PBX manually using the legacy box as a reference. Slower but cleanly leaves accumulated cruft behind.
• For very old installs this is often what you want anyway — the legacy install has years of half-disabled features and broken modules.

For migration assistance, open a ticket — we've done a lot of these and can advise on the path of least resistance for your specific source system.