Tableau Server から Tableau Cloud へ：実際に動かさなければならないもの

プロジェクト一覧ではなく、本物のインベントリから始める

プロジェクト名のリストから作った移行計画は、推測から作った計画です。何かを動かす前に、ソースサーバー自身から取った、すべての項目に所有者が付いた、何が存在するかのインベントリが欲しいところです。

Tableau サイトで人が所有できるものは6種類あります：ワークブック、パブリッシュ済みデータソース、フロー、プロジェクト、サブスクリプション、更新タスク。最初の3つは、人が「コンテンツ」と言うときに思い浮かべるものです。最後の3つは移行が失敗する場所です。プロジェクトツリーには見えず、月曜の朝までなくなっていることに誰も気づかないからです。

名前だけでなく識別子を記録してください。名前はプロジェクトをまたいで重複し、プロジェクトの途中で改名され、選り抜きの移行が間違ったワークブックを選ぶ原因になります。LUID でキー付けされた選択はその間違いを犯せず、子が選ばれたときには親プロジェクトが自動的に引き込まれるべきです。

何が動き、何が先に存在していなければならないか

コンテンツは動きます。コンテンツの周りにあるものは、たいていコンテンツが着地する前に存在していなければなりません。

ワークブック、データソース、フロー、カスタムビュー

範囲を定めた移行が動かすコンテンツ。プロジェクト単位で範囲を決めるか、個別の項目を選り抜きます。

ユーザーとグループ

ID は意図的にプロジェクトで範囲を切りません。ワークブックの所有者は、そのワークブックが移行先で所有される前に、移行先に存在していなければならないからです。ユーザーの量は、フィルター、スキップ、再マッピングで別に制御します。

サブスクリプションと更新タスク

それ自体が所有されるオブジェクトです。移行先に存在し、ライセンスを持つ所有者を必要とします。

Samples プロジェクト

すべての Cloud サイトに自動でプロビジョニングされ、あなたのユーザーの誰にも解決できない Tableau のシステムアカウントが所有します。移行ツールは、それに触れないことを知っていなければなりません。

ID は、チームを引っかける順序の制約です。まだそこにいない誰かがコンテンツを所有することはできません。カレンダーがどれだけ別の順序を望んでも、この順番は交渉の余地がありません。

静かに壊れるもの

痛い失敗は、実行中にエラーを投げるものではありません。ダッシュボードが目に見えて存在し、静かに間違っている状態を残すものです。

• 埋め込まれた認証情報。保存された認証情報で認証していたデータソースは、更新できない状態で届きます。最初の証拠は移行エラーではなく、古い抽出です。
• 所有者の欠落。移行先に作られなかった所有者のコンテンツは誰かに割り当てなければならず、移行を実行した人がいつもの偶然の答えになります。
• 生きた所有者のいないサブスクリプションと更新タスク。コンテンツは動きます。更新が止まり、受信箱に届かなくなります。
• プロジェクトをまたいで動くコンテンツ。Tableau のパーミッションは置き場所から継承されます。ワークブックについて何も変わっていなくても、移動は誰が見られるかを変えます。
• 新しいネットワークから到達できない接続。古いサーバーからは到達できて新しいサーバーからはできないホストへのカスタム SQL は、移行時ではなく、ユーザーごとに、クエリ時に失敗します。

そのリストのすべての項目は移行前に発見でき、どれもプロジェクトツリーからは発見できません。それがインベントリの段階を置く根拠であり、締め切りに触れても生き残る唯一の根拠です。

ドライランが計画

認証情報を検証するだけのドライランは、パスワードが正しいことを教えてくれます。役に立つドライランは選択を解決し、実行が行うことを項目ごとにたどるので、承認する計画が実行される計画になります。

Migrate ツールは、スイートの残りと同じコンテナの中で、公式の Tableau Migration SDK を .NET 8 上で動かします。移行そのものは、再実装ではなくベンダーがサポートする経路を使います。2層のドライランの後に、3つの強制された条件を持つ厳格な承認ゲートが続きます。

ドライランを最後まで読んでください。それがプロジェクトで最後の安い瞬間です。

承認と、書き留められるもの

承認は、名前のある人が責任を引き受ける瞬間です。その記録はプロジェクトチームより長生きしなければなりません。コンプライアンス監査は3つの平易な入力から組み立てられます：計画、実行の最終状態、そして承認のメタデータ。

ひとつの記録から二度描画されます。ガバナンスシステムへの取り込み用の JSON と、人のレビュアーや監査ファイル用の Markdown。ひとつの記録、2つの描画。機械のコピーと人のコピーが食い違うことはありません。

認証情報の名前と秘密の値は、その監査に決して入りません。エンドポイント、サイト名、種類は記録されます。テストがそれを強制しています。

着地したことを証明する

移行の誠実な終わりは、緑のステータスページではなく、比較です。

1. 両側でコンテンツを種類ごとに数え、意図したものを含めてすべての違いを意識的に突き合わせます。
2. ワークブックのサンプルで品質チェックを再実行し、存在するファイルだけでなく、実際に提供される数値を比較します。
3. すべてのスケジュールが移行先に存在し、少なくとも一度実行を完了していることを確認します。
4. すべての所有者が移行先で実在するライセンス付きユーザーであり、移行オペレーターのもとに静かに着地したコンテンツがないことを確認します。
5. 重要なダッシュボードをひとつ、タイルからウェアハウスの列までたどり、そのデータが今どこから来ているかを見ます。

最後の段階が、1時間をかける価値のあるものです。描画されるダッシュボードは、正しいソースを指すダッシュボードと同じではなく、その違いは正面からは見えません。

うまくいく順序

1. サブスクリプションと更新タスクを含めて、ソースをインベントリします。
2. まずソースで所有を直します。去った人が所有するコンテンツを移行しても、問題を解決するのではなく移動させるだけです。
3. ID、次にプロジェクト、次にコンテンツを動かし、それからスケジュールを作り直します。
4. ドライランを実行し、読み、それから承認します。
5. 計画がまだ頭にあるうちに、同じ日に移行後のインベントリを取ります。

所有を先に、というのは人が飛ばす段階です。別のプロジェクトのように感じるからです。飛ばせば2週間の移行が4週間になる段階でもあり、オフボーディングと移行が両端から見た同じ規律である理由でもあります。