In this article we explore the main steps involved in system data migrations in the Funds Administration industry. Some key elements in the process are outlined, from rationale, to team structure, testing, operating model, go-live and audit.
Why do a Data Migration Project
Fund Administration service providers use lots of different systems in their work of fund processing. These range from banking software, Fund Accounting, Shareholder services, AML-KYC verification applications, Investor Reporting, Fund compliance, NAV oversight, Regulatory reporting systems, Archive systems. Most such companies have a mix of systems developed in-house and vendor applications, interfacing internally and externally.
Data migration projects are not uncommon in the Funds Administration world. Some are one-to-one system migrations; others are many-to-many. The causes can be diverse, some drivers being internal to a company, others external.
One example is where a Fund Promoter has decided to move the Fund Administration mandate to another Administration provider, because of costs or service levels.
Another situation is where the Service Provider themselves decide to change from a legacy system to a strategic new platform, to accelerate digitization of their service offering and future proof their business model. If the old application is in-house, it may seem strange but there can be incomplete knowledge of everything it does. Properly querying the data behind is advisable in this case.
In the first case the incoming service provider must receive extracts of all the Client data from the systems of the outgoing provider and load it into their own systems. This is an easier project to sell internally and get resources as its new business, rather than the internal strategic upgrade situation.
Either way, for the administration company these types of projects must be carefully planned, accurately and fully carried out, properly documented and tied up flawlessly. The underlying investors being serviced should not even notice that the processing system running in the background has changed. Service levels must be maintained throughout the project.
In the case of new business take-on there will be many discussions with the client/fund promoter to learn how their fund data should be maintained in systems, understand exactly how their business is structured, get to know their investor profiles, amongst other topics. Of course, with any data migration initiative there is always lots of testing.
Team Structure
Data migration teams are composed of project managers, IT specialists, project officers, and business analysts with significant sectorial business experience. There may also be developers for new functionality or creating reports to cover any gaps identified during the gap-analysis study between system A and system B. External contractors with relevant business, testing and migration expertise are also particularly useful. They will come under the project budget and only stay for 6-12 months, depending on needs.
If there are waves of change, of migrations of data, of testing milestones and production releases, an Agile team structure could work, but Waterfall organization in system migrations still exist and can function well if there is a big bang approach, a single cutover date to turn off the old system and start with the new system. Different companies will have their own methodology preferences.
Project Steps
A safe way to start can be to create a project charter, explaining the concept behind the change, define the scope of the project from both business and technology viewpoints, name key stakeholders, state the testing needs, and give overall estimated timelines.
For resourcing the question of a temporary project team comes to the fore. The BAU (Business as Usual) teams have their regular work and must hit their deadlines, so they cannot be expected to also do the system changes and testing at the same time.
The projects are quite complicated, with many moving parts to consider. There are legal aspects, where one needs to keep the CSSF informed of the administration changes, there is the complication of maintaining fund and investor processing to a high standard, while at the same time implementing the changes.
The project is split into different workstreams, such as system infrastructure, static data setup, new functionality, access rights, data migration, data feeds both internal and external, new workflows, user training on new software and Operational readiness.
Target Operating Module
In the new business situation previously mentioned it is also time for the client and service provider to agree what the target operating model should be, whether processing will be straightforward, or if there are any unusual business needs to cater for. For TA business one aims to have a high STP rate (Straight through processing) of 90% or more for processing investor trades via SWIFT or SFTP, instead of emails or manual input. Processing flows are managed via static data setup, system rules and interfaces needs. This all needs to be tested, both by IT teams regarding data interfaces and their triggers, and realistic business scenarios to ensure the application behaves as expected and that outputs are correct.
Migration Strategy
Parallel Runs between old and new systems are often organized to give users and management a sufficient level of comfort that the new application will at the very least carry out existing tasks in a risk-free manner, but they are labour intensive. One can compare data processing times and check that both systems produce the same figures.
For big-bang change-over date scenarios, dry-run migrations are carried out beforehand on test environments to ensure detailed migration timelines are known and each person can perform their role as and when expected to do so, according to a defined runbook.
Go-Live / Migration Cross over
Go-live migrations are done over the weekend. From Friday one backs up data from the old system. On Saturday morning all the data is transformed and loaded into the target systems, and sanity checks are done by business testers to see if everything looks normal and that basic functions can be carried out. If milestones are hit in time and everything is deemed in good order, then the project team can sometimes finish on Saturday evening, and the new system is ready to start normal business processing on Monday. If errors are found which compromise the migration, then it may have to be postponed. In this worst-case scenario Sunday can be used to restore the old system for Monday morning normal BAU.
Post Go Live
After a successful go-live weekend (key production release) many contract project resources will leave but internal project members act as floorwalkers, assist BAU users in day-to-day questions and queries which inevitably arise with new processes and new applications to use. This ensures the machine runs smoothly.
Audit Documentation
As previously mentioned, it is also key to prepare a data migration documentation pack for audit purposes, for tracking the Project background business and IT concepts, the recording of business decisions by saving emails, test plans and results, and User Acceptance signoffs by IT and business. These are often checked by internal audit teams or the local regulator when the project is over to ensure due diligence was observed. If issues arose in roll-out or project organization a company may organize a lesson-learnt consultation exercise to ensure mistakes made are not repeated in future initiatives.
Conclusion
Overall, successful data migrations are complex and necessary projects for all involved. As a consultant it’s a valuable experience to include in your CV for the future. One learns in depth how the moving parts of a fund administration company can work together to produce a great outcome. It may seem a difficult topic at first to understand all aspects, but it is an interesting and rewarding one in the end too