Official announcement that the conversion utility at convert.freepbx.org used to migrate settings from old FreePBX versions will be shut down on or after September 28, 2020. There will be no replacement service as usage has pretty much stopped now that FreePBX 15 directly supports legacy restores with the Backup module. Additional information on Backup and Restore in 15+, see the wiki page: https://wiki.freepbx.org/pages/viewpage.action?pageId=114852215
Anyone who has need of this service has until this coming Monday to wrap up what they are doing.
While just a 3 calendar/1 business day notice is a little on the short end of things, I think the primary reason the conversion server is hardly used anymore is because it really hadnât worked reliably in a long while. I think we had a 1-in-10 success rate prior to v15 GA, even coming from official to official, like with upgrading v12 to v14 (which historically worked better with convert than the upgrade path).
That said, it wonât be missed at this point. All hail v15 Restore!
V14 to v15 upgrade is a module-level upgrade and doesnât do much at the OS-levelâŚit doesnât use convert.freepbx.org for anything. You really donât even need to fuss with v15 Restore to move from v14, unless you want to change physical machines. Iâve yet to see the v14=>v15 upgrade module fail on a production system.
We still have around a dozen FreePBX 13 servers on HyperV due to the fact that thereâs no upgrade path, I donât think that weâll necessarily need that tool to migrate.
However, is there a possibility to get this script on GitHub, so we can host it internally in case needed?
I doubt that will be possible but I will make inquiries. Our project goal is to have the Backup and Restore module in 15 do everything, so please ensure to open bug tickets if you run into problems migrating your 13 systems.
You really should give the v15 Backup/Restore method of migration a try. Just fire up a fresh v15 install in a new VM, restore one of your v13 serversâ backups on the new machine and see how it goes. As @lgaetz mentioned, reporting bug tickets if you encounter an issue on this first test run would allow for those bugs to be addressed and let you migrate all of your v13 systems to v15.
Migration to a new VM is much safer than trying to upgrade in place or use the convert tool. Thereâs effectively no risk to the in-production v13 instances. You can test the v15 restores all you want before swapping them into production.
If youâre using Backup and Restore on 15 to migrate the settings, then it should not be a hell of a job it should be nearly seamless. If itâs not, those are the tickets we want, and we wanted them a year ago. The first part of this year saw several tickets a week being opened and fixed on Backup 15, but they are far less common now. If you havenât done a legacy restore in a while, give it a try again and see how itâs working for you.
There is no way to do it because there is no way to activate the commercial modules on the target. This is a long known horrid limitation of FreePBX commercial module management.
Came here to say this. If thereâs somehow a way to confirm that the data of all commercial modules were migrated prior to moving the licenses then we can try it.
Yes, yes, yesâŚthere have been issues with regard to restoration and licensing in the past. We had a lengthy conversation with @ncorbic about this a few months ago. The team has been working hard to rework the restoration vs licensingâŚweâll just say âconflictââŚin recent months.
This has been a matter of particular interest to us here at TheWebMachine Networks - we do dozens of migrations every single week - and we check back on it often. At last complete testing just a couple weeks ago, we didnât encounter any issues with commercial module data restoring without the activation/licenses in place before the restoreâŚbut you still have to move the activation/license(s) in place after the restore, before youâll be able to utilize the modules on the new system.
To say there is âno way to activate the commercial modules on the targetâ is misleading. As soon as you Zend Reset the Deployment ID from the old system to the new system after restoring the data, your commercial modules will be configured and working just fine. Even when there was an issue with restoring commercial module data on an unactivated system, you could still Zend Reset and move the Deployment ID and then restore all your data, commercial modules included, without issue.
Of course, as @lgaetz suggests, no one can even begin to fix any of these issues you might still be experiencing if you donât report them in the bug tracker! Complain all you want, but we canât fix it if we donât know whatâs broken.
Thereâs always a wayâŚ
Compare the DB contents from both systemsâŚwhile some core modules obviously change DB structures across versions, a lot of modules are rather major-version-agnostic in nature (youâll note that the Bulk Handler version is still v13, even on v15 systems). An unactivated module wonât add to to the dialplan in /etc/asterisk/*.conf until it is activated, but the config will still be populated in the DB.
In the case of EndPoint Manager, you can confirm that /tftpboot/ contents match up between systems and also confirm via its tables in the DB.
In short, Restore will populate the asterisk DB tables for those commercial modules. Activation will expose/unlock the GUI pages AND allow the appropriate dialplan to be generated from the DB for those modules.
I am not sure which issues you are referring to, which you say we have to report so itâll get fixed.
Lorne suggested that I should try to perform a restore and if bumping into issues (if any) I shouldnât hesitate to report it.
Did I miss anything?
This doesnât confirm the migration is/was successful, rather that the DB has some data. The only way to that know for sure, at this time, is once the modules are activated.
And again, migrating with these suggestions is still:
Nope. I intended it as an âIfâ for those who do encounter a bug and a âDoâ to others who have complained that the restore doesnât work but donât submit bug reports so it can be fixed. Pardon any confusion there.
If you compare the entire contents of the DBs - you already have a .sql export in the old system backup and you can easily export a .sql from the new system - how does this not confirm that your data was migrated successfully? The DB is where the dialplan and all the other âmagicâ gets generated from for any of the commercial modules. If itâs there on the new system after restore, then it was migrated.
That having been said, there comes a point where youâve taken every precaution you can and you have two choices:
Buy a second set of licenses so you can have both activatedâŚyou can reuse the second set later for a warm spare, since youâre so concerned about interruption to your production environment.
Move the licenses to the new system and confirm that all is as it should beâŚIF it isnât, reset and move your Deployment ID back to your old system until the issue can be looked at further. Nothing on the old system will be destroyed when you deactivate the Deployment ID, so it can be moved back easily enough. At most, you have to submit a ticket and ask for a manual reset from Sangoma Support if youâve exhausted your self-service resets.
Iâm not sure what you want from Sangoma on this oneâŚto let you have two machines with working commercial modules when you only have one set of licenses? Thatâs a relatively easy target for abuseâŚjust keep restoring backup files to new servers and never activate them. If you create an easy way to bend the rules, everyone will rush in to break them and have zero remorse for it.
Iâm sure they will figure out a compromise eventually, with enough feedbackâŚbut unless youâve come with a detailed plan of action for âfixingâ this to your satisfaction without opening the piracy door wide - and if you do, Iâm sure Sangoma would love to hear it - youâre just barking at the wind.
Again, all you do is naysay and offer no potential solutions or ideas of your own for what you actually want to see happen here. 𤡠How do YOU want it fixed? What would this âsmooth migrationâ you so desperately proclaim doesnât exist even look like? I offer options to your complaint; you offer nothing but âthatâs not what I want,â in return.
