NOTICE: THIS PAGE IS IN THE MIDDLE OF A REWRITE! We have intentionally removed the Instance Migration method mentioned below, as it is no longer supported by us or Sangoma. With the introduction of FreePBX v15, you may now Restore backup files taken from an older version of FreePBX (v13/v14 fully supported, v12 experimental). We will be writing new guides in the coming days for upgrading and migrating older instances that takes this new, much more reliable method, into account. Please contact our Support staff and we'll gladly walk you through all available methods.

​

​

​

We are pleased announced the release of AWS FreePBX® AMI v3.0 (12.7.4-1710-2); based on RHEL 7.3 and featuring FreePBX® 14, with support for Asterisk® 14 and full Commercial Module support through Sangoma! This page will outline some important information regarding this new release and will be updated as new information becomes available. 

​

AWS FreePBX® v3.0 features a new core OS based on RHEL 7.3 to support the new modern software requirements of FreePBX® 14. This new OS provides all the stability of a RHEL 7 based distribution, with the flexibility of hand-picked and maintained modern packages. However, this presents a significant upgrade obstruction for those presently running production systems on our previous AWS FreePBX versions based on CentOS 6. Fear not, you will still be able to migrate your current AWS FreePBX instances from older versions to AMI v3.0, but it will require a few more advanced steps than a typical SmartUpgrade operation. As always, our support staff are here to help you ensure success in your migration!

​

We now have TWO methods you may choose from to ensure maximum chance of success. We STRONGLY recommend you try the Instance Migration method (#1) first, as this makes ABSOLUTELY NO changes to the existing v2.9 Production system and is, therefore, much safer and can be tried multiple times without harm.

 

If you are unable to successfully complete an upgrade via Instance Migration OR you have a large amount of customized software that would be tedious to replicate on a new instance, you may try the second method below. This is an IN-PLACE upgrade. For this reason, you will need to create a full Machine Image backup via the EC2 Console to prevent the very real possibility of data loss. This second method will also result in a few hours of Production downtime while you perform the in-place upgrade.

​

​

METHOD #1 - The "SAFER" first method you should try!

We have written a full Migration Guide to assist you in this process. This Migration Guide can also be used to migrate non-AWS FreePBX systems (even PIAF!) to AWS FreePBX. You can read the Guide here:

​

(REMOVED: Discontinued)

​

​

​

METHOD #2 - The "RISKIER" in-place method!

This IN-PLACE upgrade needs to happen in TWO phases, with multiple reboots in-between. While most of this process is automated, you will need to be actively monitoring it during the first phase (you will be asked questions based on your unique setup) and then manually initiate the second phase to complete the process.

​

FIRST AND FOREMOST: MAKE A PROPER MACHINE IMAGE BACKUP OF YOUR v2.9 PRODUCTION INSTANCE! THIS PROCESS CAN RESULT IN A TOTAL CRASH OF YOUR SERVER IN SOME RARE CASES, RESULTING IN SUBSTANTIAL DATA LOSS IF YOU DO NOT HAVE PROPER BACKUPS! PLEASE TAKE THE FOLLOWING STEPS TO CREATE THE IMAGE:

​

1. In the navigation pane of the EC2 Console, choose Instances, select your instance, and then choose Actions, Image, Create Image.

   ​

2. In the Create Image dialog box, specify the following information, and then choose Create Image.

   • Image name – A unique name for the image.

   • Image description – An optional description of the image, up to 255 characters.

   • No reboot – This option is not selected by default. Amazon EC2 shuts down the instance, takes snapshots of any attached volumes, creates and registers the Machine Image, and then reboots the instance. Select No reboot to avoid having your instance shut down.

     Warning: Checking this box may result in data loss!!!

​

Once you have a Machine Image of your v2.9 Instance, all you have to do is connect to your instance via SSH and run this command to get started:

​

smartupgrade v3-inplace-upgrade-phase1

​

Follow all instructions VERY carefully and answer 'Y' (YES) to all questions asked in the first phase! If you get an error that abruptly ends Phase 1, please contact our Support Personnel for assistance. The wizard will guide you through all of Phase 1 preparation, then prompt you to reboot the server manually. This will perform the base OS level upgrade. You can monitor the progress by following these steps:

​

1. In the left navigation pane, choose Instances, and select the instance.
    

2. Choose Actions, Instance Settings, Get System Log.
    

3. Click the refresh icon in the upper right of the System Log window every 5 minutes or so and scroll to the bottom of the log to check on the upgrade progress.

​

Once you see the following in the System Log:

Sangoma Linux 7 (Core) (x86_64)                                                                    

Kernel version 3.10.0-693.5.2.el7.x86_64 ip-172-31-17-118                                          

login:                                                                                             

 

You are ready to reconnect via SSH and proceed with Phase 2 by running the following command:

​

smartupgrade v3-inplace-upgrade-phase2

​

Phase 2 is entirely automated and the server will automatically reboot when it is finished (the SSH console will disconnect). This completes the upgrade process. Once the server has rebooted, you may log into the GUI and confirm that all of your configuration is intact. You server should be fully Production-ready again. 

​

Note: If you see messages on the GUI Dashboard reporting Unsigned Modules, don't panic! The module verification system can take a few minutes to finish running after the final reboot. The Unsigned Modules warning should automatically disappear soon after the final reboot, once all modules have been scanned.

​

​

​

​

If you have any questions about either of the methods mentioned above, don't hesitate to contact our friendly Support Personnel and we'll be glad to help!

​

NOTE: You are under no obligation to upgrade from your existing v2.x instances. We will continue to publish updates and security patches for the 2.x version track into the foreseeable future.

​

WARNING: DO NOT ATTEMPT TO RESTORE FREEPBX 13 (AMI v2.x) BACKUP FILES TO FREEPBX 14 (AMI v3.x) WITH THE BACKUP/RESTORE MODULE! THIS WILL PERMANENTLY CRASH THE WEB INTERFACE AND SCRAMBLE THE CONFIGURATION DATABASES OF THE FREEPBX 14 INSTANCE!

​

​

PRIVACY WARNING: Clicking the "Launch an Instance" button on this page will expose your personal information to Amazon Web Services (AWS) and their affiliates for the purposes of processing your subscription. Click here to view our Total Privacy Policy.