Tag Archives: version

Info

Version releases, upgrades and all that jazz

Murex release policy is actually quite simple:

Major versions : 3.1.x are released once/twice a year. They contain new developments, data model changes, etc…

Minor versions: 3.1.99.x are released much more frequently. They do not contain new developments or data model changes only bug fixes.

The idea behind is that minor versions can be quickly deployed or even put in a separate launcher running in production in order to address issues. There is usually no problem having 2 different minor versions pointing to the same database and being in used at the same time. But as always, check with your Murex consultant if it is all good.

Major versions are a bit more work and contains more novelties. Frequent upgrades to major versions is strongly recommended so that the gap between production version and latest Murex version remains small. It translates into a shorter turnaround between official release and production.

The other healthy habit is to have a test environment running a build version. Of course, no one can use a build version to use in production but it can be useful to test new features and work with endusers. Endusers only really care about the version that they have in production. So the focus on time to market is quite important.
Let’s take for example the need from an enduser for a new development. First steps consist in clarifying the requirements and getting clean specs. Then one needs to liaise with Murex to get a projected timeframe. It is usually best to get commitment as to which version the development will be available. Testing on the build prior to the release is highly recommended in case something is not right, not as expected as the timeframe between 2 major releases is actually quite long.
Once the development is all good and the official release received, then the non regression testing starts and finally deployment to production.

End to end, this can mean 18 months, so it is important to nail it the first time and ensure that there is no extra delay. Also, back what was said above, if endusers can see a test version with the development, it brings them confidence that they haven’t been forgotten and things are moving their way.

 

Experiences, comments? Feel free to share!

Info

Upgrading from 2.11 to 3.1

I often see posts about migration from 2.11 to 3.1, how difficult it is, what are the real benefits. So I’d thought a quick post here to demystify it might be worth it.

First of all, Murex is the best source of truth (as usual) for the migration and the more time passes, the easier the migration itself is as more and more cases are documented.

2.11 is the previous version of the Murex software. It has reached its end of life and new features are not developed onto it anymore.  All customers are strongly encouraged to move to 3.1.

3.1 is the newest version developed by Murex. Its main advantages over 2.11:

– Better workflows and better consistency of these workflows across the board. There are 3 workflows during a transaction life: pretrade workflow (which gets triggered while pricing), booking sequence (triggered when the trade is being booked) and post trade workflow (triggered after the deal is booked)

– Different consolidation process and Livebook as a new functionality

– Stronger rate curves framework/functionalities

– More models for pricing or volatility interpolation

– Better user management

– Improved pricing structure build

– Loads of smaller changes and bug fixes

For a migration to keep as identical, the main efforts of the migration will reside around workflows and working with Murex and their predefined templates. This is a great opportunity to revise the workflows but also a significant amount of work.

The trades then needs to be reconciled as 2.11 can sometimes return an incorrect valuation for specific trades  (I’m looking at you Buy/Sellbacks).

End of day will need to be revised, reports (extracts) can work from 2.11 but you might want to move them to datamart at some stage.

All in all, it is a migration but which is very streamlined and for which most issues have already been handled by Murex previously. If you have a pure front office implementation of Murex, the migration will be much quicker than if you have processing workflows involved.

More questions? Forum or comments below!