What actually comes across from a Tableau workbook

Every BI vendor will tell you migration is easy. What they usually mean is that they can read your data. Reading the data is a solved problem and it is not the work. The work is everything the workbook encodes that nobody wrote down anywhere else.

A ten-year-old workbook is a sedimentary record of decisions: which of four date fields counts as the order date, that returns are excluded but cancellations are not, that the regional breakdown always sorts by profit rather than alphabetically. None of it is documented. All of it is load-bearing, and you find out which parts when the numbers stop matching.

Start with the report, not the migration

Drop a workbook in and you get a fidelity report before you have committed to anything — sheet by sheet, calculation by calculation, filter by filter.

The import page after a Tableau workbook: four of four sheets converted with zero partial and zero manual, four of four calculations translated with zero to verify, one table of 600 rows, and one dashboard created — **The numbers to read first.** Sheets converted, and how many of those were partial. Calculations translated, and how many need a person. A workbook that comes back 40/52 with nine calculations to verify is telling you what the fortnight after the migration looks like.

4 / 4sheets converted on this sample workbook

4 / 4calculations translated, none needing a person

3filters carried, with their selections

0filters dropped

That is a small, clean sample workbook, and it is worth saying so plainly. A real estate workbook with sixty sheets and a decade of accretion will not come back 4/4, and the report will say so rather than handing you a dashboard that quietly disagrees with the old one.

A worked example

What a nine-year-old workbook actually comes back as

The sample workbook in the screenshot above returns 4/4 and 4/4, which is true and unhelpful. Here is the shape of a real one — a regional sales workbook, 52 sheets, first saved in 2017, eleven authors.

	Count	Verdict	What it means for the plan
Sheets	52	41 converted, 8 partial, 3 manual	The 8 partial are mostly sheets with a dual axis, which import as two panels
Calculated fields	38	29 translated, 6 to verify, 3 manual	The 6 are date intervals — one sitting, an afternoon
Of which table calcs	9	7 translated, 2 manual	The 2 use LOOKUP, which depends on the sheet’s addressing
Of which LODs	5	4 FIXED translated, 1 INCLUDE manual	The INCLUDE cannot be settled at model-build time, by definition
Filters	71	71 carried, 0 dropped	Including 14 quick filters with their saved selections
Uses `USERNAME()`	4 fields	Reported, not translated	Row security hiding in a formula — becomes 2 policies, and the old rule turns out to have covered only 31 of 52 sheets
Sheets nobody opened in 90 days	33 of 52	Do not migrate these	The largest single saving in the whole exercise

Illustrative composite. The figures are internally consistent and every step is one the product supports today.

Read the last two rows together. Of 52 sheets, 33 were dead; of the 19 that mattered, the review list came to roughly a dozen items. A week of work, not a quarter — but only because somebody checked usage before scoping.

And the USERNAME() row is the one that changes a governance posture: the old row-level security applied to 31 of 52 sheets, which nobody knew, because the rule lived inside a calculated field that only some sheets used. Why that is reported rather than translated →

sankey-beta
52 sheets,Converted cleanly,41
52 sheets,Partial - needs review,8
52 sheets,Manual,3
Converted cleanly,Worth migrating,14
Converted cleanly,Nobody opened in 90 days,27
Partial - needs review,Worth migrating,5
Partial - needs review,Nobody opened in 90 days,3

The workbook that came back 41/52. Read it left to right and the fidelity looks like the story; read it to the far right and the story is that 30 of the 52 sheets were not worth migrating at all.

What converts

What is in the workbook	What happens to it	Fidelity
The data	Every table in the packaged extract is written to your own cloud storage as Parquet, catalogued and queryable immediately.	Complete
Field names and roles	Dimensions and measures become the first draft of your business model, keeping the names your teams already use.	Complete
Calculated fields	Translated to the model's own expressions, deterministically — no language model involved, so the result is the same every time.	Most
Table calculations	Become a window pass outside the grouping, which is what a running total or a percent-of-total actually is.	Yes
FIXED level-of-detail	Becomes a derived table joined at its own grain — which is what keeps it constant however the view is grouped.	Yes
Sheets and layout	Worksheets become charts; the dashboard keeps its arrangement, so the page your team opens is the page they know.	Close
Sheet filters	Keep-only lists, exclusions, value and date ranges stay on the chart they belong to.	Yes
Quick filters	Become the dashboard's own controls, starting on the selection the workbook had, applying to the charts they applied to.	Yes
Filter actions	Click-to-filter carries: click a bar and the charts it pointed at still follow.	Yes
Parameters	Become interactive dashboard controls with the values the workbook offered.	Yes
Colours and number formats	Per-member colour assignments and formats carry, with a switch between the source palette and the product one.	Yes
Sort order	Carries, so a top-ten list is still the same ten in the same order.	Yes
Text and image tiles	Carry, including images packaged inside the workbook.	Yes
INCLUDE / EXCLUDE LOD	Reported against the sheet. They are defined relative to a specific view's dimensions, so they cannot be settled when the model is built.	Needs a person
Top-N and relative-date filters	Reported against the sheet they came from; that sheet is marked for review.	Needs a person
Manual sort order	Reported. An explicit drag-ordered list is not derivable from the data.	Needs a person
Power BI (.pbix)	Not yet. The report layer is readable JSON; the model needs the XMLA endpoint, which needs Premium.	Not supported

