For many reasons, more and more wealth management firms are migrating their legacy performance reporting systems to new platforms. This high level of migration activities has naturally led to questions about how to do so quickly while causing the least disruption to advisors and clients. This series will guide you through key elements of the migration process. The first article covered the strategic framework for migration and later articles will cover preparing for hidden costs and opportunities and defining minimal viable product (MVP) vs the art of the possible. This article discusses the methodology decisions of data conversion and its impacts to the overall timeline.
When planning for a data conversion from your legacy performance reporting system, your first instinct may be to do the most detailed and comprehensive conversion possible – because who wouldn’t want all their legacy data migrated into the new system? Proceed with caution on this approach; sometimes the juice isn’t worth the squeeze.
Common Methodologies for Historical Performance Data Migration
The three most common methodologies for historical performance data migration are (confirm with your new vendor which options are available and their recommended approach):
- Stored/Static Summary Data—The vendor loads static performance returns at predefined periodic intervals and levels of detail (usually monthly at the account level) to align with your legacy system. Of the three options, this method is the most efficient; however, it limits historical reporting capabilities in terms of activity, flexibility and ability to drill down.
- Values and Flows—The vendor loads periodic legacy system valuations and cash flow details into your new system for performance recalculation and the potential for activity reporting. This option is usually conducted at the account level, so it will also limit reporting capabilities down to the security or asset class levels.
- Full Transactions and Prices Migration—The vendor imports all legacy transactions and daily pricing data into the new system. All transactions are mapped for activity reporting, and performance is recalculated on the new system. This option enables the most flexible and robust historical reporting capabilities, but it is also the most resource-intensive and risky. You’ll need to consider the potential impacts to your conversion timeline.
Selecting the Best Data Migration Methodology
Determining which option is best for you starts with an assessment of your desired rollout timeline, resource availability, data accessibility, data quality, data volume and understanding the reporting requirements for your firm. Examining these decision drivers will help inform the best path forward.
- Rollout Timeline Expectations—Are you under a tight timeline to roll out the new system? How will leadership react if the desired timeline in the project plan is not met? The more detailed the data conversion, the more unknowns that can impact the project timeline.
- Resource Availability—What is your resource bandwidth for auditing converted data for performance outliers and assisting the vendor implementation team with data requests? Choosing a more complex transactions and prices conversion will result in more resourcing needs.
- Data Accessibility—What are the current capabilities for sourcing historical prices, transactions, statements, corporate actions and other market data attributes? If there are issues with reconciling past data, the new vendor will look to your implementation team for support. If your firm is lacking in its ability to source data outside of the legacy system, avoid the full transactions and prices method.
- Data Quality—Are there known gaps in the historical data or has the historical data already experienced a migration in the past? Gaps in history and past migrations are two examples of red flags if your approach is to convert full transactions and prices. There will undoubtedly be challenges that will arise which will impact feasibility and the completion timeline.
- Data Volume—How many years of historical data and how many accounts are in scope for the data conversion? The number of years of history and the number of accounts (and implied positions/ transactions) are directly correlated to risk, time and level of difficulty.
- ●Reporting Requirements—Are there specific reporting time periods or levels of detail that your clients expect to see? If you have very granular reporting needs (such as running custom time period performance calculations or reporting asset class allocation changes over time) and they are critical to your value proposition, consider the full transactions and prices conversion – a thorough cost benefit analysis is highly recommended.
Comparing Legacy and New Performance Outputs
If you plan on doing values and flows or transactions and prices conversion, your new system will be recalculating performance. When comparing the legacy vs. new performance outputs, your new system will not always match for any given period, so allow for an acceptable tolerance threshold when comparing performance data across your accounts. Additionally, make sure that your current system settings and calculation methodology are in alignment, so you can compare apples-to-apples during your conversion audit.
Converting historical data is just one important piece of the performance reporting system migration puzzle. We’ve got much more to come on this topic. Up next: hidden costs and opportunities.
Get in touch for expert support selecting new technology and migrating your legacy technology systems.
