Tableau to Power BI Migration Checklist: What to Assess Before Conversion

1. Confirm the estate scope

Begin with the Tableau environment rather than a folder of files supplied for conversion. Confirm which sites, projects, workbooks, published datasources, owners, and business units are in scope. Record whether the inventory is complete and when it was last refreshed.

• Identify all Tableau Server or Tableau Cloud sites in scope
• Capture projects, workbooks, views, owners, and upstream data assets
• Record source platform and workbook versions where available
• Separate production, development, archived, and personal content
• Assign an accountable owner for unresolved assets

2. Review usage and business value

Existence is not the same as value. Combine platform usage evidence with business-owner input before deciding that a workbook should be migrated. Recent views are useful, but they should not automatically retire regulatory, seasonal, or operational reports that are important only at specific times.

• Capture recent usage and last-viewed evidence
• Identify executive, regulatory, operational, or customer-facing reports
• Flag unused and low-usage workbooks for review
• Identify duplicate, overlapping, and superseded reports
• Record a preliminary keep, migrate, consolidate, review, or retire decision

3. Assess datasources and refresh requirements

For each workbook, identify the connection type, tables, published or embedded datasource use, custom SQL, extracts, files, credentials, and refresh expectations. A report cannot be considered migration-ready if its target data access is unknown, even when the report layout converts cleanly.

• List every embedded and published datasource
• Identify database, file, extract, cloud, and custom SQL connections
• Confirm target connectivity and gateway requirements
• Record refresh frequency, ownership, and credential responsibility
• Identify unavailable, obsolete, or environment-specific sources
• Confirm whether source data may be embedded in packaged workbook files

4. Choose the semantic-model approach

Decide whether the report will use an independent model, an existing shared semantic model, or an expanding shared model. Review grain, field roles, datatypes, relationships, default aggregations, hierarchies, date handling, and security requirements.

Do not recreate shelf-level aggregations as physical source columns. A Tableau use of SUM(Sales), for example, normally means the Sales field is aggregated in the view; it does not mean the source contains a column named Sum Sales.

• Confirm table grain and relationship cardinality
• Map dimensions, measures, keys, dates, and geographic roles
• Identify reusable measures and conformed dimensions
• Choose per-report or shared semantic-model ownership
• Review row-level security and data-access boundaries
• Confirm aggregation behavior rather than inferring physical columns

5. Catalogue calculations and business logic

Capture every calculated field with its display name, native expression, datasource context, dependencies, expected role, and usage. Distinguish calculations that can be translated safely from those that need review or manual authoring.

Pay particular attention to level-of-detail expressions, table calculations, parameter-driven logic, date calculations, distinct counts, custom SQL, scripts, and calculations whose result depends on the current view.

• Retain the original Tableau formula
• Generate and review the proposed DAX separately
• Trace dependencies between calculations
• Resolve duplicate names and conflicting definitions
• Validate critical outputs against trusted source values
• Store the user-accepted target formula as the final decision

6. Review filters, parameters, and interactions

A visible Tableau control may represent a dimension filter, date range, relative date, parameter, set, Measure Names selection, or action-driven behavior. These should not all be converted into identical Power BI slicers.

Record the field binding, source table, scope, default selection, allowed values, target sheets, and interaction behavior. Consolidate repeated evidence when the same filter is used across several worksheets so reviewers see one control and its complete usage.

• Classify dimension, measure, date, range, parameter, set, and Measure Names controls
• Resolve the source field and table explicitly
• Record single-select, multi-select, include, exclude, and default states
• Identify worksheet, dashboard, page, or report scope
• Review filter actions, highlighting, navigation, and cascading behavior
• Flag controls without a safe native Power BI equivalent

7. Assess visuals and dashboard layout

Evaluate each worksheet from its Tableau mark type, shelves, field roles, aggregation, encodings, formatting, filters, and dashboard placement. Confirm whether Power BI has a direct native equivalent and what interaction differences remain.

Dashboard objects also matter. Text, images, navigation, legends, containers, show/hide controls, and floating placement can affect the final experience even when the charts themselves convert.

• Map common charts to native Power BI visuals
• Confirm X, Y, values, legend, details, tooltips, and small-multiple roles
• Preserve aggregation, sorting, Top N, number formats, and meaningful colors
• Identify custom or unsupported visuals and interactions
• Compare target placement and sizing with the source dashboard
• Record manual layout and formatting work separately from chart mapping

8. Estimate effort and prioritize migration waves

Complexity and automation readiness answer different questions. Complexity estimates the work inherent in the asset. Automation readiness estimates how much of that work can be prepared reliably. Do not charge or prioritize solely according to features that the migration approach cannot support.

Group workbooks into waves using business priority, dependencies, complexity, readiness, owner availability, and validation effort. Begin with a representative pilot rather than only the easiest or hardest report.

• Estimate datasource, model, calculation, visual, filter, and validation effort
• Separate automated preparation from remaining manual work
• Identify blockers and prerequisite target architecture
• Account for stakeholder review and data reconciliation
• Sequence shared models before dependent reports
• Track assumptions used in cost and schedule estimates

9. Define validation and sign-off

Agree on acceptance criteria before conversion begins. Technical validation should confirm model behavior, measures, filters, visuals, refresh, and performance. Business validation should confirm that the report supports the intended decisions and that accepted differences are documented.

• Name the technical reviewer and business owner
• Define representative data and expected results
• Reconcile critical totals and calculations
• Test filter, slicer, parameter, and navigation behavior
• Validate refresh, credentials, security, and performance
• Record review status, issues, decisions, and formal sign-off

10. Keep the migration traceable

A migration assessment should leave the team with more than a score. It should create a repeatable evidence trail that supports planning, review, delivery, and later changes.

• Source inventory and usage evidence
• Workbook-level readiness and complexity assessment
• Datasource and dependency plan
• Native and proposed target logic
• Review decisions and accepted changes
• Migration tracker with owners, status, issues, and sign-offs
• Validated target package and documented remaining work