Why the filters are the whole game

If you remember one thing: the filters are what make the numbers match. A migration that carries the charts but not the filters produces a dashboard that looks right and is wrong, which is the worst possible outcome — worse than an obvious failure, because nobody investigates a page that looks familiar.

flowchart TD
    W["A Tableau workbook"] --> D["Packaged extract
.hyper"]
    W --> X["Workbook XML"]
    D --> P["Parquet in your cloud"]
    X --> M["Business model
fields + calculations"]
    X --> S["Sheets → charts"]
    X --> F["Sheet filters
quick filters
filter actions"]
    X --> R["Anything that
could not be carried"]
    P --> DB["A working dashboard"]
    M --> DB
    S --> DB
    F --> DB
    R --> RP["The review list
named, per sheet"]
    style P fill:#eef1ff,stroke:#c7cdf2
    style DB fill:#e6f7f2,stroke:#9fd8c9
    style RP fill:#fff4e6,stroke:#f0cb9a

Two files inside one archive. The .hyper is the data and becomes Parquet; the XML is every decision anyone made and becomes the model, the charts and the filters — or the review list.

Nothing is dropped quietly

A filter dropped silently is a chart with the wrong number on it. So whatever cannot be carried is named, against the sheet it came from, and that sheet is marked for review rather than passed as clean. A report that says “nine things need a person” is more useful than one that says “success” and leaves you to find them.

What the result actually looks like

A dashboard imported from a Tableau workbook, showing sales by region stacked by category and a monthly trend, with region and segment filter pills and a Min Sales parameter control carried across — **Note the top row.** “Region: 3 selected” and “Segment: 2 selected” are the workbook's own quick filters, arriving with the selections they had. “Min Sales: 100” is a Tableau parameter. The subtitle records which file it came from.

The colours are the workbook's, not ours, by default. That matters more than it sounds: people recognise a dashboard by its colours before they read the title, and a migration that repaints everything feels like a new tool even when the numbers are identical. There is a switch to adopt the product palette when you are ready.

Definitions-only files, and live connections

Not every file carries data. A .tds, a .twb, or a workbook whose extract was not packaged contains the decisions but not the rows. These import as drafts: the fields, calculations and dashboards arrive, and the report names the connection to wire up.

From there you point the model at a real datasource. The rebind only rewrites which physical tables the model reads — fields, calculations, formats and colours are untouched — and it reports every field whose column is missing rather than deleting it.

The model editor listing the imported dimensions and metrics with business names, types, formats and descriptions — **Where the workbook's decisions land.** Every field the workbook named, with its role and format. This is the draft your definitions conversation starts from — considerably more productive than a blank page and a whiteboard.

The part that is not automatable

Three things no importer will do for you, and pretending otherwise is how migrations overrun.

Deciding which dashboards deserve to survive. A typical estate has three to five times more dashboards than anyone uses. Migrating all of them is the most common and most expensive mistake. Start from usage logs, not from the file list.
Settling the definitions. When three teams' workbooks land in one model, somebody has to decide which definition of net revenue is the one. That is a business decision with consequences for people's targets, and it is the phase most likely to slip.
Checking the numbers. Export a crosstab from the original, compare it with the migrated dashboard, reconcile the differences. This is unglamorous and it is the step that decides whether anyone trusts the new estate.

Budget the fortnight after the import, not the import. The import takes minutes; agreeing what the numbers mean takes weeks, and it is the work that was always outstanding.

How to scope it in an afternoon

Pick your three worst workbooks — the oldest, the one with the most calculated fields, and the one the board uses. Not the clean ones.
Import them and read the reports. The ratio of converted to review across those three predicts the estate better than any survey.
Reconcile one dashboard properly. One, end to end, against an exported crosstab. You learn more from that than from migrating twenty.
Count the distinct definitions of your top five metrics across the three. That number is your real project plan.

Supported today: .twbx, .tdsx, .twb, .tds, .hyper, plus CSV and spreadsheet files.

The full business case, including the 90-day sequence → · Why the definitions disagree →

← All posts Request a demo