Most investment management firms that are still producing client reports from spreadsheets or legacy on-premise systems know they should move. The question is not whether to migrate to a cloud-based reporting platform – it is how to do it without disrupting live reporting cycles, introducing new errors, or losing institutional knowledge that exists only in the heads of the people who built and operate the current system.
This guide covers the practical steps involved in migrating investment reporting to the cloud: what to do before you start, how to manage the transition, and what to watch out for.
Start with a high-level reporting audit
Before starting any technical work, map what you currently produce. How many different report types do you run? How many clients does each serve? What data sources feed each report type? What client specific display rules and options exist? In simple terms, create a matrix of reporting requirements.
Firms that skip this step almost always encounter surprises mid-migration – a bespoke client template that requires a custom data calculation, a legacy benchmark feed that may exist differently in the old system, or a regulatory disclosure that needs configuring in the new platform before go-live.
Also decide whether you want a ‘like-for-like’ replacement for your reports, or a redesign and refresh of the reports – in order to introduce the latest brand updates from your firm, and the best practice reporting techniques to improve clarity and communication.
Choose a platform built for investment reporting
Generic document automation tools and cloud platforms are not the same as systems built specifically for investment management reporting. The critical differences are data integration and validation capability, the level of user control afforded, the level of automation, the flexibility of the workflow and the prompting, collection and integration of commentary to the reports.
Evaluate at least two or three specialist providers before committing. Ask each to demonstrate how they would handle your most complex report type, to demonstrate the user experience, and how they manage updates to templates.
Plan the data migration carefully
Most reporting projects are data bound – that is, the data provision and ingestion is the element that determines the critical path and the overall schedule of the on-boarding project.
Clearly documenting the data required to support the reports, both directly and indirectly and the golden data sources is a key project activity.
Establishing data extracts, trafficking methods or data transfer via APIs is a key activity.
Get these specifications agreed in writing before implementation starts.
Testing and assurance
The most important risk mitigation in any reporting migration is testing. We suggest re-producing the reports from three prior periods, and comparing the actual reports produced by the legacy process with that of the new system. Any differences should be reviewed, explained and appropriate steps taken to correct – often it’s the legacy system that is ‘wrong’.
This testing ensures the users are able to operate the system to produce the reports, and that the reports produced are accurate in terms of data, charts, tables, text, commentary, other content, and branding.
Any discrepancy needs to be investigated and resolved before cutover.
Train the right people, not everyone
Over-training is as common a mistake as under-training in reporting migrations. The investment team needs to know how to input commentary. The reporting team needs to know how to manage the production workflow and the configuration screens. Senior stakeholders need to know how to review and approve reports.
These are four different groups with four different training needs. Design training accordingly, rather than running everyone through a generic platform walkthrough.
We recommend there’s at least one ‘superuser’ who understands broadly how it all fits together, and is familiar with all the activities undertaken by their teams.
Plan the cutover date carefully
The cutover from old to new system should happen at the start of a reporting cycle, not mid-cycle. It is best to start simple and then add complexity and volume. With a cloud-based system, such as that provided by Opus Nebula, it is not necessary to migrate all the report types and reports at once. There is a huge amount of flexibility in terms of which reports you start to produce on the new system, and stop producing on the old system. This can be broad groups, or set at a highly granular level down to each individual report.
Once all the reports are being produced on the new system, the old system, processes and activities can all be retired and demised.
Frequently asked questions
How long does it take to migrate investment reporting to the cloud?
It depends on the complexity of your data environment, the number of report types you run, and how much configuration is required in the output reports.
Migrating to a SaaS multi-tenant solution such as that provided by Opus Nebula, is undertaken in a fraction of the time of a more traditional system implementation. Fund factsheet projects are typically undertaken in 3-5 weeks, and a full quarterly report on-boarding would be 2-3 months from start to finish – significantly quicker than 6-18 months for a more traditional reporting system implementation. This efficiency is created by the cloud-based and multi-tenant set up, and the system simply requires configuration to on-board a new investment firm.
What are the biggest risks in a reporting migration?
With Reporting as a Service from Opus Nebula, the traditional project risks are minimised. The core system is already live and supporting existing clients, it simply needs to be configured for new data, new users and new report outputs. These will have already been tested as part of the project activities.
Operational risks are also reduced. The system is securely hosted within the Microsoft Azure cloud, and configured to achieve the published system availability of 99.99%.
Do we need to rebuild all our templates from scratch?
No. Opus Nebula technical resources will create templates that dynamically flex based on the data, configuration and user control requirements to produce exactly the output reports required – pixel perfect every time.