Over the last half year, I have been involved in many large migration projects from another BI tool to Power BI. All with a different setup, from Tableau, Microstrategy and from Analysis Services to Power BI. In this blog I will shine a light on the experiences I gained during these migrations and share some do’s and don’ts. In this blog I start with the why you even migrate in the first place, after which we dive into the where to start and of course also how. A blog that is more focused on the process rather than the technical how-to. At the same time, this blog describes the work I did over the past months and therefore is a small recap of the past half year.

Why migrating in the first place?

In the various projects I did with clients, there were many good reasons to move away from their old BI setup to a newer more future proof one. There were a few elements that kept coming back for all of them:

• Our current BI tool does not fulfil our requirements anymore in terms of self-service capabilities.
• We want to migrate from our on-premises setup to the cloud.
• Cost saving, as we have to buy more capacity/licenses with our current BI tool.

Each of them a valid business case, but a complex migration to do. Besides that, clients were often surprised by the capabilities of the ecosystem in their first exploration around Power BI. In all cases, Power BI also brought new perspectives and new capabilities to the organizations to support their businesses. Mostly, these capabilities were around the self-service area with visual customizations and the ability to use the Power BI datasets not only in Power BI, but also with Analyze in Excel to allow users to still build their Excel pivot tables, while there is data live connected rather than exporting the data.

To get the clients up to speed on the capabilities of Power BI and all that it brings, it is very important to get them familiar with the broader ecosystem first, covering the fair share of Power BI in the Power Platform, but obviously also in the area of Microsoft Azure data services like Azure Synapse, data lake connectivity, log analytics and much more. In order to get the clients up to speed, I run a series of workshops with the clients focused around below topics

• Positioning the Platform, where to position Power BI in your enterprise architecture and how does it relate to the broader vision in the organization around data and self-service capabilities.
• Tenant configuration, what features do you allow or block for your users, why and how to still enable them to get the most out of the platform.
• Best Practices & Ways of working, how to optimally build Power BI solutions in line with best practices.
• Premium capacity configuration, what is a premium capacity and how to position it compared to the broader Power BI ecosystem.
• Usage of Premium functionality, how to get the most out of your Power BI Premium capacities, what additional features does Premium bring and even use it for self-service solutions.
• Community building and user enablement, how to optimally enable self-service users to do the right thing, know where to ask questions and how to help each other within the organization.

This series of workshops helped well to let the clients understand the Power BI ecosystem before even getting started with the migration. All this resulted in a blueprint, which they can use going forward as description with the “rules of the game” around using Power BI in their enterprise organization.

Where to start with the migration?

Once everything was set, it was time to start the actual migration. Typically, in some scenarios the ask from customers was if there is some sort of migration tool. Well, I can tell you, there is not if you come from another BI tool like MicroStrategy or Tableau. You really have to start from scratch and build the solution over again.

If you ask me, starting from scratch is also the only good thing you can do. Even if there was a migration tool, I would not have advised the clients to use it. Simply as you can use the migration also as a good moment for clean-up. So, start with stocktaking of all your current BI solutions and prioritize of all in categories like;

• C-level dashboarding
• Business critical for daily operations
• Nice to have
• Business self-service reporting
• To be dropped

Typical aspects you can look at to give everything the right priority, is to look at current usage of the reports. Everything that is not used, logically gets in the latest category. The second latest category is an interesting one though. Often, migrations are projects with a start and end date, including a deadline on which the old tool licenses expire or simply will be shut down. The central BI team, or Center of Excellence if you will, cannot be responsible for all the thousands of reports in an organization. As a result, some reports must be categorized in this self-service category where the central team does not take any responsibility. However, the community that you build up in the organization while implementing- and migrating to Power BI, is the vehicle to use and make responsible for this self-service reporting migration.

