SharePoint Online から Box へ Box Shuttle で移行する

私ごとですが長年のPCライフで手元に膨大な量のデータが指数関数的に増えていく訳ですが

全部をHDDに保管するのも怖く、クラウドストレージに置いていました

色々考えてちょっとBoxにまとめようかな？と思ってBox Shuttleでデータ移行してみたので書いときます

社内のファイル基盤を SharePoint Online から Box へ寄せる、という案件はここ数年でかなり増えました。Box が公式に提供している移行ツールが Box Shuttle です。ファイル・フォルダだけでなく、所有者やコラボレーター権限、バージョン履歴まで運べるのが特徴で、ある程度の規模の移行であれば自前のスクリプトを書くより圧倒的に早い、というのが実際に触ってみた感想でした。

ただ、事前に知っていれば悩まずに済んだポイントがいくつかありました。この記事では、実作業でつまずいた／驚いた以下の 4 点を中心にまとめます。

1. 移行先 Box の容量上限（「無制限」のはずが、初期状態では上限がある）
2. SharePoint Online 側の権限まわり（ログインは通るのに、そこから先へ進まない）
3. 転送が裏で勝手に終わること（画面は静かなまま、手元のマシンも拘束されない）
4. ユーザー・バージョン・権限を、想像よりずっと細かく制御して移行できること

前提: Box Shuttle のジョブ構成をざっくり把握する

本題に入る前に、用語だけ整理しておきます。Box Shuttle での作業は「ジョブ」という単位で動き、大きく 2 種類あります。

• Analyze Data（分析ジョブ）: 移行元のデータを読み取って、種類・サイズ・更新日・権限などをレポート化するだけのジョブ。データは 1 バイトも動きません。
• Migrate Data（移行ジョブ）: 実際にデータを転送するジョブ。さらに「データのみ」と「データ＋権限（Migrate Permissions）」の 2 モードに分かれます。

そして移行ジョブには Simulation（シミュレーション） という模擬実行モードがあり、本番転送の前に所要時間の見積もりと、移行元・移行先の非互換（サイズ超過ファイル、Box 側が受け付けないシステムファイルなど）を洗い出せます。Box 自身も本番転送前のシミュレーション実行を強く推奨しています。

おすすめの進め方は「分析 → シミュレーション → 本番転送 → デルタ同期」です。特に大規模テナントでは、分析レポートを見て部署単位・サイト単位にジョブを分割したほうが、結果的に早く終わります。

移行元は SharePoint Online だけではない

この記事は SharePoint Online を題材にしていますが、Box Shuttle が対応している移行元はそれだけではありません。Google Drive（Google Workspace）からの移行にも対応しています。 標準で使える移行元は以下のとおりです。

加えて、標準では有効になっていない「Advanced（高度な）ソース」として、Azure Files、Azure Blob、Amazon S3、SharePoint Server（オンプレミス）、Citrix ShareFile にも対応しています。こちらは利用可否が契約や設定に依存するので、必要であれば Box に確認してください。

ここで押さえておきたいのは、クラウドサービスからの移行はいずれも「管理者として認証する」という同じ構造になっている点です。Google Drive であれば Google 管理コンソールへのアクセス権が必要、という具合です。つまり、この記事で扱う「認証は通るのに権限が足りずコンテンツが見えない」という落とし穴は、SharePoint Online に固有の話ではありません。移行元が Google Drive でも Dropbox でも、まず移行元サービス側の管理権限を整えるところから始まる、という点は共通しています。

なお、これらのサービスの個人アカウントにあるコンテンツは対象外です。個人アカウントからの移行が必要な場合は、Box のコンテンツ移行サービスに相談することになります。

最初にやるべきこと: 移行先 Box の容量上限を確認する

技術的な話に入る前に、プロジェクト全体のスケジュールに直結する確認事項を先に書いておきます。これは早ければ早いほどよい、というより、移行を検討し始めた時点で着手しておくべきものです。

