This blog documents my experience migrating complex Tableau dashboards into Power BI for a client working with large-scale telecommunications data. The client’s requirement was clear: replicate the same dashboard functionality — including charts, filters, parameters, interactions, and behaviour — in Power BI.
What became clear very quickly is that Tableau and Power BI require fundamentally different ways of thinking, especially once dashboards rely heavily on calculated fields, parameters, and layered filtering logic.
This post focuses on:
- How to approach a Tableau → Power BI migration correctly
- The biggest conceptual differences between the two tools
- Common pitfalls that only appear once you start rebuilding logic
- Practical lessons learned that can save significant time
What the Migration Covered
The scope of the work involved:
- Migrating multiple Tableau dashboards into Power BI
- Preserving parameter-driven interactions
- Rebuilding complex calculated fields
- Ensuring filters interacted correctly across visuals
- Maintaining performance on large datasets
While some charts could be recreated visually, the real challenge lay in reproducing behaviour, not appearance.
A Fundamental Difference: How Tableau and Power BI Read Data
One of the most important lessons from this migration was understanding that Tableau and Power BI do not evaluate data in the same way. This single difference explains most migration issues.
Tableau: Visual-First and Query-Based
Tableau evaluates calculations at the worksheet level:
- Each worksheet generates its own query
- Calculations are often evaluated within the visual context
- Filters and parameters feel global, even when they are not
{ FIXED }LOD expressions override visual context cleanly
This makes Tableau:
- Easy to prototype in
- Flexible when layering logic incrementally
Many dependencies are handled implicitly, which is why complex dashboards can be built quickly.
Power BI: Model-First and Context-Driven
Power BI works very differently.
Power BI:
- Evaluates logic through the data model
- Applies filters via relationships
- Uses filter context to calculate measures dynamically
- Requires explicit logic for slicers and parameters
As a result:
- The same measure can return different values depending on where it’s used
- Slicers do nothing unless the model or DAX allows them to
- Logic that “just works” in Tableau often breaks without explanation
Power BI is not less capable — it is less implicit.
Why This Difference Matters in Practice
If you approach Power BI like Tableau, you will likely encounter:
- Charts showing identical values across categories
- Measures that cannot be used in slicers or tables
- Filters that partially work or don’t interact at all
- “Blank” values where Tableau shows NULL
- Performance and memory issues on large datasets
These are not bugs — they are consequences of how Power BI evaluates data.
Key Differences Between Tableau and Power BI
1) NULL vs Blank Handling
- Tableau automatically interprets missing values as
NULL - Power BI treats missing values as BLANK
- BLANK ≠ NULL in Power BI
This affects:
- Filters
- Slicers
- Conditional formatting
- Legends and colour logic
In many cases, manual normalization is required in Power BI to match Tableau behaviour.
2)Measures vs Calculated Columns
This is one of the biggest learning curves.
In Power BI:
- Measures are dynamic and context-dependent
- Calculated columns are static and row-based
Many visuals:
- Cannot accept measures as slicers
- Require columns for grouping or filtering
During migration, you must decide:
Should this Tableau calculation be a column or a measure?
Making the wrong choice often forces rework later.
How to Approach a Tableau → Power BI Migration Properly
1. Document Every Calculated Field First
Before touching Power BI:
- List all calculated fields in Tableau
- Identify dependencies between them
- Note which ones rely on parameters or filters
Many Tableau calculations depend on other calculations — recreating them out of order causes cascading failures in DAX.
2. Understand What One Row Represents
This step is critical.
Ask:
- What does one row in the dataset represent?
- Is the calculation row-level or aggregated?
- Is Tableau implicitly aggregating this for me?
Power BI will not infer this for you.
3. Rebuild Logic, Don’t Translate It
A common mistake is trying to “convert” Tableau formulas directly into DAX.
Instead:
- Rebuild the logic using Power BI patterns
- Accept that the implementation will look different
Examples:
- Tableau parameters → disconnected tables +
SELECTEDVALUE { FIXED }LODs →CALCULATE+ALLEXCEPT- Parameter-based filters → Boolean measures returning 1/0
4. Validate Everything in Tables First
Charts can hide issues.
Best practice:
- Create table visuals
- Add intermediate fields
- Compare outputs against Tableau
- Only then build charts
This step saved significant time during this migration.
Skills and Patterns Learned During the Migration
Through this project, I learned and applied:
- Converting Tableau parameters into Power BI slicers
- Handling slicers based on measures via disconnected tables
- Creating square/dot-based visuals using conditional formatting
- Building custom colour legends
- Implementing dynamic tooltips and titles
- Creating subcluster filters driven by disconnected tables
- Building Top-N visuals that respond to multiple slicers
- Managing performance and memory constraints in Power BI
- Understanding limitations of Field Parameters vs custom slicer logic
Conclusion
Migrating from Tableau to Power BI is not a visual exercise — it is a logical and architectural one.
The biggest shift is mental:
- Tableau lets you think in visuals
- Power BI forces you to think in models and context
Once that shift is made, Power BI becomes extremely powerful — but only if the migration is approached methodically.
In the next posts, I will walk through specific solutions used in this migration (with mock datasets), including:
- Rebuilding Tableau parameters in Power BI
- Subcluster filtering patterns
- Top-N filtering