We speak to a good portion of Findur clients across a number of geographies, and one topic that comes up regularly is the right strategy to make an upgrade as simple as possible.
The baseline question comes down to: ‘like-for-like’ or stage several changes as part of the upgrade. In this post, we address the important priorities that we believe should be considered for inclusion within the scope of an upgrade.
Version Mainstream Support Timeline
Clients on Findur Version 14, depending on their location and specific contract, are likely no longer covered under the terms of mainstream support. It should go without saying that, barring some exceptional understanding and agreement from senior management, upgrade planning and execution should be top priority.
Not far behind that is Version 15 which, again, depending on specific contracts and regions, will no longer be covered under mainstream support beyond Q1 2020.
Openlink released Version 18 in November, and there are clients targeted for a February 2020 go-live. Generally speaking, and this makes sense for a system aggregator, clients should anticipate enforcement of upgrade policies that more strictly align to their contracts. Beyond the contract, on a general level, it is always better to be on a version that is used by a number of clients. Turnaround on bug fixes, greater product management attention and support to the version, shared issues, etc. are all likely to play a factor and, for a system that is so critical to your business, it is worth that level of investment, at a minimum.
Upgrade Strategy Recommendations
We typically recommend clients execute their upgrade with as few changes as possible, in a ‘like-for-like’ manner. A like-for-like upgrade means that Findur is upgraded to the new version, without introducing changes to the application, database, or infrastructure, whenever possible.
There are, however, reasons why it is a good idea to depart from a straight like-for-like upgrade. Any of these conditions may justify adding scope to the upgrade.
New Modules
- The vendor may have released a new module, or a new feature that is important for the business to pursue. If this is the case, it is typically advisable to clear the upgrade, and then implement the new module. And even if this is the case, clients should apply more rigor to this area. Just because they may choose to not implement the new module during the upgrade does not mean that there will not be bugs that impact current usage. Turnaround on bug fixes, irrespective of vendor, is always a significant drag on upgrade timelines.
- A special case of implementing a new module is extension of the application into new markets. There are many items to consider here as factors so please contact us for help. But one major factor is that you do not want to be in a situation where you have not tested the new functionality prior to go-live. If that is the case and there is a showstopper bug, you are looking at waiting on a bug fix and then doing another significant round of testing prior to being able to kick off the new project. This could be a whole other paper in itself! You need not have a commercial relationship with us to ask a questions so please reach out.
- Enterprise systems, on a whole, are not doing as much specialized work or new modules these days. However, there have been recent deprecation of modules, that have required clients to migrate to alternative solutions. The SWIFT Gateway and Reconciliation Manager are good examples, and both have been replaced by new functionality that should testing prioritized to minimize project delivery risk.
Partner software and hardware changes
- Over time, partner software such as Java and other products, requires upgrading. The supporting vendor will include scope as wide-ranging as security vulnerabilities, bug fixes and enhancements critical to your business. Frequently this is the biggest reason for client upgrades – yours should be no different and should very much include migration of any partner software that is required to be upgraded.
- Similarly, hardware changes, migration to a new version of MS SQL Server, and so on, are significant changes that can be risky. Depending on your other risk factors, it is likely a good idea to include these changes in the scope of the upgrade project to test functionality and/or performance with the new infrastructure.
Open production issues
- If there are open production issues, the upgrade test team may already be performing tests on the area of functionality that suffers from the problem in production. The upgrade is an excellent opportunity to make the change in the upgraded environment and to validate the functionality. Keep that list of issues handy! Tracking these minor details are part of what will help you and your business see the return on investment from this project.
- A special category of production issue is the vendor application’s bugs. The major version upgrade can be an opportunity to escalate a bug fix priority and have the fix checked into a maintenance release.
Retire customizations
- Sometimes it might have been necessary to implement customizations or workarounds during the initial implementation (or even during subsequent upgrades!). It is possible that the vendor has made a bug fix or an enhancement available that will allow a client to retire a customization and, by all means, retire your customizations. It’s the kind of work that is minor compared to the value you get back.
- We talk to a lot of clients about the virtue of removing customizations. Some organizations update operational processes to align more closely with market standards, which may enable the retirement of customizations. Prior to kicking off your upgrade may be a good time to evaluate processes that could be altered to implement more standard features and revert to core application functionality. Reverting to core almost always makes your upgrade easier and less complex.
- Every customization that is retired reduces the burden on the production support team; eases future roadmap enhancements such as product rollouts, reporting or system integration, and speeds up upgrades now and in the future.
Evaluate removal of unnecessary features
- The best example of unnecessary features is likely to be a report that includes ‘Test’ or ‘_old’ in its name. Many clients have hundreds of reports, particularly since version 10.2 when Report Builder made the creation of reports so much easier. Every report in the system must be tested during an upgrade, so each report that is removed will reduce the upgrade effort.
- Look at disabling any superfluous report in the short-term, and ultimately deleting the report. There are ways to easily export them for quick restoration if necessary – please reach out if you have questions as there is a bit more detail in that exercise than we can cover in this format.
- Review system activity for components that are not being used. Findur has features that track the execution of reports, Auto Match definitions, scripts, tasks, and more. Review the activity, interview users, and disable unnecessary components. If you are having trouble auditing system activity, let us know and we can help.
Evaluate planned enhancements
- Some organizations have a Findur instance that makes it difficult, time-consuming and costly to extend the application to support new instrument types, currencies, hedge programs, reports, and more. If your organization is one of these, then consider adding the new instrument type, or new feature to the set of test cases in the upgrade. The new test cases should be executed after completing any side-by-side testing. Users will be performing many manual tests anyway, so the additional effort taking place during the upgrade could require much less effort than it will post-upgrade.
Evaluate Findur database size
- Some clients have a production environment that is measured in terabytes. It takes them a long time to take a backup, clone the environment, and it is costly to store. Unnecessary data in the production environment may also slow down reports and other operations. Purging data is risky so it must be tested. An upgrade can be an opportunity to ensure that a purge operation has removed data that was not essential.
Evaluate system performance
- Version changes can sometimes introduce bugs that adversely affect performance, which must be reported to Openlink and fixed.
- The full system regression test is an opportunity to remove unnecessary features that might be a drag on system performance, such as unnecessary slow simulation results. For example, turn off the Impact of Cross Gamma Delta result, and confirm that there are no adverse effects.
