What breaks in a Server to Cloud move, and how to find it first

The attachments that travel separately

Content is the part everyone plans for, and it is the part that mostly survives. What sits around a workbook is a set of separate objects, each with an owner, most with a schedule, and none of them visible in a project tree.

Custom views

A saved personal state of a workbook, one per person who made one. They ride the workbooks they belong to and are included by default.

Subscriptions

A scheduled delivery to somebody’s inbox, owned by whoever created it. After a move the workbook opens perfectly well; the email stops arriving, and the person waits a week before mentioning it.

Extract refresh tasks

What keeps the numbers current. A dashboard without one renders exactly as it always did, using last month’s data, which is the most expensive failure on this page.

Flow run tasks

Scheduled runs that reference flows. They error unless the flows move in the same run.

Favourites

Small, personal and quickly noticed. Usually the first absence a user reports, and the one that shapes their opinion of the whole project.

Alerts and the schedules behind them belong in the same enumeration, for the same reasons: a person created them, they live on the source, and their owner has to exist on the destination for them to mean anything. Some attachment types have no direct equivalent on a Cloud site, and where that is true the honest plan is to re-create them deliberately, not expect a transfer.

What a default run carries, and what waits to be ticked

Each optional type is chosen explicitly, and the defaults have a reason behind them. Custom views ride workbooks and are on. The schedule and task types are off, because they often need conversion and will error when the content they attach to sits outside the same run.

The consequence is worth saying plainly, because it is the most common route to a quiet Monday: a run configured in a hurry moves the content, leaves the schedules behind, and reports success at every step. Nothing failed. The schedules were never in scope, and a report of a clean run is a true statement about a smaller job than anybody thought they had approved.

The pre-flight preview lists what is included and what is skipped, by name, before anyone approves. That one line is the highest-value sentence in the whole preview and the easiest to scroll past on the way to the counts.

Dependencies appear there as well. Flow run tasks reference flows: ticking the tasks while flows stay out of the run leaves them nothing to attach to, and they will error in the manifest. The preview says so in advance.

Ownership decides what actually lands

Identity is deliberately not scoped by project, because content cannot be owned on the destination by somebody who is not there yet. That ordering constraint is the one teams most often meet late, usually on the day the calendar has already committed to.

Preserving the original owner is the default, and the owners of everything in the selection are pulled into the user scope automatically so a run does not fall over on a missing one. What still catches people is an owner who resolves to no email-style Tableau ID: with preserve-owner their content errors or is skipped on publish, and that is the single most common reason a migration comes back nearly empty. The preview names it, with a count and a sample of the accounts concerned.

• Publishing under the connecting account is a legitimate choice with a consequence: every item arrives owned by whoever connected. The attachments then belong to the wrong person by construction and have to be re-homed afterwards.
• Content whose owner cannot be resolved is republished under the connecting account without stopping the run. One unresolvable owner costs you an item to fix, not the whole batch.
• Tableau’s own Samples project is left where it is. It is provisioned automatically on every Cloud site and owned by a system account that resolves to none of your users. It is skipped, not attempted.
• Selection is keyed by identifier rather than by name, and the projects containing a chosen item come with it, so a rename halfway through a project cannot quietly send the wrong workbook.

Connections that worked because of where the server sat

Two kinds of connection arrive looking healthy and behave differently afterwards.

The first is credentials. Published data sources and live connections may need re-authenticating on the destination before extract refreshes succeed. This is Tableau platform behaviour and it applies to any move, which is why the preview states it on every run whatever else is in scope. The first evidence is normally a stale extract, not an error.

The second is reachability. A connection that resolved from a machine inside your own network may not resolve from a hosted site, and that failure arrives at query time, for one person at a time, long after the migration report went green. List every connection by host before the move and mark the ones whose reachability depends on where the server sits.

• Publishing overwrites. An item of the same name in the destination project is replaced, and its previous version survives only in Tableau’s revision history. A re-run without the saved manifest overwrites again.
• When permissions migrate, a grantee that did not transfer is skipped for that grant. Access can end up narrower than it was on the source.
• When permissions are left out of the run, content takes the destination project’s existing default permissions instead. Either way, destination access is worth reading after the run.

Permissions in Tableau are inherited from where a thing sits, so content that lands in a different project has a different audience even though the workbook itself is unchanged. Check the ones that moved projects first.

Enumerating them before the move

The whole job is a count taken twice. Take the first one while the source is still running.

1. List every attachment on the source by type, with an owner and an identifier against each: custom views, subscriptions, extract refresh tasks, flow run tasks, favourites, and any alerts.
2. Count them by type. The count is what you reconcile against afterwards, and a list of names is no substitute.
3. Decide for each type, deliberately: move it, re-create it on the destination, or let it go. Write the decision beside the count.
4. Confirm every owner and every proposed target owner is a real, licensed user on the destination.
5. List connections by host, and mark those whose reachability depends on where the server sits.
6. Read the preview, find the line naming what is included and what is skipped, and check it against the decisions you wrote down.
7. Read the manifest after the run, including the errors you expected. An expected error you cannot find is a decision that never took effect.

Six of those seven steps happen before anybody approves anything, and together they are the cheapest hour in the project. The seventh is the one that tells you whether the other six were true.

The Monday after, and the count that settles it

A post-migration support queue is made of things that are present and quiet. A report nobody is subscribed to any more. An extract that has not refreshed since the move. A personal view somebody had kept for a year. None of them raises an error and none of them appears on a status page. They are reported by users, not by monitoring.

The reconciliation is a count, taken on both sides, by type, compared line by line, with every difference explained on purpose, including the differences you chose. A difference you can name is a decision. A difference you cannot name is a finding, and it is much cheaper as a finding this week than as a discovery next quarter.

Do it in the same week. While the source is still running, a missing subscription is a five-minute fix and a missing refresh task is a form. Once the source is switched off, the same two questions become archaeology, and the person who knew the answer has already started the next project.

The before-count and the after-count belong in one document, taken by the same person, in the same units. Two counts, in two places, in two formats, is how a reconciliation quietly turns into a conversation about methodology.