One of the benefits of the Compiere environment is that migration to an upgraded or latest version is a relatively seamless and safe process.
Migration is the process of moving from one version of Compiere to another version (usually the latest version). This move involves the data and application dictionary definitions, as well as the source code. In other words, it's moving from Compiere 3.1 to 3.6 or interim releases such as 3.61. What this means is that Compiere Inc. maintains and generally supports only the latest version of Compiere. The requirement is that the older versions have to migrate to the latest version for up-to-date support.
Due to the experiences of many traditional systems, there may be consensus of Don't touch the system once it is working. This response is due either to the fear of losing customizations or extensions or to the cost of re-writing customizations, and sadly many professional consultants would even advise against any changes to packaged software whatsoever (the boxed-in approach). As we know, because Compiere is open source, an enhancement or customization is not a self-inflicted injury and actually the more often you migrate, the more seamless the experience becomes. However, it must be added that in real life, if the migration does fail, it is purely the technical development team that did not know what they were doing and need to skill up.
The automated aspect of the migration involves the transformation of the underlying database tables, columns, IDs, and foreign keys to the next version. The process of migration is described in the Release Notes of each version of Compiere. Behind the scenes, the process can be described as follows:
The non-automated aspect of the migration is transforming the source code from the current to the latest version, using the new version of the source code as a reference:
The migration process does not affect tenant data—it is the transformation of the underlying data structures into the latest version, and is rarely impacted. In some instances where the data is impacted, this transformation would be to accommodate more functionality, and thus the data will be transformed by the migration process, with full logs that describe the impacted aspects being created.
Since the AD changes are impacted during the migration, it is important that AD changes are managed accordingly.
Dictionary versus User Maintained entity types: This relates to any non Compiere AD change, which will automatically be assigned a User Maintained entity type:
When changing data within the AD, make sure that you assign them in the Change Audit menu item as a Customization change which will ensure that, as part of the migration, these custom changes can be identified and applied:
After the migration has completed, use the Reapply Customizations menu process in the System Administrator role:
Also, make sure that Roles are set to manual, otherwise these will be overridden during migration:
It is strongly advised to migrate at least once or twice per year. This ensures the stability and technical and functional growth of the product for the end user, and minimizes the risk of the migration becoming a huge project, when it should be a seamless process. Thus, there are certain aspects that can be managed in order to ensure that the migration remains seamless:
- Backup Strategy: Ensure that the appropriate backup strategy is followed and tested.
- Timing of Migration: As mentioned previously, at least annual migration is advised. During an extended implementation project it is advised to migrate as regularly as possible This is to ensure that not only are the benefits of a later release enjoyed, but also that future migrations are going to be easy and that the rules have been followed.
- Minimize and don't change the Compiere source code: Through Java source code structuring and modeling, it is highly recommended that no direct changes to Compiere source base be made and that all code changes are made in overriding classes or custom call-outs. Compiere also allows for Component registration so as to ensure the uniqueness of applicable component entity IDs within the market place.
- Functional migration: Make sure to read the version's accompanying release notes for details of changes made and bugs corrected, and evaluate the impact on existing business processes. If a new module is implemented, then user training should be made within the organization's normal change management processes.
- Database migration: Follow up on the migration logs meticulously, and resolve items during a test migration. The test process is repeatable, and logs are very descriptive:
