I doubt that anyone is asking Santa Claus for a CTRM system upgrade this Christmas, yet many companies will find they are in the inevitable position of having to take on a project and spend money to upgrade their Allegro CTRM system to the latest Horizon version in 2022. Given that Santa is unlikely to drop the upgrade off underneath the Christmas tree, the initial question most companies have about their CTRM upgrade is, “How much should my upgrade cost?”

Upgrading a CTRM solution can vary from a minor project to a major initiative with a cost variance of 600% or more. It can be challenging to know where your Allegro Horizon upgrade is on that scale and plan appropriately. The following are some of the initial key considerations that we use to provide our clients with direction and guidance for the price of an upgrade.

What is driving the upgrade?

Understanding the effort associated with the upgrade starts with having a clear understanding of the desired benefit. Many upgrades are driven by the need to ensure efficient license costs and supportability for re-code from ION; these initiatives do not make to functionality. Other initiatives seek the same supportability and want to further stabilize and secure their CTRM system by moving to the cloud. Others are looking to maximize the benefits of their Allegro system, taking advantage of increased core system functionality, thus reducing existing custom extensions. The most complex initiatives are those that seek to incorporate new capabilities and functionality as part of the project.

Clarity on the overall goals of the upgrade will help define the approach, effort, and budget for the upgrade. It will also serve as a clear north star and guiding post for the project while conducting the upgrade. 

What are the applicable changes?

Changes to your Allegro instance can be driven by your organization’s desire for new functionality or by the inherent changes associated with the upgrade. Understanding the degree of change is crucial to determining the cost of the initiative. Determining the degree of change requires both an in-depth knowledge of the different versions of Allegro, and specific knowledge of your current instance and desired functionality.  

Your class events need to be analyzed to determine the level of remediation needed for the class events to function properly in the upgraded environment. This includes consideration for the purpose of the class event and the identification of class events that can be eliminated by leveraging new core functionality in the upgraded version. Detailed understanding of new Allegro functionality, as well as industry knowledge, drives success in this analysis.

It is important to understand the changes as well as the implications of the upgrade. For example, multiple valuation modes were added between Allegro Horizon .134 and Horizon .145 which means separate settlement and credit valuations. While this is a major change in functionality it tends to be a minor effort to address the change during the upgrade. Conversely, exchange transactions and ExchangeConnect were also reworked around the same time. While the functionality is straightforward, the configuration and in some cases extension to make financial trade capture work well requires some effort including considerations around potential data enrichment for existing trades and with exchange testing.

Lastly, infrastructure changes need to be baked into the change analysis. Ultimately, hosting on cloud infrastructure significantly reduces the time needed to stand up environments for testing, disaster recovery, etc. However, the initial move to the cloud takes time in the form of planning, architecting, and training. These considerations need to be part of the upfront cost analysis.

What is your upgrade approach?

The approach taken to perform the upgrade will also impact the cost of the initiative. There are two major approaches to performing an upgrade to Allegro to Horizon. The first approach is to install the new version of Allegro and then migrate your data in your existing Allegro system to the new version of Allegro. One advantage to this approach is that your baseline is an out-of-the-box instance of Allegro, without any customization. 

This facilitates the understanding and usage of the Allegro system without undue complexity. A second advantage to this approach is that it allows the business to leave behind large volumes of legacy data that can slow down the overall performance of the system. They can also leverage the opportunity to move to a “clean house” and undergo reference data analysis to only bring in clean reference data to the new system.

The second approach is to convert your existing Allegro database to the new version of Allegro, and then remediate the issues in your visual module and class events to use the new database. One major advantage of this approach is that it eliminates the tedious analysis of identifying what data to migrate and how to fit the data into the new database. 

Secondly, this approach brings all your customized functionality to the new systems, thus avoiding losing functionality that your users are dependent upon. Lastly, the approach provides all historical data in one place with one model of the data.

Choosing the approach is not an independent or arbitrary decision. Identifying the appropriate approach for each upgrade is part of the pre-upgrade analysis and is based on multiple factors, including the customization and complexity of the existing Allegro system as well as the quality of historical data.  

The approach that you take will be a driver in the cost of the initiative as well as a driver in resources and the size of the team. The first approach places a great deal of responsibility on the owners of the data, which could have implications as the owners of the data have day-to-day operational responsibilities. The second approach places a great deal of responsibility on technically capable resources with strong Allegro knowledge of both the legacy version and the new Horizon version.

How many groups are involved?

The question, “How many Allegro users do you have?", is an important question but a more important one is, “How many user groups are involved with the upgrade?” The list of Allegro users alone does not represent the indirect impact of the upgrade. System interfaces and recipients of reports, present added complexity even though they are not named Allegro users. Data change implications and the effort required to involve groups outside of the core Allegro user community should be considered carefully. In some cases, the data is changing because of underlying data table/structure differences between the previous version and the upgraded version. In other cases, changes to business functionality and capabilities may be the catalyst for changes to the interface or reports.

Typically, the upgrade is easily manageable within the immediate Allegro user groups because they are beneficiaries of the benefits of the upgrade, or their daily operations are dependent on having a maintainable, efficient Allegro system. More effort is often needed for ancillary groups as the upgrade could mean change and required effort without the benefits of something new.  

The second example of an upgrade impacting ancillary groups is upgrades that include going from on-premise infrastructure to cloud infrastructure when upgrading from Allegro 8 to Allegro Horizon. As discussed, a move to the cloud can be highly beneficial and needs to be considered as part of the change analysis. A change in infrastructure also needs careful consideration from the perspective of the level of involvement needed from ancillary groups, like the security and cloud administration personnel, which may not be readily available in-house.

What is your approach to testing?

Testing is a multiplicative factor on effort for upgrade projects as well as the single biggest driver of the quality of your upgraded system. The amount of testing effort is related to the amount of change. Often people use the baseline effort required for the upgrade as an indicator of the amount of change. The more things change the more effort for the upgrade and the more effort required to test those changes. 

However, the total effort associated with testing depends largely on factors within your specific organization. One of the biggest factors around testing approach is balancing the conflict between user time and user comfort with the upgraded instance. There is a minimum amount of testing that should be performed as part of an upgrade but there is also a large variable portion of time for testing. The user acceptance testing (UAT) approach, including who is involved and the scope of the testing, is a major variable. There are benefits to heavy user involvement in UAT and end-to-end scenarios. 

Sometimes a lighter UAT is preferred with greater emphasis put on the project team testing and the use of some super-users within the business versus UAT with all users. Parallel testing is another lever that can be considered if the business is willing to dedicate the time necessary to get more comfortable with the new solution.

Testing is a major driver to the level of effort for an upgrade to the point that we will talk more about how the different aspects of testing impact the cost of a project in a subsequent blog.

What is next?

Executives often have data points from industry peers on the cost of an Allegro upgrade. One of the most frequently asked questions is why there is so much variance in the cost for one organization’s upgrade versus another. 

Answering the above questions provides the foundation for cost analysis that helps explain the huge cost variations to your executives.  

The next step is a more detailed analysis. From our wide range of experiences with performing Allegro upgrades of all sizes at Veritas, we have built a list of considerations to think through the cost of the upgrade. After working through these key considerations, we then perform a rapid analysis of the existing Allegro system. The rapid analysis entails the completion of a detailed matrix of the drivers of upgrades costs allowing us to further refine the cost estimate before the effort begins.  

This rapid analysis, in turn, answers the second most frequently asked questions from executives, “Is the estimated project cost accurate? What is the risk of it being more? Do we have a contingency for the unexpected?” With our systematic approach to estimating the upgrade costs we not only streamline the analysis process, but we also consistently deliver Allegro Horizon upgrade projects within planned budgets and timelines.  

At Veritas Total Solutions, we are experts in CTRM Systems and believe our combination of business-minded consultants and technical experts make us uniquely positioned to help clients through all stages of the CTRM journey including initial discovery, rapid analysis, and estimating costs. If you are interested in learning more about our specific capabilities, contract us to learn more or subscribe to our blog to stay connected.