BI Migrations: A step-by-step guide

In the data-driven nature of today’s startup world, business intelligence (BI) tools are operationally indispensable. Your client services team depends on product engagement analytics to guide strategy and assess churn risk. Your finance team requires custom data pulls to build their forecasting models. Your C-suite stakeholder needs to know who your most engaged users are, what features they interact with most, how much time they spend on the platform, what brings them back to the platform, and how that all changes over time so they can add it to the appendix of a board deck.¹

If you stay in data long enough, the chance that you’ll either lead or contribute to tooling migration, and particularly BI tooling, is as likely as someone asking you the age-old question “How many users do we have?”. And it can be daunting! However, with the right planning and conscious decision-making, you can ensure a smooth transition for you and your team.

In the guide below, I’ll share my approach to navigating a successful migration. Strap in 🚀 

The Guide

The Guide² is broken into two sections: Pre-rollout and Migration. The pre-rollout steps should take about 2-4 weeks and you should aim to complete this phase shortly after signing a contract with a new vendor. Further, I recommend limiting the actual migration (time between signing a contract with a new vendor and removing all users from your existing BI tool) to 6 weeks. Limiting the timeline enforces key success drivers, such as ruthless prioritization and self-service, which I’ll describe in more detail below.

Pre-rollout

Define Owners and Roles

Before diving into the migration process, it's crucial to establish clear ownership and roles within your organization. Identify who will own the following responsibilities: executive oversight, project management (likely yourself), user training, model development, and dashboard buildout (both from the data team and internal power users).³ Align on requirements from each owner before kicking off the migration, and align with their managers on the time required during the migration and beyond.

Scope the Migration

Set the expectation that not every aspect of your existing BI system needs to be, nor should be, ported to the new tool. Analyze the usage reports of your previous BI tool, conduct user research to understand which content is essential for business operations, and leave everything else in the dust.⁴ While this may feel incomplete and ruffle a few feathers, use it as an opportunity to eliminate reporting cruft and teach folks how to self-serve in the new tool.

Set Self-Service Success Metrics

I am most passionate about this lesson: your end goal should be developing power users into internal champions and value drivers of your organization’s data. Power users will drive org-wide adoption and provide valuable feedback during the migration process. Treat the migration like any product release or enterprise software rollout, where the success metrics are user stickiness and topline engagement. In this case, encourage high-value actions like self-served analysis and report building that validate the monetary cost of the new tool and the opportunity cost of implementation.

Build a Flexible and Staggered Rollout Plan

The migration roadmap should be rigid enough to drive progress, but flexible enough to adjust to unforeseen issues. Instead of the big bang approach of shutting down the existing tool for everyone all at once, consider staggering the rollout of the new BI tool to different teams at different times. This allows for incremental value delivery and provides an opportunity to address any issues or concerns before full implementation. I favor rolling out to a group of users with low data literacy and thorny data problems first as a way to “eat the frog” and lean into potential issues.

Migration

Communicate the Migration Timeline Early and Often

After a clear roadmap is finalized, communicate it to all stakeholders involved and produce weekly updates that keep all folks informed about the migration status. Further, draw a line in the sand by specifying a deadline for shutting down your existing BI tool and fully transitioning to the new tool.⁵

Build 80% Coverage of Data Entities

Having already scoped the most critical data content to be transitioned in the migration, aim for 80% coverage of base data entities/topics/models (i.e. centralized datasets with established joins) during the migration process. The goal here is to enable future analyses and not base data entities solely on the work of the past. The remaining 20% of entities (read: use cases) will often surprise you, and that’s alright!

Don’t Solve All Tech Debt, but Prioritize Reusability

There’s a bit of nuance to this take. If you try solving 100% of tech debt, you won’t get anywhere. That said, still prioritize reusable components like metrics on datasets (common aggregations, default filters) and clear entity naming (dim_user → "Users") because they support concepts like user experience and self-service.

Training, Training, and Training

Invest in comprehensive training sessions to ensure that all users are proficient in using the new BI tool. Segment these sessions based on permission sets and encourage hands-on learning led by BI vendors whenever possible. Offer additional working sessions for quick assistance or troubleshooting. Hop on a quick huddle if needed! The most successful rollouts involve an “on-call” data team for needs early on in the process. This level of attentiveness drives trust-building and pays dividends in the long run.

Permission Groups

Establish permission groups based on the size and structure of your organization. While smaller organizations may opt for more permissive settings, larger organizations should lay the groundwork early to ensure proper access control and data security.

Constant Reassessment

Follow the product approach here. Check in with power users and key leaders throughout the migration and beyond. What’s working? What’s not? Use this information to inform and prioritize future improvements. I've seen success with brief surveys in effectively surfacing shared issues and feelings during and post-migration.

Conclusion

Successful migration requires careful planning, effective communication, and a commitment to user empowerment and training. Invest time in these principles and see the benefits in the months and years to come.

1  This one hits close to home.

2  I wanted to use a ^TM here but was told you need an actual trademark to do so. Alas.

3  In this context, “power users” is loosely defined as a group of stakeholders who can build insights, reports, and analyses for themselves and others with little instruction.

4  A great question to help manage the scope of rebuilt content: “would not having this insight/analysis/report for a week significantly degrade the business?”.

5  One trick I like to use here is telling stakeholders that we’re shutting down the existing BI tool in week X but keep data team access until week (X + 4). This mitigates the inevitable “wait, I forgot I needed this!” scare from folks because we (the data team) can quickly reference the existing tool in an emergency.

Need help managing a migration project, building training materials for your new tool, or deciding between light and dark mode? Reach out to [email protected].