「容量無制限」でも、初期状態には上限が設定されている

今回使ったのは Box のビジネスプラスプランです。このプランは容量無制限と案内されていますが、新規に開設したアカウントは、最初から無制限になっているわけではありません。 初期状態では組織全体のストレージ使用量に上限が設定されており、今回のケースではその値が 8 TB でした。

1.5 TB 程度の移行であれば 8 TB の枠内に収まりますが、移行対象が数 TB 規模になったり、複数のサイトやシステムを段階的に寄せていく計画だったりすると、この上限にぶつかります。しかも厄介なのは、上限に到達するのが移行の途中だという点です。転送が進んだところでアップロードが失敗し始め、原因を調べて初めて容量上限に気づく、という展開になりかねません。

なお、この 8 TB という数字が新規開設アカウント共通の初期値なのかどうかは、Box の公開ドキュメントからは確認できませんでした。プランや契約内容、開設時期によって異なる可能性があるので、数字を鵜呑みにせず、自分のアカウントの実際の値を確認してください。 ポイントは具体的な数値ではなく、「無制限をうたうプランでも、開設直後は上限が設定されていることがある」という事実のほうです。

確認方法

Box の管理コンソールから、以下で現在の使用量と上限を確認できます。

• Admin Console → Account and Billing → Usage: 組織全体のストレージ使用量と、設定されている場合は総容量の上限が表示されます
• Admin Console → Insights → Storage: Storage タイルから、より詳細な内訳を確認できます

あわせて、ユーザー単位の割当（Storage Allocated）も確認しておくとよいでしょう。これは組織全体の上限とは別の設定で、ユーザーごとに許可する容量を指定するものです。管理対象ユーザーが所有するフォルダーへのアップロードは、組織全体のストレージ割当にも計上されます。

上限の引き上げはサポート依頼。そして、待ち時間を織り込む

上限を引き上げるには、Box のサポートまたはアカウント担当者に依頼する必要があります。管理コンソールから自分で変更できる項目ではありません。

ここで強調しておきたいのが、この対応は基本的に早くないということです。依頼を出してその日のうちに枠が広がる、という類のものではなく、状況によっては相応の待ち時間が発生します。契約内容の確認が入ることもあり、やり取りが往復すればさらに伸びます。

したがって、移行スケジュールを引くときは次のように考えておくのが安全です。

• 移行データ量の見積もりが出た時点で、すぐに上限引き上げを依頼する。分析ジョブの結果が出たら、その足で連絡するくらいの温度感でよいです
• 依頼から反映までの待ち時間を、スケジュール上のバッファとして明示的に確保する。「サポートに投げたから大丈夫」と並行作業を進めると、本番転送の直前で足止めを食らいます
• 上限が引き上がったことを、管理コンソールの表示で自分の目で確認してから本番転送を開始する。回答をもらっただけで実際の設定が変わっていない、という食い違いを避けるためです

転送そのものは 1.5 TB が 7 時間半で終わるスピード感なのに、その前段の容量確保で数日待たされる、というのは笑えない話です。技術的な準備よりも先に、この事務的な手続きを動かしておくことを強くおすすめします。

1. 最大の関門は SharePoint Online 側の権限だった

ログインが通ることと、コンテンツが見えることは別問題

ここが一番ハマりどころです。

Box Shuttle で移行元として SharePoint Online を設定すると、Microsoft のサインイン画面にリダイレクトされます。ここで認証情報を入れてサインインが成功し、Box Shuttle の画面に戻ってくると、「よし、接続できた」と思ってしまいます。が、そこから先に進まないことがあります。

具体的には、次のような症状として現れます。

• ファイル選択画面（Select file locations）でサイト一覧が空、あるいは一部のサイトしか出てこない
• 分析ジョブを流しても、対象サイトのアイテム数が 0 件で終わる
• 権限移行ジョブの Examine（パス検証）で、対象サイトのパスがまとめてエラーになる

