Migration Scoring
Antares scoring turns Tableau workbook structure into planning signals. The Analyzer produces a Tableau complexity score for each workbook, then applies a target-specific migration score for the selected BI platform.
The scores are not estimates of elapsed project time. Use them to compare workbooks, group migration waves, identify workbooks that need redesign, and explain why a workbook is low or high risk.
What we score
Section titled “What we score”Antares scores two related but separate dimensions.
Migration difficulty
What it measures: how much target-specific effort is expected for this workbook.
Used for: migration wave planning, target selection, blocker review, and conversion readiness.
Tableau complexity
What it measures: how hard this Tableau workbook is to understand, maintain, and validate.
Used for: portfolio cleanup, refactoring decisions, and workbook owner review.
The Analyzer currently supports migration scoring for these target systems:
| Target system | What the target score emphasizes |
|---|---|
| Power BI | DAX rewrite effort, feature gaps, calculated parameters, table calculations, set actions, custom extensions, LOD expressions, context filters, and workbook scale. |
| Databricks AI/BI | SQL-native migration fit, unsupported Tableau interactions, SQL JOIN rewrites, AI/BI parameter support, SQL window-function mappings, and dashboard rebuild scale. |
Target migration scores also produce reasons, blockers, and warnings:
- Reasons are the top scoring factors shown to explain why a workbook received its migration tier.
- Blockers are high-priority migration risks with no direct equivalent or major target limitations.
- Warnings are features that can migrate but need review, validation, or redesign.
Tableau scoring
Section titled “Tableau scoring”Tableau complexity measures the workbook itself, independent of the migration target. It looks at calculations, LOD expressions, context filters, parameters, actions, data modeling complexity, workbook size, dashboard density, and field utilization.
Formula
First, Antares normalizes the raw component scores: technical is divided by 600 and multiplied by 100, data is divided by 250 and multiplied by 100, and size is divided by 200 and multiplied by 100.
Then Antares combines those normalized scores as 55% technical complexity, 30% data complexity, and 15% size complexity. In prose, the Tableau complexity score is normalized technical score times 0.55, plus normalized data score times 0.30, plus normalized size score times 0.15.
Tableau complexity tiers use these thresholds:
Low 0-40
Straightforward workbook structure. Good candidate for early review or portfolio cleanup.
Medium 40-60
Some complexity. Expect targeted validation, calculation review, or small refactors.
High 60-100
Significant workbook complexity. Experienced reviewer involvement is likely.
Very High 100-150
Major workbook complexity. Plan focused remediation before or during migration.
Extreme 150+
Exceptional complexity. Consider refactoring, splitting, or phased review.
Technical complexity has the largest weight because it includes the features that most affect maintainability and migration risk: calculated fields, nested and complex calculations, table calculations, window functions, LOD expressions, context filters, parameters, actions, data blends, and custom SQL.
| Technical signal | Scoring behavior |
|---|---|
| Calculated fields | Simple calculated fields add low complexity. Nested or complex calculations add more because they are harder to trace and validate. |
| Table calculations and window functions | Add higher complexity because they depend on visualization structure, partitioning, ordering, and addressing. |
| LOD expressions | FIXED LODs score higher than INCLUDE and EXCLUDE because they override the visualization level of detail. |
| Context filters | Add complexity because filter order can change LOD behavior and query semantics. |
| Parameters and actions | Basic parameters and simple actions score lightly. Parameter actions and set actions add more complexity. |
| Data blends and custom SQL | Add technical complexity because they affect performance, debugging, optimization, and maintainability. |
Data complexity measures source and model shape.
| Data signal | Scoring behavior |
|---|---|
| Data source count | Tiered by number of data sources. More sources increase the score. |
| Connection types | Live connections, extracts, and custom SQL connections add points. Custom SQL adds the most. |
| Relationships | More relationships increase the score. Many-to-many relationships add an extra penalty. |
Size complexity measures workbook scale.
| Size signal | Scoring behavior |
|---|---|
| File size | Tiered by workbook size. Larger files score higher. |
| Total components | Worksheets, dashboards, and related workbook components increase scale complexity. |
| Dashboard density | More visualizations per dashboard increase review and rebuild effort. |
| Field utilization | Very low utilization adds a penalty for unused-field cleanup. Very high utilization adds a smaller penalty because nearly every field needs validation. |
Power BI scoring
Section titled “Power BI scoring”Power BI migration difficulty is a target-specific score. It asks how much effort is expected to reproduce the Tableau workbook in Power BI, with attention to DAX, Power Query, visual interactions, custom visuals, and report/page rebuild effort.
Formula
The Power BI migration formula is a capped cumulative score: Antares multiplies each detected metric count by that metric’s Power BI weight, sums the results, and caps the final score at 100.
Some repeatable features are capped so one pattern cannot dominate the score by repetition alone. For example, parameter action groups, calculated parameters, context filters, window calculations, worksheet count, and dashboard count have caps.
| Feature group | Why it matters for Power BI |
|---|---|
| Set actions | No direct equivalent. Usually require bookmarks, complex DAX, or redesign. |
| Custom extensions | Must be rebuilt as Power BI custom visuals or replaced. |
| Calculated parameters | String parameters usually need custom DAX. Numeric parameters often map to What-If parameters. Date parameters can map to date slicers with DAX. |
| Table calculations | Simple and percent calculations are usually low effort. Running, difference, lookup, and WINDOW calculations require DAX context work. |
| LOD expressions | FIXED often maps to CALCULATE plus ALLEXCEPT. INCLUDE and EXCLUDE often require SUMMARIZE and iterator patterns. |
| Context filters with LODs | Need special review because Tableau filter order may need to be recreated with DAX filter context. |
| Worksheets and dashboards | Add scale effort because report pages, visuals, layout, and interactions need recreation and validation. |
| Data blends | Usually map to relationships, but still need modeling validation. |
Power BI migration tiers use these thresholds:
Low 0-20
Straightforward migration with features that map directly to DAX measures, slicers, What-If parameters, relationships, or built-in interactions.
Medium 20-40
Moderate effort. Expect LOD or table-calculation conversion to DAX patterns.
High 40-60
Significant rework. Heavy table calculations, window functions, or extensions may require custom DAX or custom visuals.
Very High 60-80
Major blockers. Set actions, calculated parameters, or features without direct Power BI equivalents need workarounds.
Extreme 80+
Extensive blockers at scale. A phased approach or partial rebuild is recommended.
Databricks AI/BI scoring
Section titled “Databricks AI/BI scoring”Databricks AI/BI migration difficulty uses the same capped cumulative scoring pattern as Power BI, but the weights are different because AI/BI is SQL-native instead of DAX-native.
Formula
Antares multiplies each detected metric count by that metric’s Databricks AI/BI weight, sums the results, and caps the final score at 100.
Features that map naturally to SQL score lower than they do for Power BI. Features that depend on Tableau-only interactivity score higher because AI/BI may not have an equivalent workaround.
| Feature group | Why it matters for Databricks AI/BI |
|---|---|
| Set actions | No equivalent and no practical workaround for dynamic set behavior. |
| Custom extensions | No Tableau-style extension gallery or custom visualization plugin equivalent. |
| Parameter actions | No click-to-update-parameter interaction. Usually requires redesign. |
| Highlight actions | AI/BI supports cross-filtering patterns, but not highlight-only interaction in the same Tableau sense. |
| Data blends | Must be rewritten as SQL JOINs or modeled through Unity Catalog rather than visual blending. |
| LOD expressions | FIXED maps well to SQL partitioning. INCLUDE and EXCLUDE are more limited and may require AGGREGATE OVER workarounds. |
| Table calculations | Running, percent, simple, difference, lookup, and WINDOW patterns often map to SQL window functions, so many score lower than in Power BI. |
| Parameters | String, numeric, date, and datetime parameters are natively supported through SQL parameter syntax, so they are usually low effort. |
| Worksheets and dashboards | Still add scale effort because datasets, visualizations, pages, filters, and cross-filtering behavior need recreation. |
Databricks AI/BI migration tiers use these thresholds:
Low 0-20
Straightforward migration. Calculated fields, parameters, and many table calculations map to SQL custom calculations or native parameters.
Medium 20-40
Moderate effort. INCLUDE or EXCLUDE LODs, data blends, or SQL JOIN rewrites need focused review.
High 40-60
Significant rework. Custom extensions or parameter actions may require redesign.
Very High 60-80
Major blockers. Set actions or unsupported interactions need manual redesign.
Extreme 80+
Extensive blockers at scale. Multiple set actions, custom extensions, or parameter actions usually require phased migration or partial rebuild.