From 15 to 17 without duplicating licenses?

Hello

can someone explain to me how to perform the switch \ upgrade between two pabx? Let me explain better, I have an old freepbx at version 15 with several licenses and commercial modules still active and expensive, for example one of these has 1000 Sangoma Phone licenses. We are facing a migration process to the current version 17. I do not intend to perform an upgrade but to have a clean machine on which to progressively migrate the extensions and settings and then activate everything. The problem is that I cannot have two machines with the same ID and therefore I cannot perform the configurations on the commercial modules unless I duplicate the purchase, which is absurd. Is it possible that Sangoma does not have something like a temporary license, alias of an ID or a procedure to not generate additional costs?

The short answer, there really isn’t one because someone with no real technical experience at Sangoma made a business decision about commercial licenses.

See on all the older versions (v16 and lower) you could run a backup of your system, spin up a new server and restore your backup to it. It would restore the entire backup, including your commercial modules and the associated data (database entries, etc). In the end it would check all of your licenses, realize your licenses were bound to a different machine and disable the commercial modules until the licenses where moved. It would also lock you in the version if your support fees hadn’t be paid. However, if you knew the secret handshake of the Water Buffalo Lodge you could actually get the newest version of the module and trick the system allowing you to get a “free upgrade” of the module(s).

Someone (or more than one) at Sangoma saw this bad thing and decided the license check needed to be improved on restores. So now it seems during the restore process it checks the license and if there isn’t an existing license on the server it just doesn’t restore the module at all. Not restore and then lock it out so you can’t use it, just not restore anything at all. Oh and not a single warning about it either. So even after you moved your licenses you find that not a single one of your commercial modules had any data restored at all. They are all clean slates. Now of course you in your catch 22 because now you’ve moved your licenses and trying to do another backup from your old system won’t work on the commercial modules because no valid licenses. Your only option at that point on the v17 system is to restore your backup again so the commercial modules will this time around be restored properly because you’ve moved the licenses. Of course it also means your new v17 is most likely out of sync in regards to data.

I get why they wanted to do it but it has been a complete clusterf@%# of an implementation and probably something that should have been saved for v18 for better migration control. This has been going on for over a year, numerous complaints but not a single person at Sangoma has decided to rectify this.

I am curious though as to who made the big business decision to make upgrading a FreePBX system using commercial modules to v17 the most pain in the ass process they could come up with. Clearly not one person at the table making these decisions advocated or even thought about the complications they were putting on their own user base.

1 Like

This is simply madness, if you then add that backups and restore do not always work, let alone when it comes to different OS and different versions of freepbx…and the omelette is done. I honestly do not understand how it is possible not to have thought of something like this and I am really in difficulty. The only option is to configure everything that is configurable in the new version 17 and then migrate the id but this will create stops for some applications… I have dozens of groups in the user manager with different permissions for Sangoma and the visibility of the queues in the softphone, thousands of phones in the endpoint module and so on… the IT manager will not be happy and these are the things that then push you to abandon a system, when a company thinks small and does not care about customers.

I know nothing about the technical details, but if the backed-up module data is unencrypted, couldn’t you just bypass the check?

The check is within the modules themselves now it seems. So no, you can’t bypass the EPM check when it is part of the code in a commercial module.

Almost every commercial module is available on the Sangoma store with a 1 month free trial, which should get you around the problem before moving your Deployment ID:

  • Appointment Reminder
  • Call Accounting
  • Caller ID Management
  • Call Recording Report
  • Conferences Pro
  • CRM Link
  • EndPoint Manager
  • Extension Routing
  • Outbound Call Limit
  • Page Pro
  • Q Xact (Queue Reports)
  • Phone Apps
  • SysAdmin Pro
  • VM Notify
  • Voicemail Reports
  • Web CallMe
  • XactDialer (Broadcast)
  • Fax Pro
  • PINSet Pro
  • Park Pro
  • VQ Plus (Queues Pro)
  • Class of Service
  • Scribe with 10 Minutes
  • CDR Pro
  • MFA for 1 User
  • Queue WallBoard
  • SangomaConnect for 2 Users

It’s not the same thing

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.