原因は、認証が通ったアカウントに、対象サイトそのものへのアクセス権が付いていないことです。Microsoft 365 の世界では「テナントの管理者である」ことと「個々の SharePoint サイトのコンテンツを読める」ことは別の話で、管理者ロールを持っていても、サイトコレクションのメンバーに入っていなければコンテンツは見えません。Box Shuttle は移行元アカウントの権限でコンテンツを読みに行くので、ここで素通りされてしまうわけです。

初回認証にはグローバル管理者が必要

Box の公式ドキュメントでは、新規テナントでの初回の SharePoint Online 管理者認証にはグローバル管理者が必要と明記されています。理由は、初回認証のタイミングでテナント内に Box Shuttle アプリケーションのサービスプリンシパル（アプリの実体）が作られるためです。加えて、そのグローバル管理者アカウントが SharePoint 管理センターにアクセスできる状態になっている必要があります。

このサービスプリンシパルの作成は初回だけなので、Box のドキュメントには「初回認証に使ったグローバル管理者のシステム設定は、移行の最後に削除してよい」とも書かれています。

事前チェックリスト

移行元の設定前に、以下を確認しておくと無駄な試行錯誤を減らせます。

4 つ目が今回の本題です。SharePoint 管理センターの「アクティブなサイト」から対象サイトを選び、サイト管理者（サイトコレクション管理者）に移行用アカウントを追加します。対象サイトが多い場合は、PowerShell で一括付与したほうが確実です。

# SharePoint Online 管理シェルでサイトコレクション管理者を一括付与する例
Connect-SPOService -Url "https://contoso-admin.sharepoint.com"

$migrationAccount = "migration-admin@contoso.com"

Get-SPOSite -Limit All | ForEach-Object {
    Set-SPOUser -Site $_.Url -LoginName $migrationAccount -IsSiteCollectionAdmin $true
}

移行が完了したら、この権限は忘れずに剥がします（-IsSiteCollectionAdmin $false）。移行用アカウントに全サイトの管理権限が残り続けるのは、セキュリティ上あまり褒められた状態ではありません。

切り分けの考え方

エラーの出方で原因を切り分けられます。

• そもそも認証画面で失敗する／Box Shuttle に戻ってこない → 初回のグローバル管理者認証、またはアプリケーション登録（Cloud FastPath / CFP Admin）の問題
• 認証は成功するが、特定のサイトだけ見えない・スキャンできない → そのサイトへのアクセス権の問題

前者はテナント全体の設定、後者はサイト個別の設定なので、見るべき場所がまったく違います。ここを混同すると延々と関係ない設定をいじることになるので、最初に切り分けておくことをおすすめします。

2. 転送は裏で勝手に終わる — 画面も、手元のマシンも縛られない

拍子抜けするほど静かに進む

移行ジョブを走らせて、まず意外だったのがこれです。画面上にエラーらしい表示が何も出ません。 転送が始まると進捗が淡々と伸びていくだけで、警告も赤字のログも出ないまま完走します。今回は 1.5 TB のデータが約 7 時間半で転送完了しました。平均するとおよそ 200 GB／時、秒あたり 55 MB 前後です。

一方で、これだけの量を SharePoint Online から短時間で吸い出していれば、Microsoft 側のスロットリング（流量制限）には確実に引っかかっているはずです。大量のリクエストを投げれば 429 Too Many Requests が返るのは Microsoft の仕様であって、移行ツールの側で避けられるものではありません。

それでも画面が静かなままなのは、Box Shuttle が裏側でスロットリングを受け止めて、待機と再試行を勝手にこなしているからです。運用する側からは「何も起きていない」ように見えるけれど、実際には水面下でリトライが回り続けている、というのが実態に近いはずです。

結論として、転送中にオペレーターがやることはありません。画面を眩めて異常がないか監視する必要すらなく、開始したら放っておいてよい。ここは移行計画を立てるうえで地味に効いてくるポイントでした。

