Alfresco Enterprise edition is in version 5.x right now. The first version 5.x was released in December 2014, almost two years back, but still, most Alfresco Enterprise users are using versions 4.x or even 3.x. This is especially true for those enterprises who have a heavily customized Alfresco Enterprise instance. They tend to push off the upgrade until they are sure that it is critically needed and no workaround is available. Even a thorough analysis of what the impact of upgrade would do end-to-end on an enterprise-grade deployment would take a long time. Now add to fact that update would require changes in ancillary areas like integrations, business processes, training etc and we get a considerable delay in updating of the solution.
This post is for those who are thinking about updating their Alfresco solution to latest versions. In one of our recent engagements, we came across a similar situation where the client had an Alfresco Enterprise 3.X based solution and need to update the solution to Alfresco Enterprise 5.x version. We are going to use this example throughout the post.
The client was using Alfresco ECM Enterprise Edition version 3.3.1 as a backend repository for all user created as well as dynamically created content. The content was of a varied type, including videos, audios, images, documents, etc. The ECM was integrated with SugarCRM which was used as a frontend for all business processes. In addition, they were using MySQL 5.0.95 as the backend database, Apache Tomcat 5.5.23 as Application Server and Web Container. The current server machine was using RedHat Enterprise Edition 5.11 (Tikanga) as the operating system.
The Updating Process
The Alfresco ECM Enterprise version 3.3.1 can not be upgraded to Alfresco ECM Enterprise version 5.x directly. The standard procedure is to update Alfresco 3.x version to Alfresco 4.x version first and then Alfresco 5.x version. In addition, an Alfresco solution uses multiple supporting software like MySQL, LDAP, Tomcat, etc., that have to updated separately as well. Therefore each upgrade requires a subsequent upgrade of ancillary software first then only we can proceed with the update of Alfresco instance itself.
|RedHat Enterprise Edition 5.11 (Tikanga)
|Red Hat Enterprise Linux 6.4 x64 or above or Ubuntu 12.04 LTS x64 or above
|Apache Tomcat 5.5.23
|Apache Tomcat 7.0.X
|OpenLDAP – 2.3.43
|JDK – 1.6.0_24 – 64 bit
|JDK 7.0 uX
|ImageMagick – 6.4.2
To be more technical, here is the current technology stack compared with a necessary technology stack that is required for smooth functioning of Alfresco Enterprise 4.x and above.
For more details on Software package checklists, check out the link here.
Also, we won’t be going to go very technically deep into exact steps on how to upgrade
the Alfresco version. To know more about it, you can check out this link.
There are three possible approaches, which we can use to upgrade the current Alfresco Enterprise version 3.3.1:
- 1. In-place Upgrade
- 2. Upgrade using a Separate Infrastructure
- 3. Upgrade using a Cloud infrastructure like AWS
In place, upgrade means upgrading the whole solution step by step on the same machine itself. Or to be more precise, updating each ancillary software then and there without moving or migrating
data. Here is the risks associated with such a process, best ways to avoid them, and what other things that you may have to keep in mind when updating the solution.
- The Operating System itself need to be upgraded. Though we can upgrade it, but whenever Operating System need to be upgraded the best approach is to start from a clean machine. The main reason is simple, Old OS may have an old version of dependent libraries which does not always get cleaned up when the in-place upgrade is done leading to bloating of software, unnecessary wastage of storage space, and opening to potential security risks. In addition, the old packages may conflict with new packages installed as part of the upgrade.
- MySQL needs to be upgraded from 5.0.95 to 5.5 or 5.6. There are major changes between 5.0 and 5.5 releases. For example, in 5.0.x versions, for creating tables to use INNODB, we used to use TYPE, which has now been replaced in new versions with ENGINE. So if you try to run an old version of Alfresco Enterprise, like 2.x or 3.x using MySQL 5.5/5.6, even creating tables will be impossible and Alfresco would not even start in the first place. In addition, such updated have a strong possibility of data corruption and data losses.
- The component on which alfresco depends for content related services such as ImageMagick, SWFtools, LibreOffice etc., also is dependent on system libraries.
- OpenLDAP is also depended on System Libraries. Therefore updating OpenLDAP is
dependent on the version of other software as well.
In short, this is the way that has the most probabilities of something going wrong. It requires comparatively fewer efforts, though. But considering potential downsides, we don’t recommend going with this way.
Upgrade Using Separate Infrastructure
Another way is to create a completely separate instance, developing and deploying an upgraded
version of Alfresco solution, and then migrating the data to the new solution.
Here are some considerations when we update the solution through this way.
1. Operating System
The Ideal operating system is always Linux/Unix based ones like Red Hat Enterprise or Ubuntu, but we can always use Windows OS as well. For Linux/Unix systems, the operating system’s edition should be equivalent or above Red Hat Enterprise Linux 6.4 x64, and Ubuntu 12.04 LTS x64. If we are using Ubuntu 12.04 LTS x64, we would have to go with MySQL 5.5 only as MySQL 5.6 would give problems. Also as Ubuntu 12.04 LTS x64 would soon become outdated with no long term support, we suggest using a newer version of Ubuntu 14.04.5 LTS or above.
2. Application Server
As per alfresco documentations, minimum Tomcat and JDK versions should be Apache Tomcat 7.0.X and JDK 7uX.
3. New Server Considerations
As we are going to change the server, we would have to change all related configurations in Alfresco, APIs, and all integrated solutions like:
- Register new Alfresco to CAS instance
- Apache HTTP configurations
- Configure image tools (like usps.photoassist.com we used in this example)
- Configure API connections and integrations at 3rd party software (like SugarCRM used in this example)
4. Cost Considerations
There is a one-time cost consideration for maintaining two servers, old and new. After we have migrated to the new server, we can stop using the old server (after taking appropriate backups of course). But in between cost overheads can be large for enterprise-grade solutions that maintain high-cost servers or self-hosted servers. Also for upgrading solutions that involve multiple servers, we may have to figure out most efficient step by step upgrade plan to make sure we get minimum downtime and minimum costs.
Upgrade Using Cloud Infrastructure
Cloud infrastructure have come a long way. They have proven to be dependable, scalable, flexible, secure, and most importantly cost effective especially for enterprise grade solutions. For this example we were using Amazon Web Services are preferred cloud infrastructure provider. The basic premise is similar to the previous method. To upgrade we will create a separate server instance on AWS infrastructure and then migrate all data from old instances to the new infrastructure. Here are the consideration to keep in mind.
- Operating Systems is same as the previous approach. We can go with Red Hat Enterprise Linux 6.4 x64 or Ubuntu 14.04.x LTS x64 or above as preferred. The only difference is that we may have to use AWS RHEL 6.4 as Amazon Machine Images (AMI) for all instance type across all regions. Also, Amazon Premium Support or Red Hat Global Support may incur extra costs.
- As Alfresco stores Files in File System then sizable Elastic Block Storage need to be configured with AWS EC2 Instance.
- With AWS infrastructure, standard practice is to use separate rDS (AWS Relational Database Services) instance which can then be configured as MySQL 5.6 server.
- Problems may arise related to OpenLDAP, SSO, and Tomcat. Usually, other solutions also share these resources so you may either have to migrate the whole solution to AWS infrastructure and reconfigure all resource using software or leave them where they are and bear separate costs for running them at separate locations. For large solutions, this becomes a management and logistics challenge. In our example, this software was shared with some 3rd party solutions, therefore, we used separate servers for this software.
- Choosing the right AWS instance may also require some research. For this example, we went with an m4.2xlarge instance with 1TB storage but this can be changed to a better or lower instance type as per requirement and at any time. That’s what cloud infrastructure all about.
- Securing AWS instance is an entirely different process. A lot of research and small configurations are required to make the AWS instance secure.