Sunset date for convert.freepbx.org


(Lorne Gaetz) #1

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.


Convert.freepbx.org timeout
(Lorne Gaetz) pinned globally #2

#3

Just checking if the FPBX module to update from FPBX 14 to 15 uses this service?


#4

googling around, seems like convert.freepbx.org was for migrating from non-freepbx distros?


(Dave Burgess) #5

The 15 restore module should be able to handle those as well, so I can see this being deprecated.


(TheWebMachine Networks (Sangoma Software Development Partner)) #6

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! :vulcan_salute:

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.


(Itzik) #7

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?


(Lorne Gaetz) #8

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.


(TheWebMachine Networks (Sangoma Software Development Partner)) #9

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.


(Itzik) #10

That’s not true. Migrating commercial modules and it’s data from one server to another is a hell of a job.


(Jared Busch) #11


(Lorne Gaetz) #12

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.


(Jared Busch) #13

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.


(Itzik) #14

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.


(TheWebMachine Networks (Sangoma Software Development Partner)) #15

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. :man_shrugging:

There’s always a way…

  1. 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.
  2. 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.


(Itzik) #16

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:


(TheWebMachine Networks (Sangoma Software Development Partner)) #17

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:

  1. 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.

  2. 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. 🤷


(Itzik) #18

Again. Allllllllllllllllllllllllllllllllll what you just said is still not a smooth migration. Period. You know it, we know it and Sangoma knows it.


(TheWebMachine Networks (Sangoma Software Development Partner)) #19

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.


(Jared Busch) #20

It has been discussed previously. Go look search for it. It is not a secret.