rclone のようなツールとの決定的な違い

そして、これが今回いちばん「助かった」と感じた点です。転送はすべて Box 側のインフラで完結するので、手元のマシンを動かし続ける必要がありません。

同じことを rclone や自前のスクリプトでやろうとすると、話がまるで変わります。転送を実行するマシンを 7 時間半のあいだ起動しっぱなしにしなければならず、そのあいだずっと次のような心配がついて回ります。

• 端末がスリープしたら転送が止まる。電源設定やカフェインスタンバイの準備が要る
• ネットワークが切れたり、社内ネットワークへの接続が切断されたりすると、そこで中断する
• 端末を再起動できない、持ち出せない、別作業で負荷をかけられない
• 長時間の接続を維持するために screen や tmux、あるいは専用のサーバーを別途用意する羽目になる
• 転送の間じゅう、手元の回線の帯域を占有する

要するに、転送のあいだ 1 台のマシンを人質に取られるわけです。しかも夜間に流すなら、翌朝まで止まっていないことを祈るしかありません。

Box Shuttle はここが根本的に違います。ジョブを開始してしまえば、ブラウザを閉じても、パソコンをスリープさせても、その日の仕事を終えて帰っても、転送は裏で進み続けます。 翌朝あらためて管理画面を開けば、結果が出ている。夕方にジョブを開始して翌朝に結果を確認する、という進め方が何の工夫もなく成立するのは、この仕組みのおかげです。

移行ツールを選ぶとき、つい転送速度や対応機能の比較表に目が行きがちですが、「自分のマシンを縛られないこと」は想像以上に効いてきます。 特に移行が複数回に分かれる場合や、並行して別の作業を進めたい場合には、ここが作業全体の進み方を変えます。

裏側で何が起きているのか

429 Too Many Requests は、Microsoft が「短時間にリクエストを送りすぎたので少し待ってほしい」と返しているサインです。サービス全体の安定性を守るための仕組みなので、大量移行では発生して当たり前のものだと考えてください。

Microsoft は単純なリクエスト数ではなく「リソースユニット」というコスト換算のモデルで制限をかけており、たとえば権限関連の操作（$expand=permissions など）は単一アイテムの取得より 5 倍のコストが計上されます。つまり権限込みの移行ジョブは、データのみの移行よりスロットリングを受けやすいということになります。

そして 429 のレスポンスには Retry-After ヘッダーが付いていて、「何秒待てば再試行してよいか」が秒数で示されます。ここを正しく処理できるかどうかが、移行ツールの出来を分けます。 待たずに即リトライすると制限期間はさらに延び、Microsoft のドキュメントでも Retry-After を無視して攻撃的にリトライするアプリケーションはブロック対象になりうると明記されています。

自前の PowerShell スクリプトで移行しようとすると、このバックオフ制御を自分で実装しなければなりません。雑に書くと「リトライすればするほど遅くなる」という罠にはまりますし、そもそもエラーハンドリングとログ管理を一式作り込む必要があります。Box Shuttle を使っていてスロットリングをまったく意識せずに済んだのは、この面倒な部分がツールに内包されているからです。画面に何も出ないのは情報が足りないのではなく、利用者が判断する必要のないところまで処理してくれている、ということだと理解しています。

速度が気になるときに触れる項目

スロットリング自体は避けられませんが、頻度を下げて全体のスループットを上げる手は打てます。今回は特に調整せずとも十分な速度が出ましたが、テナントの状況によっては効いてくるはずです。

