What a Tableau Server to Cloud migration actually costs

Not on technology. On inventory. Nobody knows how many workbooks exist, which ones anyone opens, what they depend on, or who owns them.

So work starts on the visible reports. The deadline arrives. The last twenty percent turns out to contain the ones the executive team uses, and those are the ones with the most complex dependencies and the least documentation.

The technical execution is often the easiest part of the program. That is counterintuitive enough that most plans are built as though the opposite were true.

The Validation row deserves attention. Teams plan conversion effort carefully and then discover there is no agreed test for whether a migrated report is correct. Without that definition, every asset becomes a negotiation with its owner.

Access and provisioning looks trivial and is chronic. Security reviews, service accounts and credential approvals move at the client IT department's pace, not the project's, and they gate work that is otherwise ready.

An estimate produced before the inventory exists is a guess. Two weeks of counting produces a defensible scope, a rationalisation list and an estimate that is not fiction.

That is often the most valuable two weeks of the program, and it can be bought as a short standalone engagement before anyone commits to a number. Any provider unwilling to sell it separately is quoting on a scope they have not verified either.

The inventory should cover data sources, workbooks, extracts, schedules and permissions, with usage data attached and a named owner per asset.

Every mature deployment contains reports nobody opens. Usage data plus a named owner resolves them: a workbook with no views in twelve months and no owner willing to claim it gets archived with a documented decision rather than migrated.

This routinely removes a material share of scope, and it is the only phase where the deliverable is less work.

It requires air cover, because someone always objects on principle to archiving a report they do not use. That objection is political rather than analytical, and it needs a sponsor rather than an argument.

These programs typically involve three organisations: the client's IT function, a partner consultancy executing conversions, and internal business owners approving results. Each holds part of the plan, and the default failure is three partial plans and no shared status.

The fix is consolidation rather than more meetings. One tracker every party reads, one point of contact for the client's IT director, one validation standard applied to every asset, and process documentation stakeholders use to approve each phase.

An enterprise transit technology provider ran exactly this shape: 154 SAP HANA data sources, more than 100 workbooks, a hard vendor end-of-life deadline, and an internal team that had never run a platform migration. Delivery lead owned inventory, sequencing, client IT coordination and the tracker while a partner consultancy's developers executed the conversions. All 154 data sources migrated with zero unplanned production outages, inside the vendor deadline.

That division — delivery lead rather than sole implementer — is worth stating in the statement of work rather than discovering during it.

Fixed fee after the inventory, or banded hours with the band's assumptions written down. Fixed fee before the inventory is a number invented to win the work, and it will be renegotiated.

Carve the genuinely unknown parts into a separate discovery phase with its own small fixed fee rather than burying them in a buffer. Buffers get negotiated away first because they look like padding, which leaves the risk and removes the cover.

That is the same discipline that applies to any fixed-fee technical project: the margin is decided in the scope document, not during delivery. If the document has no assumptions list and no exclusions, the estimate is not protected regardless of how good it was.