BI Migration: What It Is, How Teams Approach It, and What Stays Hard
September 30, 2026
A BI migration moves the reporting layer of an organization from one business intelligence platform to another: the dashboards people open, the calculations and models behind them, and the rules about who sees what. The data itself usually stays where it is. That distinction matters, because a BI migration is often confused with two things that share its vocabulary: a data migration, which moves rows between systems, and a move inside one vendor, such as Tableau Server to Tableau Cloud, where the artifacts keep their format and the vendor ships the tooling.
Why do teams migrate BI tools?
Four reasons come up most often. A licensing renewal makes the cost of the incumbent visible on one line, next to a cheaper or already‑owned platform. A consolidation decision, often after an acquisition, leaves the company running two or three BI tools and wanting one. The data platform pulls the reporting layer toward it, which is why Databricks and Microsoft each publish guidance for arriving from other tools. And sometimes the team that knew how to run the incumbent has left. Microsoft's migration guidance names the same drivers: standardizing away from several tools, lowering cost of ownership, doing more with fewer people. None of them settles the shape of the project.
What are the approaches to a BI migration?
| Approach | What it means | Fits when | What it costs you |
|---|---|---|---|
| Rebuild | Treat each old dashboard as a requirements document and author the new one from scratch | Small estate, or a redesign was overdue anyway | The most hours per dashboard; each one becomes a small project |
| Lift‑and‑shift | Reproduce each dashboard as faithfully as the target allows, no redesign | Regulated reporting, or users who need the same screen on Monday | Inherits every flaw, and some things cannot be reproduced at all |
| Rationalize, then convert | Retire what nobody opens, merge duplicates, then move what remains | Large estates that grew for years without pruning | An inventory and usage study before any dashboard moves |
| Automated conversion with review | A tool regenerates the model and report from the source definition; people review what it flags | Hundreds of dashboards with repeating patterns | Review capacity; output reproduces function, not pixel layout |
These are not exclusive. In practice a project mixes them: rationalize first, convert the bulk, rebuild the most‑viewed few, lift‑and‑shift what regulation freezes (automated versus manual works through the economics of that mix). Microsoft's guidance says it's rare that a direct one‑to‑one migration occurs without any refactoring or enhancement, and its customer write‑ups note that not every report could be faithfully replicated. The mix is decided dashboard by dashboard.
What are the phases of a BI migration?
Microsoft frames a migration as pre‑migration steps plus five stages: gather requirements and prioritize, plan deployment, conduct a proof of concept, create and validate content, then deploy, support and monitor. Whichever vendor is on the receiving end, the work falls into six phases.
| Phase | Output | The mistake to avoid |
|---|---|---|
| Inventory and usage | Every dashboard, its sources, its viewers, its last open date | Counting workbooks instead of what people actually open |
| Scope and prioritize | A ranked list: what moves first, what moves later, what retires | Migrating everything because nobody will sign off on retiring anything |
| Proof of concept | A few representative dashboards, end to end, numbers reconciled | Picking the easy ones, which proves nothing about the estate |
| Convert or build | Models, measures and report pages on the target | Starting the bulk before modeling and naming conventions on the target are fixed |
| Validate | Old and new agree under filters, dates and security roles | Checking totals only; the discrepancies live in the details |
| Cut over and decommission | Users moved, the old platform read‑only, then off | Leaving both platforms live indefinitely, which doubles the cost the migration was meant to remove |
The last phase is the one the business cares about, because the decommission date is when the old license stops; sequence everything earlier backward from it.
What makes BI migration hard, whatever the platforms?
Five problems recur whatever the source and target pair, and they are the ones estimates get wrong.
| Problem | Why it is hard | What decides it |
|---|---|---|
| Where the logic lives | Every platform puts calculations somewhere different: a worksheet, a measure on a shared model, a SQL dataset, a metric view | A per‑calculation decision about its home on the target, made before the bulk conversion starts |
| Calculations with no equivalent | Level of detail expressions, table calculations, set actions and time intelligence each exist on some platforms and not others | An inventory that names them before anyone commits to a date; they are redesigned, not translated |
| Security | Row‑level rules are rebuilt against a different identity model every time | Testing per role before cutover; it is the first thing an auditor asks for afterwards |
| Validation | Two dashboards with the same total can still disagree under a filter, on a fiscal calendar, or for a user in a restricted role | Reconciliation under filters and roles, not totals; this is where projects that looked finished find out they were not |
| Adoption | Microsoft's customer notes say the challenges left after migration were skills, time and funding rather than the platform; its migration overview warns that experts in the old tool may feel displaced | Training, a support path and a communication plan, budgeted like the conversion itself |
The pair‑specific pages go into each of these for one source and target: LOD expressions to DAX, row‑level security to Unity Catalog, table calculations in Databricks AI/BI.
How do you choose a BI migration approach?
Measure the estate before choosing. Three measurements decide most of it. The share of dashboards anyone opens. In one migration Microsoft documents, about half of thousands of published reports had been accessed in the previous year, and the set that delivered significant value was half of that again; an estate with that profile is a rationalization project first. The spread of complexity. If most dashboards are a few standard charts on one source, automated conversion pays off and rebuild effort concentrates on the few that are not; if every dashboard is a bespoke analytical application, the plan is closer to a rebuild. The reliability of per‑dashboard estimates, which is low. The same write-up records a report estimated at 50 days that took about 50 hours, and concludes that estimates are most valuable in the aggregate. So measure the whole estate and size the project from the distribution, not from individual estimates. Cost and duration for the Tableau to Power BI case are worked through on their own pages: cost estimation and how long a migration takes.
BI migration services, tools or both: which do you need?
BI migration solutions on the market fall into four kinds, and as of September 2026 they are not interchangeable. Vendor‑native importers move content toward the vendor who wrote them: Databricks' Genie Code importer accepts Tableau workbook and data source files and Power BI template (.pbit) files and builds AI/BI dashboards, while Tableau's Content Migration Tool moves content between Tableau sites. Conversion tools read the source definition and generate the target artifacts across vendors. Services firms and systems integrators run the project, usually with an accelerator of their own inside. In‑house teams do the work by hand, the right answer for a small estate with the target skills present. Consultant versus tool works through the choice, and the partner program is where tool and integrator meet.
What Antares does
This is the product‑dependent section; everything above holds whichever tool you use. Antares is the BI migration tool behind this library, and it automates the convert phase with two modules. The Analyzer reads the source environment's metadata, never business data, and returns the inventory the phases above depend on: usage, complexity, data sources, and which dashboards carry constructs that will not translate mechanically. It is free and fully deterministic. The Converter is deterministic‑first with guardrailed, validated AI steps, and converts and deploys dashboards at a flat $200€200 per source dashboard, LLM costs on top, typically under $20€20.
Each supported source and target pair has its own guide, such as Tableau to Power BI and Tableau to Databricks AI/BI, and the home page keeps the current list of routes. It is not a data migration tool and it does not redesign dashboards: the output is like for like, one source dashboard becoming one Power BI report page or one AI/BI dashboard. See the Analyzer and Converter pages, or run the free Analyzer on your own estate.
Primary sources: Microsoft's Power BI migration overview, requirements stage and customer lessons; Databricks on importing Tableau and Power BI files; Tableau on the Content Migration Tool.
Related Migration Resources
Frequently asked questions
What is BI migration?
Moving an organization's reporting layer from one business intelligence platform to another: dashboards, the calculations and semantic models behind them, and access rules. The underlying data normally stays put, which separates it from a data migration, and it crosses vendors, which separates it from moving between sites of the same product.
Is BI migration the same as data migration?
No. A data migration moves rows between storage systems; a BI migration moves what is built on top of them. The two are often scheduled together, but running them at once means every mismatched number has two possible causes. Sequencing the BI layer against the existing data, then moving data later, is usually cheaper to validate.
Which BI migration approach is cheapest?
For a small estate, an in-house rebuild. Above a few dozen dashboards, rationalizing first is the biggest saving available, because a large share of most estates is never opened; automated conversion with review then handles the bulk, and rebuild effort is spent only on the dashboards that carry the most viewers.
Can BI migration be automated?
Partly. The model, standard visuals, filters and most calculations can be generated from the source definition, and that is the bulk of the hours. Constructs with no equivalent on the target, security rules and the validation that old and new agree still need people. Vendor-native importers exist too, but each moves content toward its own vendor.
Do we need a BI migration service, or can we do it in-house?
In-house is realistic when the estate is under a few dozen dashboards and the target platform's skills already exist. A services firm is the answer when nobody internal can run a multi-month program, or when change management for hundreds of viewers is the real work. Ask any firm which accelerator it uses and what its output needs reviewed.