• 帯域スイッチを絞る: ジョブのサマリー画面に、移行元からのアップロード速度を調整するスライダーがあります。右端に振り切ると制限なしの最大速度になりますが、テナントが混んでいる時間帯はあえて絞ったほうが安定することがあります。
• 業務時間外に流す: テナント全体の負荷が下がる夜間・早朝のほうが、使えるリソース枠に余裕があります。
• ジョブを分割し、同時実行数を抑える: 分析レポートを使ってサイト単位・部署単位に分けると、1 ジョブあたりの負荷が下がります。
• バージョン履歴を事前に整理する: 全バージョン移行を選ぶ場合、バージョン数がそのまま API 呼び出し数に効いてきます。不要な履歴を移行前に削っておくのは、費用対効果の高い準備作業です。

なお、Microsoft は「サポートチケットを起票してもスロットリングは解除しない」と公式に明言しています。サービス全体の安定性を守るための仕組みなので、緩和交渉をするのではなく、付き合い方を設計するのが正解です。

3. ユーザー・バージョン・権限を、想像以上に細かく移行できる

ここからは Box Shuttle の良いところです。「とりあえずファイルを全部コピーする」だけのツールではなく、移行後の運用を見据えた制御ができます。

アカウントマッピング — 誰のデータを、誰に渡すか

権限移行ジョブでは、移行元のユーザー／グループと移行先の Box アカウントを対応づける「アカウントマッピング」を行います。Box Shuttle は以下の順で自動マッチングを試みます。

1. 移行元コンテンツの初回スキャン時に、全ユーザー・グループ・権限を棚卸しする
2. 移行先の Box 側のユーザーとグループをスキャンする
3. 所有者とコラボレーターの権限、移行先のパスを突き合わせ、最適な組み合わせを自動で割り当てる

たとえば username@mycompany.com という SharePoint アカウントは、同じメールアドレスの Box アカウントに自動で紐づきます。部署グループや地域拠点のグループ、法務のようなアクセス制限グループも、対応する Box のグループへマッピングされます。

自動で決まらなかったユーザーは、マッピング画面に「未マッピング」として残ります。ここで手動で移行先ユーザーを選ぶか、チェックを外してスキップするかを決めます。すべてのアカウントをマッピングかスキップのどちらかに確定しないと次へ進めない仕様なので、退職者や Box 側にアカウントがない人の扱いを曖昧なまま流してしまう事故は起きにくくなっています。

ひとつ注意点があります。移行対象として選んだアカウント（データの所有者）のチェックを外すと、そのユーザーのデータごと移行対象から外れます。「このユーザーは権限だけ要らない」つもりでチェックを外すと、データが丸ごと落ちるので気をつけてください。

バージョン履歴 — ここだけは後戻りできない

移行ジョブの設定途中で、バージョンの扱いを選びます。

• Migrate current version only（現行バージョンのみ）
• Migrate all versions（全バージョン）

全バージョンを選んだ場合、バージョン 1 から順番に移行されます。そして重要なのが、現行バージョンのみを選んで移行した場合、あとから過去バージョンだけを追加移行することはできないという点です。ここは不可逆なので、移行計画のかなり早い段階で「履歴要件」を関係部署に確認しておく必要があります。

内部統制や監査対応で過去バージョンの保持が求められる部署がひとつでもあると、後から「やっぱり履歴が必要でした」となったときに再移行が発生します。全バージョン移行は転送量も API 呼び出し数も増える（＝スロットリングも受けやすい）ので、コストとのバランスを取りながら、サイト単位で方針を分けるのが現実的でしょう。

権限とコンフリクト解決 — 3 つの選択肢

SharePoint と Box では権限モデルが異なるため、そのまま 1 対 1 で移せないケースが必ず出てきます。典型的なのは、親フォルダーより子フォルダーのほうが権限が狭い（あるいは広い） というパターンです。Box Shuttle はこれを「権限コンフリクト」として検出し、ジョブ設定時に解決方法を選ばせます。

セキュリティ観点では Restrict か Skip が安全側です。Expand は運用は楽ですが、「親フォルダーにアクセスできる全員が、本来見えてはいけなかった子フォルダーを見られるようになる」リスクがあります。機密情報を含むサイトでは、Expand を安易に選ばないほうがよいでしょう。

