Many things need to happen to have a successful migration from a legacy application to a new system. There are difficult data mapping decisions that need to be made and data quality concerns to be addressed. There are the typical challenges of change management and end user training. In large efforts, entire teams may be dedicated to profiling and remediation of legacy data. In the midst of all this migration activity sits a critical and often underestimated function – reporting. What happens to all the analytical, transactional and operational reports the legacy system provided and where do users go for that data in the new world?
The first step to ensuring that existing and future reporting needs are met is to conduct a report rationalization effort. A reporting rationalization is a holistic review of all the existing reports, metrics and dimensions used in the current system with a mapping to how this data will be delivered in the new system. Often during a reporting rationalization, many reports and metrics are found to be either duplicated in multiple places or unused. By spending time up front to understand the legacy reporting and how it translates to the new reporting needs you can almost always reduce the number of reports that need to be replicated. Building a smaller number of highly utilized reports reduces upfront development costs and also keeps maintenance costs lower moving forward.
How does one complete a reporting rationalization? Depending on the availability of documentation it can be a daunting task or an easy one. Understanding what data you need prior to starting the rationalization and developing a strategy to collect it will keep you focused and prevent analysis paralysis. At a minimum, the following data must be captured to successfully use the output of the rationalization to drive target state reporting requirements:
- Legacy report name and description
- Report owner and/or metric owner
- Name and definition of each metric as defined on the legacy report
- Name and definition of each dimension as defined on the legacy report
- Data types and length of each metric/dimension on the legacy report
- Source database, table and column name for each metric and dimension
- Calculation for each metric. Often times business logic is embedded into a report, so it is critical to capture this logic so that informed consolidation discussions can occur
- Business area – What part of the organization is the report intended for?
- Report frequency and latency – Is the report run on demand, produced daily, weekly or monthly? Is the data real-time or batch?
- Report type (Operational, Transactional, Analytical) – Often times the legacy system does not distinguish between report types. As organizations move to target architecture, there may be a need to separate reports by future data store
- Suggested business intelligence component to use in the target state architecture. How will the data be consumed in the target state? Is it analytical data that needs to be sliced and diced in a cube, is it a canned report or does it require ad-hoc access?
Once this data is collected for each of the legacy reports, a consolidation recommendation can be made. There will likely be opportunities to eliminate reports or combine reports to meet multiple users' needs. The rationalization also gives the warehouse team a reference point to ensure that the requirements they are delivering on will meet the final reporting needs. Completing a rationalization effort upfront will pay dividends throughout the project and increase the likelihood of having a satisfied business customer at go live.