How to Successfully Migrate reports from Murex MX2.1 and Murex MX3.1
In the previous blog, we discussed Data Migration, System Integration and Quality Assurance for a successful migration. In this blog, I’ll cover real world example of a successful trade system migration, focusing Reports Migration.
Report migration mainly involves re-creating reports in the proposed new trading system and compare them against the report generated from the existing system. The reports have to compared and checked for overall format, structure, data precision and data integrity. The focus is not on the amount of data a particular report holds; the concern is more about the representative data from the old and new systems.
My team helped a large bank migrate from MX2.1 to MX3.1, including end-to-end trade lifecycle, new products and pricing methodologies. Mindtree had earlier helped the bank migrate from Mreport to Datamart in MX2.11 as well as in Lean Murex project to streamline MX2.11 objects, which was carried out in preparation for migration from MX2.11 to MX3.1 as a clean and optimized MX2.11 will enable seamless migration to MX3.1.
The bank was finding it constraining to design and implement new trade structures/ payoffs. Higher trade volumes were causing significant impact in meeting well established SLAs. Our team first analyzed MX2.11 components and evaluated migration impacts. We then created the migration strategy and migrated 4000 reports from five different sub systems successfully.
The category of reports involved all kind of EOD/Intraday reports including Mreports, DM, PL-VaR, VaR, Risk, Simulation, Accounting, Hedge, Collateral, Trade query and related objects, PL/Trade notepads etc. We designed reports to improve performance and migrated all the MxML Interfaces and workflows from MX2.11 to MX3.1. The team managed the migration end-to-end – from analysis, design, and development to SIT, UAT, DR testing and go-live.
Best migration practices and automation was effectively used to speed-up adoption. We cleaned-up unused objects to enhance performance. Recon differences were recorded for tagging of issues during UATs. The automation testing framework was delivered to help the technology team to gradually bring down the build time and cut down turnaround for regression testing cycles.
Below are some of the factors that make report migration stream complex:
- Data model (table representation of trade, static data, financial data and everything else) of existing system and new system may not match entirely; it may warrant thorough analysis of the whole set of reports.
- Changes/enhancements around the treatment of products in the new system might introduce addition/deletion of data records during the data migration process.
- Determination of exact root cause for any differences found during data comparison need to be validated with the system vendor (to be cross-verified against a list of these type of issues already identified by the vendor)
The above exercise is repeated for every report in question; and in case of big banks where the total number of reports to be migrated runs to more than 1500 to 2000, the total effort to deliver this migration would be considerably high.
As the number of reports in the system to be validated/reconciled/approved by business becomes bigger, planning, execution and management of the reporting stream would take critical focus as it would have the potential to affect the testing and go-live date.
From the details that we have discussed in these three blogs, it is evident that the most important and critical stream post identification of a particular vendor product would be the Data Migration and Report Migration streams. If these streams are well managed, migration is guaranteed to be on time and business can reap the benefits of the new product from day one.