また、権限移行ジョブでは転送前に Examine（パス検証） が走り、移行元のアイテムが移行先に正しくマッピングできるかを確認します。エラーが出た場合は View Errors から内容を確認でき、全パスのリストを CSV でダウンロードして精査することもできます。修正後に Re-examine paths で再検証、どうしても解決できないパスは Skip paths and continue で飛ばす、という流れです。

Mirror Deletions は慎重に

ジョブのサマリー画面に Mirror Deletions というチェックボックスがあります。これを有効にすると、移行元に存在せず移行先にだけあるファイルが削除されます。デルタ同期で移行元の削除を反映させたいときには有用ですが、設定を誤ると Box 側のデータが消えます。

Box のドキュメントでも「動作を理解せずに有効化しないこと」「Mirror Deletions を使う場合は必ずシミュレーションを実行して結果を確認すること」と繰り返し警告されています。ここは素直に従うべきところです。

4. 実績: 1.5 TB を 7 時間半、残ったエラーは 2 件だけ

ここまでの設定を済ませて本番転送を流した結果が、こちらです。

1.5 TB を一晩で終えられる計算なので、業務時間外に開始しておけば翌朝には完了している、という進め方が十分成立します。夕方に開始して翌朝に結果を確認する、というスケジュールを組めるのは、移行計画を立てるうえでかなり大きなポイントでした。

残ったエラーはファイル名の問題 2 件だけ

これだけの量を流して、最後まで解消しなかったのは書き込みエラー 2 件のみでした。しかも内容はどちらもファイル名に起因するもので、データの破損でもネットワークの問題でもありません。

SharePoint と Box では、ファイル名に使える文字や長さの制限が異なります。SharePoint 側では問題なく保存できていた名前が、Box 側の命名ルールに引っかかって書き込みに失敗する、というのがこのエラーの正体です。よくある原因は次のあたりです。

• Box 側で使用できない文字が含まれている
• 名前の末尾がスペースやピリオドで終わっている
• フォルダー階層を含めたパス全体が長すぎる

対応はシンプルで、移行元のファイル名を変更してからリトライするだけです。転送結果の画面からエラー一覧を確認し、該当ファイルを特定して、SharePoint 側で名前を修正します。あとはもう一度ジョブを走らせれば、差分として該当ファイルだけが転送され、それで完了しました。1.5 TB の移行で手作業が必要だったのは、結局このリネーム 2 件だけだった、ということになります。

なお、この手のエラーはシミュレーションの段階でも検出できます。Box のドキュメントにも、シミュレーションで洗い出せる非互換の例として「サポートされる最大サイズを超えるファイル」や「thumbs.db などのサポート外のシステムファイル」が挙げられています。本番転送の前にシミュレーションを回して結果を確認し、引っかかりそうなファイル名を先に直しておけば、事後のリトライすら不要にできます。今回は 2 件で済んだので後追いで対応しましたが、件数が多いテナントでは事前にまとめて処理したほうが効率的でしょう。

実務での進め方（まとめ）

最後に、ここまでの内容を作業順に整理します。

フェーズ 0: 容量の確保（最優先・リードタイムが読めない）

1. Admin Console → Account and Billing → Usage で、組織全体のストレージ上限を確認する
2. 移行データ量が上限を超えそうなら、即座に Box のサポートまたはアカウント担当者へ引き上げを依頼する
3. 依頼から反映までの待ち時間を、スケジュールにバッファとして確保する
4. 引き上げが反映されたことを管理コンソールの表示で自分の目で確認する

フェーズ 1: 権限の準備

1. グローバル管理者アカウントを用意し、SharePoint 管理センターへのアクセスを確認する
2. Microsoft Entra 管理センターで Cloud FastPath と CFP Admin の登録を確認する
3. 移行対象サイトに、移行用アカウントをサイトコレクション管理者として追加する（PowerShell での一括付与を推奨）
4. Box 側は、管理者または Shuttle 権限を付与された共同管理者でログインできることを確認する

