Investment Data Migration

What is a System Conversion or Data Migration?

Implementing a new portfolio accounting, composite, performance and/or trading system always requires some legacy data conversion. Data migration is the process of moving stored information between systems, or formats. Data migration occurs for a number of reasons, including server replacement or maintenance, a change of data centers, data consolidation projects, and system upgrades. As much of a company’s corporate knowledge and business intelligence is contained in its data, any data migration project must be done carefully to minimize risks.

Including your Performance team at the beginning of any conversion project will help to keep you ahead of the curve.

Investment Data Migration Readiness

Unlike any other legacy system migration, Investment Data Migration is one of the biggest projects a firm will undertake – Executive Sponsorship is a must and the pain of NOT doing this migration has to be real.

To help in this decision you may ask yourself a few key questions:

Investment Data Migration

If you answered ‘Yes’ to any of these it may be time to consider a re-visit of your internal processes, systems & service providers. 

Investment Data Migration Tools

Below are the qualities inherent in any good Investment Data Conversion Specialist, and bringing these to your Firm is our top priority:

  • Supports the development and implementation of appropriate solution(s), tools, reports based on recommendations offered to Operations stakeholders

  • Provides a detailed assessment of your current state operating model, we can make various recommendation to align with your business strategy and forward-looking initiatives

  • Demonstrates the ability to analyze disparate and complex data with a focus on identifying business gaps and opportunity leveraging existing and new data

  • Supports senior members of the team with delivering identified best practices, process improvements, and new solutions based on analytic findings of key operating business metrics surrounding financial health, associate and customer experience trends, and other business-related initiatives

  • Participates actively in internal/customer meetings, displaying confidence in offering ideas and suggestions

  • Supports testing and analysis of policy system and conversion data across multiple project lines to identify critical differences between the source system and the target system

  • Partner closely with client data SMEs to define requirements for data conversion

  • Test the target system functionality with converted data and verify that QA team can be engaged for formal testing

Investment Data Migration Challenges

When intially speaking with a prospective client about any back office transformation, the main problem I always hear is:

“We already converted our data to the new system, but the returns aren’t matching and we can’t figure out why...?”

Sound familiar?

During any system conversion, reverse engineering your firm’s inputs required to calculate your performance returns will help you to identify all of the necessary data points needed to ensure a smooth and accurate system conversion.  To know what will change, you must first have a clear understanding of how in-scope functions work today. For some asset managers, this information will be readily available in documented procedures and work flows. For others, a refresh might be required to validate and confirm the current state.

To plan and execute increasingly critical backoffice transformations, firms should be thinking about business requirements, project planning, governance frameworks and data management, to name a few.

Investment Data Migration Services

While we can’t list out every step in a Conversion Project, to get you started in the right direction, some system conversion steps are listed below:

Governance/Steering and PMO Implementation

All transition projects need a governance plan, a steering committee and a PMO to provide oversight and coordination across the firm. Without adequate resources and access to key subject matter experts, the risk of project delays and poor decisions could increase significantly. Additionally, if management does not see this project as a top-priority across the organization, progress will likely be delayed in some fashion.

Business Requirements

To know what will change, your firm first needs a clear understanding of how your processes work today. Start by defining and clearly communicating business requirements. This process is determing what ‘outputs’ your legacy system produces so an eventual determination can be made if these outputs can be achieved in the Future State (this is also plays a part in the Vendor Selection process).

Develop Timelines

Estimate the time required to execute the transformation, to minimize missed deadlines, budget overruns and change management issues during the project. Failing to clearly define your business requirement timelines, and understand that this process needs to be flexible at the outset could mean reworks, delays and budget issues.

Applications Utilized

All systems used in your organization that will be affected need to be determined, along with application ownership, etc. Both the client and the new service provider should identify which entities and internal teams will be affected by any process changes, and whether there are any constraints or requirements to consider.

Vendor Selection

This involves choosing the correct system that will house your data going forward based on current business requirements.

Data Input Discovery

This step involves investigating what ALL of the pieces of data are housed in your legacy system: manual or otherwise.

Up/Down Stream Dependencies

Every piece of data in your organization impacts/touches another. This step involves developing a process flow to determine what inputs affect all outputs, and vice versa. This information could be readily available in documented procedures and work flows (see Business Requirements).

Data Mapping

This is the process of mapping every piece of data in the legacy system, and determining its ‘home’ in the new system.

Testing, Testing, Testing

Once the data starts to be converted into your new sytsem, all process and outputs need to tested to ensure conversion accuracy. This is first done on a small scale, then continues gradually over time until your eventual parallel testing and eventual go live.

Sample Client Engagements

A global investment management/brokerage company was converting from its in-house legacy system to a future state vendor solution, while simultaneously outsourcing its entire back office operations.  I was involved in year 2 of an estimated 5 year project.  During my tenure, I was involved in testing the ‘Day 1, Go-Live’ scenarios to potentially eliminate conversion failures on the day of transition.

Assets Under Management: Over $1 trillion

Account Types: Brokerage accounts to large, institutional investors

Accounts Under Management: 100,000+

Investment Vehicles: All

Major Hudle: Working on a highly segrgated project with overlaping objectives and iterative goals


A global investment management firm was spinning off certain US-based assets into a separately owned legal entity.  During this engagement, an entirely new office was created to house/manage/operate this newly formed company, while simultaneously converting all spun off data onto entirely new platform(s).  As a result, I had to create an entirely new GIPS firm for the newly spun-off entity, including all of the related policies and procedures. Additionally, all new operational processes needed to be created in order to maintain all GIPS-based performance.

Assets Under Management: $15B

Account Types: Large insurance-based managed accounts

Accounts Under Management: 70

Investment Vehicles: Bank loans and fixed income instruments, with derivatives for currency hedging

Major Hudle: Attempting ro create an entire conversion project, in 6 months, without having a fully defined account list

A US-based brokerage firm transitioned from their existing portfolio accounting system to a more user-centric, future state system.  I was engaged to transition all of the client reporting needs/reports for the financial consultants from the current to the future state environment.

Assets Under Management: Over $100B

Account Types: Brokerage accounts and small to large managed accounts

Accounts Under Management: 20,000+

Investment Vehicles: US Equities and Fixed income, with mutual funds and ETFs

Major Hudle: Creating new client performance reports that satisfied existing requirements, but updated for new enhancements

Case Studies

Below are some helpful tidbits of information learned from a variety of back office transformation projects:

 

data field mapping

Has your firm mapped out all of the available data fields from the legacy system to the new system?


trailing return differences

Do differences exist in the trailing return methodologies between your firm’s New and Legacy systems?


vendor questions

Have you ensured that the new vendor has the capability to meet all of your existing business requirements?


benchmarks

Has the benchmark mapping methodology differences between the 2 systems been identified?


Inception date mapping

Does your firm utilize various Date Fields to denote specific ‘inception’ dates for its accounts?