I’m currently working as an Asterisk developer and administrator at this company. I’ve been coding under Asterisk 18, but we’ve got a bunch of systems still running on the outdated Asterisk 11.18.0. Why? Because my boss isn’t exactly keen on embracing change.
After some persistence, I convinced him to make the move to Asterisk 18. Great news, right? Well, here’s the catch: his code, which I’ll generously label as ‘legacy,’ started throwing issues. He’s a big fan of macros and is unable to figure out what he call “the mess of pjsip” (yeah, I’ve been trying to push him away from that), but we managed to resolve some issues by compiling the macro and chan_sip modules. However, every time we address one issue, another pops up. It’s becoming a bit of a whack-a-mole situation.
I’m curious if there’s a more streamlined approach to migrating from such an old version of asterisk. As far as i know, the current changelogs and upgrade notes won’t go too far as to track changes from asterisk 11 to 18. If a complete dialplan overhaul is the only solution, it might be more practical to stick with the current setup. Given the size of our application, testing everything would be an immense undertaking that I’m not sure my boss is up for.
Any insights or suggestions would be greatly appreciated!
thank you!
You can look at the UPGRADE notes for each interim version to understand what has changed over the entirety. There’s no streamlined approach really, aside from checking those and seeing what is applicable. The more clever an implementation, the more potential changes needed.
I have been migrating along for years. What I have found is that some versions could not be accomodated with an upgrade. Rather a complete reinstall from source was the answer.
That’s what I did. I fired up another box with just the basics, reinstalled our required packages (sox, mpg123, ffmpeg, lame…) reinstalled asterisk 18 from source and just ported the dialplan to this new machine.
This afternoon, after opening this thread, I discovered much more serious errors, which indicate that we will have to redo more things than I would like.
I’m going to dig into these documents to see if I can save this migration project, since I was the one who had the bright idea of modernizing things after all.
I’m intrigued as to what sort of problems you’re running into with this
process.
I took on a customer some 18 months ago who was running an Asterisk 1.8 system
and wanted to upgrade to Asterisk 16 (at that time the current Debian stable
packaged version), and apart from a few consistent dialplan syntax differences,
we managed it without a great deal of fuss.
They’ve since been upgraded to Asterisk 20 without any problem at all, other
than the inevitable chan_sip → chan_pjsip change.
So, please could you explain in a bit more detail what specific problems you’re
running into with this Asterisk 11 → 18 upgrade?
Also, I’m intrigued as to why you’re upgrading to 18, which gives you just
under 2 years from now before it’s EOL, instead of going to Asterisk 20, which
gives you until Q4 2027? Given that the manager is “resistant to change”,
surely you want to reduce the time before the next change becomes recommended?