フェーズ 2: 分析と計画

1. Analyze Data ジョブを実行し、データ量・種類・権限の実態を把握する
2. 判明したデータ量をフェーズ 0 の容量見積もりに反映する（不足しそうならこの時点で追加依頼）
3. レポートをもとにジョブを分割し、サイト・部署ごとにバージョン方針（現行のみ／全バージョン）を決める
4. 権限コンフリクトの解決方針（Expand / Restrict / Skip）を、セキュリティ要件に照らして決める

フェーズ 3: シミュレーション

1. Simulation を実行し、所要時間の見積もりと非互換ファイルの一覧を確認する
2. アカウントマッピングの未マッピングユーザーを、マッピングかスキップに確定させる

フェーズ 4: 本番転送

1. 業務時間外に転送を開始する。帯域スイッチはテナントの状況に応じて調整する（1.5 TB で約 7 時間半なので、夕方開始・翌朝確認が組める）
2. 開始したら放っておく。スロットリングはツールが内部で処理するため、画面上は何も起きずに進む
3. 完了後、結果を確認し、書き込みエラーが残っていれば対応する。ファイル名起因であれば移行元でリネームしてジョブを再実行すれば差分として転送される
4. 結果を XLSX でエクスポートして記録を残す

フェーズ 5: 並行期間とカットオーバー

1. デルタ同期で差分を追従させる
2. 移行完了後、SharePoint Online 側に付与した移行用アカウントの権限を剥がす

おわりに

Box Shuttle での SharePoint Online 移行でいちばん時間を取られるのは、実はデータ転送そのものではなく、その前段の準備でした。移行先 Box の容量上限はサポート依頼が必要なうえ対応に時間がかかりますし、移行元の権限は「ログインできているのに何も見えない」という、エラーメッセージも親切ではない状態で立ち止まります。どちらも技術的な難易度が高いわけではないのに、知らないと日単位で時間を持っていかれます。

逆に、権限さえ通ってしまえば、あとは驚くほど静かに終わります。1.5 TB が約 7 時間半で転送完了し、その間ずっと画面にはエラーひとつ出ませんでした。スロットリングは確実に起きていたはずですが、Box Shuttle が黙って処理してくれていたわけです。そして rclone などと違い、転送は Box 側で完結するので手元のマシンを起動し続ける必要がありません。夕方にジョブを投げて帰り、翌朝に結果を確認するだけ。この「マシンを縛られない」という一点は、事前に想像していたよりずっと大きな価値がありました。最後まで残ったのはファイル名に起因する書き込みエラー 2 件だけ。それもリネームしてリトライすれば片付く程度のものでした。ユーザーマッピング・バージョン履歴・権限コンフリクトの扱いも想像よりずっと細かく制御できます。特に「現行バージョンのみを選ぶと後から履歴を追加できない」という不可逆な仕様は、計画段階で押さえておく価値があります。

そして冒頭でも触れたとおり、Box Shuttle の移行元は SharePoint Online だけではありません。Google Drive、OneDrive for Business、Dropbox for Business、Windows ファイルサーバーからでも同じ流れで移行できます。容量上限の確認、移行元サービスでの管理権限の付与、シミュレーションでの事前検証、そして放っておけば終わる転送——この記事で書いた勘所は、移行元が変わってもだいたいそのまま当てはまるはずです。

これから同じ移行を検討している方の、遠回りを少しでも減らせれば幸いです。

参考リンク

• Migrating Content from SharePoint Online to Box（Box Support）
• Viewing Organization Storage and Bandwidth Usage（Box Support）
• About Source System Configuration（Box Support）
• Introducing Box Shuttle（Box Support）
• Avoid getting throttled or blocked in SharePoint Online（Microsoft Learn）
• Migration performance guide for SharePoint & OneDrive（Microsoft Learn）