You'll have to search hard to find a self-respecting company these days that doesn't use a business intelligence (BI) tool for making data-driven decisions. Few decisions can get an approving nod from management if they're not properly vetted with data and analysis.

However, this also means there's likely to come a time when your BI tool no longer fulfills all your organization's needs. It might not support self-service, become too expensive, not support certain data sources, or simply not have all the features that new use cases require. Migrating to a new BI tool can unlock benefits like real-time data and advanced analytics techniques such as machine learning and generative AI, adoption of self-service analytics and data-driven decision-making, and lower license fees.

But migrating dashboards and reports is rarely a matter of plug-and-play. BI tools are notorious walled gardens; exporting visualizations with a couple of clicks from one tool to another is mostly impossible. BI tools are also often deeply integrated with an organization's data structures, so migration can also be complex and time-consuming. Couple that with possible internal resistance from people accustomed to the existing tool and its workflows.

A BI tool migration also involves risks. If it's not done properly or takes too long, data could get lost, access can be disrupted, and users might long for the good ol' days when they used the previous BI tool.

Two things can help you overcome these challenges: following a structured approach and working with a data catalog. This article explains the steps you should take before and during the actual migration and shows how a data catalog can support that process.

The advantages of a data catalog

In BI, data catalogs act as centralized repositories that collect, organize, and present metadata about various data sources and their contents in an organization. Data catalogs give BI users crucial context and information about data, like definitions, data source(s), relations, and more. This enables self-service analysts to better understand, locate, and use the data for analysis and reporting.

Specifically relevant for BI tool migrations is data lineage, the Strava for data. Data lineage visualizes every step that a piece of data goes through on a map. This map contains data source(s), intermediary tools, data transformations, and destination.

Having an overview of how your data flows through your organization can drastically improve your migration both during planning and execution.

Since data lineage shows how data ends up in your BI tool's dashboards, you could assess if certain metrics require data transformation in the BI tool or if everything is calculated beforehand. The latter requires deciding on the right place where data transformations should occur, and it also likely increases the workload of the migration. For example, Looker has a built-in semantic layer that is hard to recreate in several other BI tools.

Furthermore, your current BI tool has likely accumulated several workarounds, quick wins, and hacks over the years, all with the aim of getting some data (typically, dumps of spreadsheets) into the tool. Discovering which visualizations depend on such a data source is a difficult endeavor without a data catalog and its lineage features.

A data catalog is also typically populated with your central data repository metadata, from which data quality metrics are derived. These metrics can guide you in determining which analytics assets (dashboards and reports) should be migrated first. Some might even be eliminated altogether if they don't meet a certain standard. Without a data catalog, calculating these metrics for each column of each table could take a lot of time.

Steps for doing a BI tool migration

With that in mind, let's now explore the steps required for a successful BI tool migration and how a data catalog can support you at various stages.

Assessment and planning

Before migrating, you should assess what specific problem(s) your organization has encountered with its BI tool. Pinpointing the exact problem makes planning the migration much easier, as it guides your goals and the description of the problem you share with potential vendors in a request for information (RFI).

It's also important to establish goals and objectives that your organization wants to achieve by migrating to a new BI tool and translating them into key performance indicators (KPIs). Setting KPIs lets you evaluate whether the migration was successful. For example, here are some potential goals you might have with corresponding KPIs:

• Improve user adoption: Number of weekly end users in the organization
• Improve speed: Seconds to load an insight or dashboard
• Promote new functionality: Number of weekly end users of the new functionality
• Boost discoverability: Number of unique tables and columns used by end users

For proper evaluation, measure these KPIs before and after the migration.

Even if your organization has a dedicated purchase department or purchasing guidelines, make sure not to neglect the following steps:

1. Create a list of vendors and tools that seem as if they fit your goal(s).

2. Send out an RFI that includes aspects like functionalities, performance, integration with your organization's digital ecosystem, cost, support, and security.

3. Once all information is gathered, request proposals from each vendor before selecting one.

Data inventorying, selection, and prioritization

In parallel with planning the migration, your organization should start inventorying its data and BI assets—dashboards, reports, databases, tables, columns, and more.

If you've invested thoroughly in data governance practices and worked with a data catalog in the past, inventorying your assets should be a breeze, and you can proceed to prioritizing them. If you don't have a data catalog yet, now is a good time to introduce one since it can be the foundation of your migration planning.

Prioritization can be based on various criteria:

