Options for Standard Books version change with customisations

Problem Statement

Updating the Standard Books version regularly is essential to ensuring that the product remains competitive, secure, and aligned with the latest industry standards. Excellent releases new Standard Books versions at least twice a year, and customers must update to the latest version no later than three months after it is released. Regular updates help incorporate new features, fix bugs, and improve overall performance. However, the need for frequent updates also presents challenges, especially when customizations are involved.

Need for Regular Updates

Security Enhancements: Frequent updates help in addressing vulnerabilities and ensuring that the product is secure against potential threats.
Feature Improvements: Regular updates allow for the introduction of new features that can enhance user experience and meet evolving customer needs.
Compliance: Keeping the software up-to-date ensures compliance with industry regulations and standards, which can change frequently.
Performance Optimization: Updates often include performance improvements that can lead to a more efficient and faster product.

Challenges of Customizations

Compatibility Issues: Customizations may not always be compatible with the latest version of the Standard Books, leading to potential functionality issues.
Increased Testing Requirements: Each update requires thorough testing of customizations to ensure they work as intended, which can be time-consuming and resource-intensive.
Resource Allocation: Maintaining customizations requires dedicated resources, which can strain teams and divert attention from other critical projects.
Documentation and Knowledge Transfer: Customizations often require detailed documentation and knowledge transfer, which can be challenging if team members change or if the original developers are unavailable.

In conclusion, while updating the Standard Books version regularly is crucial for maintaining a robust product, the presence of customizations introduces complexities that need to be managed effectively.

Possible approaches to update process

While Excellent provides a free-of-charge test environment for two weeks after each new version release, performing the HAL code update to the new version and testing the functionality is chargeable consulting work delivered by Burti. Here are the available approaches and the associated risks for the update

Approach description	Risks and benefits

Approach description	Risks and benefits
Full HAL code transfer and testing on a test server:	Includes: full HAL code check against the latest standard code including window definitions removal of any temporary fixes that might have been applied while waiting for a fix in the standard code deployment on a test server full testing of the agreed critical acceptance tests which should include all the customisations deployment on live server The best option ensuring all customisations are aligned with the newest standard code and working as originally intended Reduces risk of server or client crashes or clashes with standard functionality to minimum When done regularly no technical debt is accumulated and costs for each version change are predictable It can be quite expensive, especially with large amounts of customisation
Partial HAL code transfer and testing on a test server:	Includes partial HAL code checking excluding customisations that have a low risk of conflict with standard code e.g. window and interface changes, totally custom functionality etc. deployment on a test server full testing of the agreed critical acceptance tests which should include all the customisations deployment on live server Cheaper in terms of developer time required Minimizes risks of server or client crashes or clashes with standard functionality Standard product improvement might not be available in cases when they require interface changes that are effectively overwritten with your customisation Over time technical debt is accumulated and with each time next full HAL code transfer can become more expensive
No HAL code transfer and testing on a test server:	Includes no HAL code checking is performed assuming there will be no clashes with the standard code deployment on a test server partial testing of the agreed critical acceptance tests which should include all the customisations deployment on live server Cheaper in terms of consulting hours required Standard product improvements might not be available in cases when they require interface changes that are effectively overwritten with your customisation High risk of unexpected clashes between the customised and standard code that can cause server crashes and even data corruptions that can cost many downtime and consulting hours after go live
No HAL code transfer and testing on a live server:	Includes partial testing of the agreed critical acceptance tests which should include all the customisations Fast and cheap Requires longer downtime of the live system which can be an issue if downtimes during business hours are expensive for the business Standard product improvements might not be available in cases when they require interface changes that are effectively overwritten with your customisation Very high risk of unexpected issues of any sort and thus unpredictable and high consulting and downtime costs to find and solve them after go-live