What does upgrading to 2.50 mean?

by Jorge Monfort
Senior Consultant at Global Partner Services

When you are facing an Openbravo ERP 2.40 to 2.50 upgrade project the first thing you need to consider is what the real purpose of this upgrade is and what your client's expectations are.

The upgrade process, in fact, entails converting core customization into modular extensions and the effort required to perform this task greatly depends on the degree of re-use that you want to achieve.

For most companies, who have customized 2.40 for their own usage and do not have an interest in sharing their extensions, the scope is limited to a straight technical upgrade. On the other hand, if the client wishes to obtain reusable modules that can be distributed through the Central Repository or sold through the Openbravo Exchange, more work is required.

At the extreme end of complexity, you will find the case where the client wants to achieve a complete and fully packaged and reusable vertical solution.

I recently worked on such an upgrade and I would like to share here some lessons learned in this project. Let's try to analyze these different scenarios and the impact of each one of them.

Case 1: Single company that just wants to upgrade to 2.50:
There are many reasons for upgrading to 2.50

• To take advantage of the new functionality included in the 2.50 version
• To leverage the easy maintainability experience of the modularity platform
• Due to the sunset of their current Openbravo ERP version

In this case, just an upgrade could mainly fulfill the expectations. The Openbravo ERP upgrader would create a single extra module including all customizations, and after some adaptations and manipulations we could enjoy a real 2.50 implementation, always taking into account that this module wouldn't accomplish the necessary naming rules required to be able to publish it in the Openbravo Central Repository or in the Exchange.

Apart from this first simple scenario we could think of enhancing it by re-factoring our big module into smaller ones to simplify its maintainability in production environments and reduce the effort of resolving future potential bugs or naming conflicts (reviewing and updating a small module will always be easier than having to create a new version of the whole big industry template module). It would involve creating new modules and moving some customizations from the original big module (mycustomization module) to these new modules.

Although we should always take into account the significant increase in effort required, it would also constitute a pre-step to future module reusability which will lead us to case 2.

Case 2: Client that expects to commercialize his customizations
In case our client considers that customizations implemented for them could have commercial relevance, or just thinks that it could be a chance to recoup their investment, we should take some specific actions in order to be able to publish them in the Openbravo Exchange.

• In this case, re-factoring into independent modules is a must. That means a higher investment but it is justified by a commercial return.
• Adjusting to Naming Rules would also be a must in order to guarantee that our modules are fully compatible with others published in Openbravo Exchange. This task also implies a big effort for renaming all our customizations.

So, notice that all this judgments need to be done and scope should be clearly defined before starting the project because it has a clear impact in the effort load calculation and in reaching the client's expectations.