FreePBX 17 upgrades

So what’s the procedure for upgrading FreePBX 16 to 17? I haven’t seen anything mentioned about it anywhere and there’s no sign of an updater module on edge. Was going to give a try soon but wanted to see if there was anything planned to happen…

I think you would be best served by creating a backup, then restoring that to the new system. SangomaOS later FreePBX OS was changed from based on Red Hat to based on Debian.

You may have missed the blog post that details this, including the wiki article on installing. It is not advised for production systems as FPBX 17 is beta.

No, that’s not an option for people who aren’t hobbyists. And I’m not using FreePBX OS.

I have used this post to spin up FreePBX 17 on a Debian 12 cloud image.

Previous Sangoma posts indicate that FreePBX-17 and their commercial OS will be based on Debian 12. I would guess that just as people use Debian and Ubuntu, that the finished product will run on current releases of those OS as well.

I did a FreePBX backup of my FreePBX-16 system and restored it on the FreePBX-17 system and it mostly worked. Understand that FreePBX-17 is still pretty much Alpha software and is incomplete. It will be a while before they fully deploy it. I would not deploy it in a production environment until it is finished.

What do you want to achieve? What do you miss on the freePBX 16 machine? Why not wait until 17 is stable?

1 Like

you will restore into it - taking a compatible backup and restoring that into a freshly built 17 system.

I’ve been testing it extensively for the last month or so… its going to be amazing :slight_smile:

I mean, the current release has under 50% of the OSS modules that currently are in use by FreePBX. I’m not sure what extensive testing there has been unless, of course, there’s just been more development behind the scenes that we can’t see.

So far this all has been a big disarray of issues. The bug/issue tracker is down, the wiki is a complete mess and the beta of FreePBX v17 that is out there is the most nonproductive beta released in the last 10 years. OSS development on v17 has been basically done in the shadows and none of us have been able to contribute because, as pointed out, everything is up in the air/in flux/a hot mess right now.

After over a year of paying for VMs to use as development for v17 and spending pretty much of 2023 fighting with broken development infrastructures and repos that were never in sync and out dated with the current development, amazing isn’t a feeling I’m getting right now about it.


Then I recommend waiting until the program is out of beta. Many potential problems to avoid this way. What is the urgency behind needing to upgrade/review a system that’s still in beta?

Did my post sound like there was any urgency? I have a lot of PBXs to manage – many of which are under strict SLAs – which involves planning well in advance for future changes. The impression I got from Sangoma’s breathless blog posts was that 17 is nearing a final release.

lol no I will not

First you ask then you lol? :thinking::roll_eyes:

FreePBX 17 Does not exist outside of BETA, with no confirmed release date. I would treat it as non-existent until official release.

there has been a lot more development and testing behind the scenes and this is ongoing - I think the community will be impressed with the work; im not sure what youre working with but its sounds very different from the current state of affairs with respect to what ive been testing.

we look forward to sharing this with everyone very soon :slight_smile:

1 Like

@cdolese this is fantastic to hear, and we appreciate the hard work being done. With the previous versions, there was kind of a list of what was coming with the version. Besides the big move from CentOS, is there or will there be a list of changes/enhancements for 17?

Per the blog, FreePBX v17 is on a new OS and the only way to migrate to it is a new build. Unless you are running OSS installs on Debian already then you are fine. But if you have Distro installs, new machines will be needed.

As mentioned above, I’m not using their OS. I guess I’m an old-school sysadmin – I don’t want a PBX web interface in control of my whole system. So it’s just a PHP application, and not tied to an OS. If there isn’t going to be a GUI-based upgrade path, it’s not super complicated to do it manually. But that would be breaking with like 15 years of precedent and just one more minor annoyance to plan for. Hence my question…

So you are saying github is still simply a mirror and should not be taken as the latest and most up to date source for code from the project?


17’s initial focus is solely on the transition - that is the big thing : )

that said , system performance by nature of the modernization seems vastly improved in my testing and i think most will agree when they finally touch it

1 Like

To answer @miken32 actual question unofficially It so far seems like the update path for “NON DISTRO” systems will loosely be the following. There will probably be dragons on this path but it should work at some level. Hopefully the freepbx upgrade tool will be updated to help with this but with the “supported way” being an OS change I have low hopes… Unfortunately the version upgrade module is NOT open source so the community legally can’t fix it. Perhaps @lgaetz @cdolese @ncorbic or one of the other official people would allow that module to be re-licensed and released to github so the community could update it legally.

  1. Update the host to php 8.2.X
  2. Download the tarball and on an existing system run ./install -n
  3. Use fwconsole ma updateall

Yup this is pretty much what I’ve done, though just fwconsole ma downloadinstall with a URL works fine without the need to rerun the install script. There were a couple of patches needed to get it working. For the record, this is what my process looked like as of this morning:

fwconsole ma upgradeall --edge

dnf module switch-to php:remi-8.2
dnf module switch-to nodejs:18
dnf -y update

# patch a fatal error that was just a warning in PHP 7
# waiting on a PR to be accepted to fix this
sed -i '/public function query/s/public/#public/; /#public function query/a public function query(string $query, ?int $fetchMode = null, mixed ...$fetchModeArgs){' /var/www/html/admin/libraries/BMO/Database.class.php

fwconsole ma downloadinstall

# version locked composer install causes an error, not sure why this fixes things???
pushd /var/www/html/admin/libraries/Composer && composer require symfony/translation ~6.3 && popd
fwconsole ma upgradeall
# restore the framework module
fwconsole ma downloadinstall framework
fwconsole reload
1 Like