Some businesses still answer their phones through a self-hosted copy of Twilio’s original OpenVBX: a PHP app on a server somewhere, set up years ago by someone who may no longer be around. It still routes calls, so nobody touches it. Then the server needs an upgrade, a PHP update breaks something, or a voicemail stops arriving, and the team realizes nobody knows how it works.
This guide is for that team. It covers what the archived project means for you, the three realistic options, and a checklist of what has to move if you decide to migrate. It’s written by the Xsquare team, who built the hosted OpenVBX product and also do custom Twilio development, so we’ll be upfront about where each option fits.
The original OpenVBX project is archived
The open-source code lives at github.com/twilio/OpenVBX. GitHub shows the repository was archived by its owner on 4 March 2021 and is now read-only, which means no new fixes or updates will come from it. Its README lists PHP 5.2.3+ and MySQL 5+ as requirements, which tells you how old the codebase is.
For a team still running it, that has practical consequences:
- Security fixes are on you. Nobody upstream is patching the app or its bundled libraries.
- Server upgrades get risky. Moving to a current PHP version can break an app written for much older PHP, and staying on an old version carries its own risk.
- Knowledge is fragile. Plugins, custom call flows and server settings often live only on that one machine.
- Twilio keeps changing. Twilio’s APIs and US messaging rules, such as A2P 10DLC registration, have moved on since the code was last updated.
None of this means the phones stop tomorrow. It means you should decide on a plan before something breaks.
Before you decide: a quick audit
Spend an hour answering these questions. The answers usually point to the right option.
- Which PHP and MySQL versions is the server running, and who can log in to it?
- How many numbers, users and call flows are in use today?
- Which plugins are installed, and does anything depend on them?
- Where do voicemails and recordings end up, and does anyone need the old ones?
- Do you text customers from these numbers, and is that traffic registered?
- What would you add if the system were easy to change?
Three honest options
Option 1: Keep it and maintain it
If the install is stable, call volumes are low and nobody needs new features, keeping it can be reasonable for now. Do it properly: back up the database and code, put the server behind current security patches, document every call flow and plugin, and assign someone who can fix it. Accept that every PHP or server upgrade will need testing, and that you are effectively maintaining an unsupported app yourself.
Option 2: Move to a hosted product
If you want what OpenVBX did (call flows, voicemail, shared numbers, SMS) without running a server, a hosted system is the shortest path. Our own OpenVBX cloud platform takes its name from the original project but was rebuilt from scratch with Node.js and React Flow. It runs on your own Twilio account and adds a drag-and-drop call flow editor, two-way and bulk SMS, a browser dialer, a CRM with booking, and an AI receptionist. It has a 7-day free trial with no card required, and Twilio bills your calls and texts separately at Twilio’s rates.
Because it uses your existing Twilio account, your phone numbers don’t have to move anywhere. They are pointed at the new system.
Option 3: Have a custom Twilio app built
If your old install was heavily customized, with plugins that talk to your own database, unusual routing rules, or calls that need to live inside your own software, a custom Twilio IVR and SMS app may fit better. You get exactly the behavior you had (or better), in modern code that you own, still running on your own Twilio account. This costs more up front than a subscription and needs ongoing maintenance, so it’s worth it only when a product can’t do what you need. See our post on Twilio IVR options for how Studio, custom code and hosted tools compare.
What has to move: a migration checklist
Whichever way you go, the work is mostly inventory and testing. Use this as a starting list.
Phone numbers
With OpenVBX, your numbers live in your Twilio account, not in the app. They stay where they are. Migration means changing each number’s voice and messaging webhooks from the old server to the new system. List every number and what it’s used for before you start.
Call flows
Write down each flow: greetings, menu options, business-hours rules, who rings and in what order, where voicemail goes. Screenshots of the old flow editor help. These are rebuilt in the new system, not copied automatically.
Users and groups
List each user, their devices (desk phone, mobile, browser), and the groups they belong to for ring rules.
Greetings and audio
Download any recorded greetings and hold audio so they can be uploaded again, or replaced with text-to-speech.
Voicemails and call recordings
Decide what you need to keep and for how long. Recordings may sit in your Twilio account, on your server, or both. Export what you need before you shut anything down, and check your own retention obligations.
SMS history and contacts
Export message history and contacts from the old database and from Twilio’s logs if you want them in the new system. Contacts can usually be imported as a CSV file.
Plugins and integrations
List every plugin and anything that posts data to another system. Each one is either replaced by a built-in feature, rebuilt, or retired.
10DLC registration
If you text US customers from local numbers, check that your A2P 10DLC brand and campaign are registered and that the numbers are in the right Messaging Service. If a campaign was rejected, our guide to fixing a rejected 10DLC campaign can help.
Cut-over and rollback
Test the new setup on one spare number first. Then switch numbers over during a quiet period, make test calls and texts, and keep the old server available, unchanged, for a short time so you can point a number back if something was missed.
FAQ
Is Twilio’s OpenVBX still maintained?
No. The GitHub repository shows it was archived on 4 March 2021 and is read-only.
Will I lose my phone numbers if I move off OpenVBX?
No. OpenVBX used numbers in your own Twilio account. Moving means changing where those numbers send calls and texts, not porting them.
Can my old call flows be imported automatically?
Plan to rebuild them. Document each flow first, then recreate it in the new system and test it.
Is the hosted OpenVBX the same code as the original?
No. The Xsquare team rebuilt it from scratch with Node.js and React Flow. It shares the name and the idea, not the old code.
When does a custom build make sense instead?
When your old install relied on custom plugins, your own database, or routing rules a product can’t handle.
Next steps
If you want a hosted system, start an OpenVBX trial. If you need a custom Twilio build or help planning the move, see our Twilio development services or contact Xsquare with a short description of your current setup.