• Business criticality: How essential is the BI asset in the decision-making process of your organization?
• Effort: Some notoriously complex dashboards and reports might require a tremendous amount of work to migrate.
• Quality: What is the quality of the source data? Is the data complete and correct? Are the decisions based on the BI asset likely to be correct?
• Department: To reduce complexity, some migrations are handled on a per-department basis.

If quality is not a criterion for prioritization, make sure to use it in your workload calculations; some BI assets might be crufty or rely on bad data management practices. A BI tool migration is the perfect moment to rework such assets, but keep in mind that it can increase the effort of your migration considerably.

Data transformation and cleansing

Usually, organizations prefer to centralize their data transformations in a single tool. For example, if you're following a medallion architecture, unprocessed data resides in the bronze layer of the data warehouse, cleaned data resides in the silver layer, and modeled, consumption-ready data resides in the gold layer. Moving the data from one layer to another is handled by a data transformation (or data modeling) tool like dbt.

However, some dashboards or reports might rely on gold layer tables but still apply complex logic—such as window functions, high-cardinality aggregations, or multicolumn calculations—to them within the BI tool. This could result in slow dashboards and even high data processing costs. It can be worthwhile to move this logic into the data transformation tool, especially if multiple dashboards rely on the same calculations.

As mentioned earlier, data catalogs can indicate where redundant logic is used after the transformation layer. While it's also possible to do this *during* the migration, moving this logic into the data warehouse beforehand can prevent unpleasant surprises later. If you go this route, account for this increased workload during the planning phase and ensure that both analytics engineers and BI engineers are on board.

Secoda's lineage features are an ideal asset for mapping how a change in logic populates throughout your data and analytics stack, as it instantly makes clear how a single change could break downstream dependencies.

Report and dashboard migration

If you've done thorough planning, the actual migration can happen in a structured manner.

Your data lineage tool can act as your to-do checklist. You can also use it to detect and compare BI assets in the old and new tools to identify if the correct data sources have been used.

While dashboards and reports are downstream BI assets, they usually share upstream dependencies. As mentioned earlier, a BI tool migration can be the perfect occasion for optimizing and simplifying dependencies.

Testing and validation

Only introduce migrated dashboards in the organization when they've been thoroughly tested.

Dashboards should be tested for technical properties. For example, dashboards shouldn't consume too much processing power, and they shouldn't perform complex calculations in the BI tool. End users and stakeholders should also test them to ensure that the dashboard functions as expected.

Deployment and user training

After testing and validation, it's time to deploy the new BI environment. You can deploy in two ways: in phases or all BI assets at once.

A phased approach has certain benefits:

• It mitigates risk. You can identify issues with the new BI assets and the environment (for example, the performance of the BI server).
• It provides flexibility in that new insights can be used to change deployment procedures.
• When the BI team's resources are limited, they can focus their support on a per-asset basis instead of serving the entire organization at once.

But it also has disadvantages:

• A lack of vigor can mean you end up with two parallel BI stacks.
• Managing two BI stacks at the same time requires many resources.
• Ensuring data consistency between both systems is challenging.

A big-bang implementation also has advantages:

• The potential for a faster implementation forces organizations to make tough decisions.
• Costs are reduced since only one system needs to be kept online and maintained.

However, it has its disadvantages, too:

• It's high risk; it's easy to overload a system if everybody in your organization tries to access it at the same time. There's no room for adapting.
• It could be hard to offer support to end users. They could feel left out, resulting in a lower user adoption rate.

One approach clearly isn't inherently better than the other. You'll have to weigh up the pros and cons of each to decide what's best for your organization.

Finally, organize training for all self-service analysts and consumers of dashboards. It's worth noting that this training should not be the first time you involve your organization's BI community. They should have been providing input and feedback at various stages of the migration process.

Since a data catalog drastically improves the accessibility and interpretability of data, it helps improve user adoption. Without one, users can easily get lost, or they can distrust the data, abandon the new BI tool, and revert to the old familiar tool.

Final insights on BI tool migration

Migrating from one BI tool to another can be challenging. A structured approach supported by a data catalog with a data lineage feature can drastically improve your chances of success.

A data catalog can act as a migration checklist to ensure consistency and data quality, and it can help you identify ways to improve BI assets in the new tool. Because a data catalog makes an organization's data and analytics assets comprehensible, it also makes it easier for self-service analysts and dashboard consumers to adopt and trust your new tool.

If you're looking to migrate between BI tools, Secoda's robust data lineage features can help provide structure for your migration. Book a demo to learn more.