With the recent release of Alfresco 6, many clients are beginning to plan to upgrade to the latest version of Alfresco in the coming months. TSG has been assisting clients with upgrades for years, we have developed several best practices to make the process successful.
When performing an upgrade, organization and planning are essential. While smaller upgrades are often easy, many clients are reluctant to upgrade until they absolutely have to. Those of us who have performed an Alfresco upgrade know that there’s a lot more involved than just running an executable to install patches. For heavily customized systems, upgrading Alfresco can be a lengthy process requiring time for planning and testing.
1. Before you upgrade, consider a migration to the cloud
Alfresco was built with a focus on cloud native infrastructure. We find most organizations view their their overall infrastructure strategies much differently than they did 5 years ago. With the continual move towards IaaS and Cloud first initiatives, an upgrade is often the perfect time to make the jump towards the cloud. All of the best practices in this post are still applicable, but a migration also provides a company with the ability to correct some of the assumptions that were made when the system was first implemented. Migrating content from the older install, into a fresh deployment of Alfresco in the cloud is a great way to adjust object models, clean-up folder structures and on-board new groups. Additionally, the new cloud instance can be deployed, configured and content migrated, without any disruption to the existing production environment. When the environment is ready, it can be promoted to Production status. Any content created during the small outage can be quickly migrated with a small delta migration or even rolling migration.
2. Take Inventory of Configurations and Customizations
Part of the Alfresco upgrade process is moving configurations and customizations from the old version of Alfresco to the new version. It’s important to take an inventory of all of the configurations and customizations in your Alfresco installation ahead of time. Most configurations can be easily ported into the new version of Alfresco, but if they haven’t been identified in advance, it’s just as easy to forget them. If your system has customizations, it’s important to verify that the customizations are compatible with the new version of Alfresco, and to recompile them against the new version of the Alfresco SDK.
A complete inventory of Alfresco configurations and customizations is also a great guide for helping determine what functionality needs to be tested after the upgrade is complete. From our experience with upgrades, out-of-the-box Alfresco functionality typically requires very little testing after an upgrade, but customizations should be thoroughly tested to ensure compatibility with the new version of Alfresco.
Don’t forget to hang on to your inventory of configurations and customizations because the list can help you kick start future Alfresco upgrades as well.
3. Validate Supported Stack
It’s really tempting to dive head first into an Alfresco upgrade, but it’s critical to first validate that the database, OS, browsers, etc. are supported with the new version of Alfresco before proceeding with the upgrade. It’s common for Alfresco to drop support for some components and add support for others, especially when major versions are released. It’s important to stay on a supported stack in order to ensure that Alfresco can provide support for any cases that you log via the support portal. A complete list of the Alfresco supported stacks can be found here. Note that significant changes to the supported stacks have come with the release of Alfresco 5.
4. Document the Process
Alfresco provides good documentation for performing upgrades, found here, but every upgrade is different. Some of the steps may be relevant for your environment, and others may not. Documenting the upgrade process as you perform it will not only help ensure that that all of the appropriate steps are taken in all environments (development, test, production, etc.), but it will also help future upgrades go more quickly. Since the process does not change much between versions, your documentation can likely be reused.
5. Test on a Clone of Production Data
Even if you have non-production Alfresco environments (development, test, etc.), we recommend performing an Alfresco upgrade on a clone of the production data prior to performing the actual production upgrade. From experience, we’ve seen successful upgrades in non-production environments still lead to issues when upgrading production. Because of differences in the type and amount of data in production, sometimes unforeseen errors can occur. For example for one client, upgrading Alfresco required a full re-index in Solr, and during the upgrade the system ran out of memory due to the amount of data in the production repository. The out of memory error was not encountered during the upgrade in the test environment because the amount of data in the test environment was only 5% of what was in production.
Testing on a clone of production data also has the benefit of giving you an idea of how long the production upgrade will take. If the upgrade runs more slowly than is acceptable for production, steps can be taken in advance to optimize the process (database tuning, more CPU/RAM, etc.).
6. Have a Backout Plan
No matter how much planning you do for an Alfresco upgrade, there’s always a possibility that things will not go as expected when upgrading a production environment. It’s important to have a plan in place for backing out the upgrade if things do not go well. If you’re working in a virtual environment, the quickest way to back out an upgrade is to create a snapshot of the VM, database, and content store before starting the upgrade, and reverting back to the snapshots if necessary.
Hopefully this list of tips is helpful in planning your upgrade to Alfresco 6. Please feel free to add comments below.