BI and analytics migration
Migrate Your BI & Analyticsfor enhanced insights and decision-making
Moving between BI tools means rewriting calculations and agreeing what your metrics mean. Most reports shouldn't move at all. The ones that do have to match, or nobody will trust them.
Reports move, and the definitions behind them matter more
A BI migration looks like moving dashboards from one tool to another. The difficult part is underneath: the calculations and business definitions that have accumulated inside those dashboards. Revenue might be calculated one way in the finance workbook and another way in the sales one, and both have been trusted for years. Moving tools forces that disagreement into the open, which is uncomfortable and also one of the main benefits.
Start with what is really used
Microsoft's Power BI migration guidance, which applies well beyond Power BI, begins with an inventory of the reports and dashboards that are candidates for migration and a list of every data source they access. It then moves through requirements and prioritisation, deployment planning, a proof of concept, content creation and validation, and finally deployment and support.
Usage logs are the most useful input to that inventory. It is common for a small share of reports to get most of the views. The rest should be archived, not rebuilt, and you should expect some pushback. Ask the owner of each report what decision it supports. If nobody can say, it is a candidate for removal.
What doesn't translate directly
- Calculations. Each tool has its own formula language and evaluation model. A Tableau calculated field or an Excel formula doesn't become a DAX measure by swapping the syntax, because filter context and aggregation behave differently. Budget for rewriting and testing them.
- The semantic layer. Moving to a shared model is a good opportunity to define each metric once, in place of one definition per workbook. It takes longer up front and saves you from this exact argument next time.
- Row-level security. Who may see which rows has to be rebuilt in the target's model, then tested by logging in as real users with different roles.
- Scheduling and refresh. Extract schedules, incremental refresh and subscriptions all need a new home, and source systems may not cope with a different query pattern.
- Pixel-exact reports. Invoices, statements and regulatory reports are a different kind of output. Microsoft provides separate routes for these, such as moving SQL Server Reporting Services content to Power BI Report Server and tooling to bring .rdl reports to the Power BI service.
- Visual habits. Layouts don't carry over one-to-one, and it is usually better to design for the new tool than imitate the old one.
Proving the numbers match
Trust decides whether people adopt the new reports, and one unexplained difference can sink it. So we run both side by side for a period, and compare key figures at several levels of detail: overall, by month and by a sample of customers or products. Differences get written down and explained. Often the old report turns out to be the wrong one, and the business needs to hear that from someone who can show the working.
Set an end date for the old tool as part of the plan. If both stay available indefinitely, people keep using the one they know, and you pay for two.
What we can show you
We have no published BI tool migration. We have built reporting inside applications: cross-channel campaign reporting in one schema for an advertising platform, and utilisation and revenue reports for a rental business. So we understand how to model the data and how to reconcile it, and that is where we would help, particularly on pipelines and source systems. For a large Power BI or Tableau estate, pair us with a specialist in that tool.
BI migration questions
Is there a tool that converts our reports automatically?
Third-party converters exist and may save time on layouts and simple calculations. Treat their output as a first draft. The calculations still need checking by someone who understands both the tool and your metrics.
Should we fix our data warehouse first?
If your metrics disagree because the underlying data disagrees, yes, or at least at the same time. A new front end over the same confusion only makes it look better.
Which reports would people actually miss?
Tell us the current tool, the target and the handful of reports the business runs on. We will tell you where we can help and where a tool specialist would serve you better.
We reply within one business day (IST).