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:
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.