Tableau Server to Tableau Cloud: what actually has to move

Start from a real inventory, not a project list

A migration plan built from a list of project names is a plan built from a guess. Before anything moves you want an inventory of what exists, taken from the source server itself, with an owner against every item.

Six kinds of thing can be owned by a person on a Tableau site: workbooks, published data sources, flows, projects, subscriptions and refresh tasks. The first three are what people picture when they say content. The last three are where migrations go wrong, because they are invisible in a project tree and nobody notices they are missing until a Monday morning.

Record the identifier, not just the name. Names repeat across projects, get renamed halfway through a project, and are the reason a cherry-picked migration selects the wrong workbook. Selection keyed by LUID cannot make that mistake, and a parent project should be pulled in automatically when a child is chosen.

What moves, and what has to exist first

Content moves. The things around content mostly have to be present before it can land.

Workbooks, data sources, flows, custom views

The content a scoped migration moves. Scope by project, or cherry-pick individual items.

Users and groups

Identity is deliberately not scoped by project, because a workbook owner has to exist on the destination before the workbook can be owned there. User volume is controlled separately, by filtering, skipping or remapping.

Subscriptions and refresh tasks

Owned objects in their own right. They need an owner who exists and is licensed on the destination.

The Samples project

Auto-provisioned on every Cloud site and owned by a Tableau system account that cannot be resolved to one of your users. Migration tooling has to know to leave it alone.

Identity is the ordering constraint that catches teams out. Content cannot be owned by somebody who is not there yet. The sequence is not negotiable even when the calendar would prefer otherwise.

What breaks quietly

The failures that hurt are not the ones that throw an error during the run. They are the ones that leave a dashboard visibly present and quietly wrong.

• Embedded credentials. A data source that authenticated with a saved credential arrives unable to refresh. The first evidence is a stale extract, not a migration error.
• A missing owner. Content whose owner was never created on the destination has to be assigned to somebody, and whoever runs the migration is the usual accidental answer.
• Subscriptions and refresh tasks left without a live owner. The content works. It stops updating and stops arriving in inboxes.
• Content that moves across projects. Permissions in Tableau are inherited from where a thing sits. A move changes who can see it even when nothing about the workbook changed.
• Connections your new network cannot reach. Custom SQL against a host that was routable from the old server and is not from the new one fails at query time, per user, not at migration time.

Every item on that list is discoverable before you migrate, and none of them is discoverable from a project tree. That is the argument for the inventory step, and it is the only argument that survives contact with a deadline.

The dry run is the plan

A dry run that only validates credentials tells you the password is right. A useful dry run resolves the selection and then walks what the run would do, item by item, so the plan you approve is the plan that executes.

The Migrate tool runs the official Tableau Migration SDK on .NET 8 inside the same container as the rest of the suite. The migration itself uses the vendor-supported path rather than a re-implementation of it. A two-layer dry run precedes a hard approval gate with three enforced conditions.

Read the dry run in full. It is the last cheap moment in the project.

Approval, and what gets written down

The approval is the moment a named person takes responsibility. The record of it has to outlive the project team. A compliance audit is built from three plain inputs: the plan, the final state of the run, and the approval metadata.

It is rendered twice from one record. JSON for ingestion into a governance system, Markdown for a human reviewer or an audit file. One record, two renderings. The machine copy and the human copy cannot disagree.

Credential names and secret values never enter that audit. Endpoints, site names and types are recorded. A test enforces it.

Proving it landed

The honest end of a migration is a comparison, not a green status page.

1. Count content by type on both sides and reconcile every difference deliberately, including the ones you intended.
2. Re-run a quality check on a sample of workbooks and compare the numbers actually served, not only the files present.
3. Confirm every schedule exists on the destination and has completed at least one run.
4. Confirm every owner is a real, licensed user on the destination, and that no content quietly landed under the migration operator.
5. Trace one important dashboard from its tiles back to the warehouse column and look at where its data now comes from.

The last step is the one worth the hour. A dashboard that renders is not the same as a dashboard pointed at the right source, and the difference is invisible from the front.

A sequence that works

1. Inventory the source, including subscriptions and refresh tasks.
2. Fix ownership on the source first. Migrating content owned by somebody who left moves the problem instead of solving it.
3. Move identity, then projects, then content, then re-create schedules.
4. Run the dry run. Read it. Then approve it.
5. Take the after inventory the same day, while the plan is still fresh in your head.

Ownership first is the step people skip, because it feels like a separate project. It is also the step that turns a two-week migration into a four-week one when it is skipped, and the reason offboarding and migration are the same discipline viewed from two ends.