Though, the business users might not have enough knowledge and understanding of Power BI at that moment. Therefore, it is not only the workshops at the beginning of implementing Power BI which are important, but also proving training on different levels in the organization. Think about typical consumer training – how to access reports. But also, how to build new reports on top of managed datasets, and finally all the way to start building solutions from scratch. A training program like this, will also help to identify the champions in your organization that can play a bigger role in the internal Power BI community within the organization by running knowledge sessions and being available for Q&A. In order to appreciate the champions, make sure they have involvement with the core team, for example by including them in a phased roll-out of new features in Power BI.

Rebuild the solutions or not?

As I already briefly highlighted in the section before, is that you can best start from scratch. I didn’t go into details on that part, so here we go! It is rather simple; your Power BI solutions work best with a decent star-schema as data model. Other tools often work based on joined (flat)tables, which is rather different and will not perform well in Power BI. Also, the concept measures in a Power BI data model are typically something that does not exist in Tableau or any other tool. So far only the data model aspect, just to name a few things and we did not even get started on the reporting and dashboarding side – or in general the front-end, where again you will have Power BI specifics like bookmarks, buttons, sync-slicers, field parameters and more.

So, the main thing is, simply don’t try to get exactly the same as you had before and avoid trying to reach feature parity. Each tool, the old and the new one, has its specifics. Redesigning the solution is the way to go! Developers often like to structure their work a lot and might have the old report open on one screen and try to rebuild the exact same on the other screen in Power BI. Please don’t! By taking that approach, you simply will leave a lot of potential behind, which is typically hidden in the tool specifics – like making use of report page tooltips.

Further, rebuilding the solutions is the ideal moment to clean up! Compare it to moving to a new house. If you pack your stuff before moving day, you also clean up and throw stuff away that you don’t need anymore. Try to see the migration to Power BI as exactly the same. Nevertheless, who said the old solution was correct? This is also the right time to review what was there, re-evaluate definitions and rethink the purpose of the solution whether the insights are actionable or not.

This is also the reason why I have my doubts about the recently released migration tool from Analysis Services to Power BI. The tool simply helps you to do a lift and shift from Analysis Services to Power BI but skips over all the considerations described above. From an IT perspective, the tool is still valuable though, in case you have to maintain two ecosystems being Power BI (Premium) and Azure Analysis Services, where the migration allows you to bring everything to one platform and lower hosting and maintenance cost.

Learnings

During these migration projects, I had to investigate time and effort in learning the other tools too, to understand the solution structure and tool specifics, in order to advise clients how certain elements are taken care of in Power BI. At the moment of writing this blog, I’m in the Power BI space for roughly seven years and always said; I focus on Power BI only and I’m not interested in other tools. However, these migrations required me to invest more time in the other tools too. For me personally, it was a learning to not close my eyes entirely for what is happening outside of Power BI.

Looking at a broader scope, I think it is a great learning and one of the main points I want to emphasize in this blog, is to not even try to reach feature parity, because you will not succeed. The tools each have their own specifics and end users will understand that things work differently, as long as you guide and coach them – through trainings, or any other hand-over setup of your choice.

Finally, the way of working within the team is super important to make sure each member of the team matches the same quality criteria before migrated solutions are released to the business. Also, setting and managing expectations to the business is key to make it successful. Plan time to onboard them and guide them through the new ecosystem, let them provide feedback as things will look and work slightly different as what they are used to. Some things (like report specifics) can be adjusted based on their feedback, but the tool and ecosystem are different and remain different. It’s a matter of give and take – but in the end achieve a success together! Make them part of the process and involve them from beginning till end. Consider recording short snackable videos (3-5 minutes max) for guidance though the new platform which end users can easily consume from the community platform to quickly understand where to find- and how to do stuff.

In all these migration projects, I was personally most involved in the start-up of the projects with the workshops and to get the team started. During the actual migration execution, my role was slightly different and more a Q&A role to steer the team in the right direction and answer their questions fast on the how-to in Power BI. Personally, being involved in projects in this way was also a great learning! No longer focusing on nitty-gritty details but looking at it from a distance and more steering the team who are actually doing the migration.