Customization – Upgradeability

In one of my previous posts “Customization – Do you fit in the box?” I touched upon an important aspect when deciding to customize a software platform (same principles apply whether it is a PLM platform or for instance a CRM platform).



How will my customization impact the upgradeability of the platform?

The reason why this becomes very important becomes obvious when you want to upgrade the platform from an old release to a newer release. Most companies skip one or two releases in each release cycle from the vendor before upgrading, and that makes it all the more important to perform an upgrade analysis beforehand.

If no customization is made it becomes an analysis of:

•  What does our current data model look like, and what will it look like after the upgrade
• What does our data look like, and how will the modifications from the vendor impact our data set.

If customizations have been made the analysis becomes a bit more complex:

• What did the original data model of the software platform look like
•  What does our current and customized data model look like?

•  What will the data model look like after the upgrade?

• Are there any conflicts between our current customized data model and how the data model will look like after the upgrade?
• Should some of our customizations be removed since the new release covers some of our customizations?
• What does our data look like, and how will our customizations and the modifications from the vendor impact our new data set?

In my view there are a few rules that should be followed to avoid too many problems with upgrades.

• Try as much as possible to avoid changing the OOTB (Out Of The Box) data model itself, it is usually a lot safer to add to the OOTB data model and GUI.
• Avoid to make changes in the OOTB business logic itself. If you have to make changes, then override the OOTB logic and create your own separately, BUT make sure to document such overrides so that you can switch back to OOTB. Remember that if you change the business logic directly, chances are those modifications will be overwritten by an upgrade.

• If you decide to make your own data model completely customized with GUI and Business logic you are generally safe from an upgrade point of view, but you then stand the risk of not being able to benefit from the software vendors new releases of the platform in the future if they have decided to incorporate the same kind of functionality in the OOTB platform. In such cases you will be faced with a migration project, not an upgrade….

• One of the things that always cause a hassle when upgrading is changes to the user interface (GUI). I would offer the same advice here. Do not change the original user interface! Make a copy instead, implement the changes and override the original. This is because if you change the original, your modifications will probably be overwritten during an upgrade. In addition when performing an upgrade analysis you’ll have to perform a three way comparison between the old OOTB, your customizations and the new OOTB to reveal the consequence of the changes.

• If the software platform comes with a framework that rapidly enables you to build a user interface, data model and associate business logic, this is often preferable, BUT make sure to always analyze what new functionality is provided in the new release. Can you remove some of your older customizations? If you have overridden or hidden the old OOTB user interface, you will not be able to see the new juicy stuff that came as a result of an upgrade.

• Never upgrade the production environment without having tested extensively in a sandbox first (a copy of the production environment). Not even the best upgrade analysis in the world will find all issues or problems when performing an upgrade

Conclusion:
When dealing with software platforms you should always perform an upgrade analysis to determine how the upgrade will impact your installation. In my view, this should be done even if you have gone strictly OOTB. Such an analysis can help you weed out the worst of the problems, and should serve as a decision point for the upgrade project. Test your upgrade and procedures in a sandbox environment extensively first before upgrading the production environment.

Some points to ponder
Bjorn Fidjeland

The image used in this post is by Dirk Ercken and purchased at dreamstime.com