「SharePoint のデータを移行したいけど、何から始めればいいの？」という方を対象に、移行プロジェクトの進め方を説明します。
●この記事の目次
移行プロセスの概要
まず最初に、移行プロジェクトの進め方の大まかな流れを説明します。
下の図の通り、現状分析⇒要件確認・移行方針確定⇒移行計画・移行準備⇒リハーサル・パイロット・本番移行というステップで進めるのが王道です。規模等によりスキップできるステップもありますが、基本はこの流れで進めることをお勧めします。
なお、本記事では、ShareGate Migration Tool を利用することを前提としております。ShareGate Migration Tool は、SharePoint 移行を行うツールとして必要な機能を網羅しており、ライセンス費用も安価です。手作業で移行を実施する場合と比較すると大幅に作業工数を削減できるため、SharePoint のデータ移行を行う際には、是非、検討しましょう。
Step１．現状分析
SharePoint 移行で一番大事な工程となります。
ここをおろそかにすると、計画通りに進まなかったり、本番移行で想定外な事が多発してしまいます。
では、具体的に何をすればよいか？について、説明します。
※現状分析は、ShareGate の試用版で実施しましょう。
ShareGate の試用版は、すべての機能が網羅されており、現状分析が可能です。
ライセンスを購入せずに、現状分析とツール評価が一緒にできるので、お勧めです。
ただし、ShareGate の試用版で移行を実施してもランダムでデータが抜け落ちるので、本番移行には使えません。
※試用版のお申し込みはこちら
(1)環境調査
ShareGate から移行元と移行先の SharePoint に接続が出来るかの確認を行います。Microsoft 365 の認証方式やプロキシサーバー、ファイアウォール、証明書などのネットワーク環境によっては ShareGate で接続できないため、これらの問題を解決し、接続できるようにする必要があります。ShareGate のExplorer メニューの Add Connection から実施します。
※Microsoft 365 への接続時のトラブルシューティングはこちら
※SharePoint オンプレミス環境接続時のトラブルシューティングはこちら
(2)現行の SharePoint 環境の調査
移行計画のため、SharePoint 内の調査を実施します。具体的に何の調査を行うかを説明します。
(2-1)Source analysisを取得
サイトコレクションレポートを取得する事によって、以下の情報が取得できます。
- サイトコレクションの個数
- サブサイトの個数
- 各サイト単位のサイズ（サイトコレクションのサイズにサブサイトのサイズは含まれません）
- エラーや警告
1～3の内容は、移行計画時の移行スケジュール、実行台数の計画や実行端末の割り当てなどに利用します。
4のエラーや警告は、以下のような観点で取得できます。
● 3rdパーティー製品の機能
● カスタマイズされた機能やテンプレート
● チェックアウトされたアイテム・ファイルの数
● 接続できないサイトコレクション
これらの内容に対して、要件確認時に移行先でどうするかの方針を確定させる必要があります。
(2-2)サイトコレクションレポートを取得
サイトコレクションレポートを取得する事によって、以下の情報が取得できます。
● サイトテンプレート
● 設定言語
これらは、移行先のサイトテンプレートをどうするか要件確認で提示します。ここで、移行元は異なるテンプレートで移行すると、移行先でその機能が移行できなくなる可能性があります。また、移行先の環境に無いサイトテンプレートが移行元に存在している場合は、利用している機能を諦めるから膨大な費用をかけて構築する必要があります。3rdパーティ製品を導入して、追加されたサイトテンプレートの場合、移行先に対象の3rdパーティ製品を導入できるか確認します。これらについては、正しく移行が出来るかどうかの事前調査を行う事を推奨します。
(2-3)巨大なサイトコレクションに対してサイトレポートを取得
● サイト毎のサイズ
● サブサイトが多いサイトの特定
● サブサイトの階層数
これらを調査することで、サブサイト単位で移行が可能かどうかを知ることが可能になります。
(2-4)Unused site report を取得
Unused site reportを取得する事によって、未更新のサイトの情報が取得できます。指定した期間で更新の無かったサイトを抽出し、要件確認の際に、利用していないと判断できるサイトは移行対象外にするなど工数削減が可能となります。
※この調査では閲覧履歴での調査ではありません。閲覧履歴から判断したい場合は、SharePoint のAudit log機能が動作している必要があります。
(2-5)Workflow reportを取得
サイトワークフローとリストワークフローを取得し、ワークフローが存在しているか確認します。SharePoint のワークフローは、ShareGate で移行はしますが、移行先で正しく動作する保障はありません。したがって、移行後にワークフローを手動で修正しなければならなくなる可能性があります。要件確認の際に、この部分の作業スコープを決めておく必要があります。
(2-6)Lists with workflows reportを取得
ShareGate では、ワークフロータスクは移行できないため、リストワークフローを事前に把握しておく必要があります。また、ワークフロータスクが途中のものがある場合は、移行前にタスクを完了しておくことをお勧めします。
(2-7)Checked out documents reportを取得
ShareGate では、チェックインされていないバージョンのアイテム（ドキュメント）を移行することができません。この調査では、移行できないアイテムを明確にし、チェックインが必要なアイテムをチェックインする必要があります。ShareGate の機能よりチェックインする機能もあります。
※「Source analysis」では、チェックアウトされたドキュメントを含んでいるリスト・ライブラリを確認することができましたが、このレポートはアイテムやドキュメントまで確認することが可能です。
(2-8)Orphaned user reportを取得
この調査は、必須ではありませんが、ShareGateを移行中に多くのエラーや警告の発生原因となります。その数を減らす目的としては、実施した方が良いものとなります。この調査では、Active Directory から削除されているユーザーが SharePoint のサイトコレクションのユーザー一覧に残ってしまっているユーザーを指しています。ShareGate を移行時に、移行元の Active Directory から削除されていて見つからない状態になっているため、エラーや警告が発生してしまいます。このユーザーを移行前に削除することで、エラーの発生数を抑制することが可能になります。
(2-9)リストレポートを取得
この調査も必須ではありませんが、厳密な移行計画を行いたいときは、リストレポートでリスト毎のアイテム数を取得します。この調査により、サイト毎にどのぐらいのアイテム数があるか計算が可能になり、複数のサイトコレクションで移行時間を計測することで厳密な移行時間を計画することができるようになります。
(2-10)IRM(Information Rights Management)の使用状況を取得
ShareGate では、IRMで暗号化されたアイテムやドキュメントは移行できません。そのため、事前に IRM が利用されているリスト・ライブラリを特定する必要があります。まずは、SharePoint Server の全体管理画面より[Information Rights Management]の設定がされているか確認します。IRM が設定されていた場合、ShareGate での調査ができない為、「SharePoint 移行評価ツール」を利用して、IRM を利用しているリスト・ライブラリを特定します。
※利用できる環境にご注意下さい。
(3)構造コピーでサイトコレクションをサンプル移行
ここでは、移行の実行時間の計測や、(2)で解説した以外にも潜在的に隠れている問題を見つけるのに役立ちます。移行実行時間については、この後の移行計画にも利用します。また、移行元の環境と移行先の環境で仕様が異なっているために発生するエラーなどもあるため、事前に知っておき対策を立てておくことが重要となります。ShareGate のトライアル版で構造コピーを実施することをお勧めします。
Step２．要件確認・移行方針確定
Step１で解説した現状分析の結果から、移行の要件をユーザーに確認し、移行方針を確定する必要があります。また、現状分析の結果からだけではなく、他に決めておく事項も説明したいと思います。
まず、現状分析の結果について解説します。
現状分析の結果
(1)Source analysisのエラー・警告に対する要件・移行方針
3rdパーティー製品やカスタマイズされた機能やテンプレートなどは、ShareGate では移行できないため、移行先に 3rd パーティー製品の導入や、移行先に構造を構築しておく必要があります。また、SharePoint Online で3rd パーティー製品を利用する場合、移行元との互換性の確認も必要となります。このあたりの事を考慮して、移行方針を確定する必要があります。移行方針としては、２パターン考えられます。
- 3rd パーティ製品やカスタマイズ機能は移行しない。
- 構造コピーを実施後に 3rd パーティ製品の導入やカスタマイズ機能を実装する。
この場合、[Copy content only]でデータのみをコピーする必要がある。
(2)サイトコレクションレポートに対する要件・移行方針
移行先のサイトテンプレートと言語設定を確定させます。尚、移行先のサイトテンプレートをモダン UI にする場合、クラシックUIで作成されたページはカスタムスクリプトを有効にしない限り移行できません。カスタムスクリプトの有効化はサイトコレクション単位で必要になります。
※設定方法はこちら
(3)Unused site reportに対する要件・移行方針
未使用サイトに対する移行方針を確定します。このレポートをユーザーに提示し、現在利用しているものなのか、移行する必要があるのかをヒアリングします。移行する必要が無いものは、移行対象から外すことで工数が削減できます。
(4)Workflow reportに対する要件・移行方針
ワークフローに対する移行方針を確定します。まず、利用しているワークフローかどうかを確認し、移行が必要なものなのかヒアリングします。移行が必要な場合、移行後の動作確認や動作しなかったときの修正を誰が行うのか等、作業スコープを確定させます。移行プロジェクトチームが本作業を実施する場合は、作業工数、見積もり、移行スケジュール等の見直しが必要になります。ワークフローを移行先に再実装する場合、データ移行が完了後に実装する必要があります。
(5)IRM(Information Rights Management)に対する要件・移行方針
IRM 機能が有効なまま移行は出来ない為、IRM 機能をオフにして移行する必要があります。IRM機能が有効なドキュメントライブラリを移行しないという事はほぼ無いはずですが、テスト的に作成されたものであれば事前に削除するか、IRMの機能をオフにするなどが考えられます。移行する必要があるものについては、いつオフにするのか、オフにしている間ユーザーがファイルをダウンロードできてしまう等の問題があるため、その対策を考える必要があります。
(6)構造コピーでサイトコレクションを移行した結果に対する要件・移行方針
SharePointの環境や使用方法によって発生するエラーや警告が異なります。エラーや警告の内容に合わせて、事前にどのように移行するかの方針を決定しておきます。
ここまでが現状分析に対する要件確認と移行方針の確定になります。ここから現状分析とは関係なく、決定しなければいけない要件の確認となります。
移行要件の確定
(1)移行先のサイトコレクションのURL
基本的には移行元と移行先で同じURLで良いが、移行元が複数のWebアプリケーションで構築されている場合で、移行先がSPOの場合は、テナントが１つになるため、URLが重複する可能性があります。この場合は、移行先のURLの命名規則を事前に確定しておく必要があります。
(2)移行先のサイトコレクションのクォーターサイズ
サイトコレクションによってサイズを調整するのか、一律にするのかを確定する必要があります。
(3)ページ
ShareGateではマスターページが移行できないため、移行先で画面崩れが発生することがあります。ページ内に配置しているWebパーツが正しく移行出来なかったり、一部の文字に対する文字化けが起こることもあります。また、SP2013などでSite直下にdefualt.aspxが存在している場合、ShareGateでは移行できません。移行するまでにdefault.aspxをSitePagesライブラリなどに移動しておくことをお勧めします。これらのページに対する修正作業を行う場合、作業スコープを確定させます。
※移動しても画面崩れが発生することは多々ありますので事前に確認しておくことをお勧めします。
(4)リンク
移行対象のサイトコレクションが少ないなどの場合は、あまり気にする必要はないかもしれませんが、サイトコレクションが多く、移行期間が長くなるような場合、リンク切れは致命傷になりかねません。ユーザーにはリンク切れになる旨を事前に伝えるなどの対策が必要となります。
リンクの洗い替えは、ShareGate の移行方法やオブジェクトのタイプによって挙動が変わります。
[Copy Structure]の場合
サイトコレクションを丸ごと移行する場合、Webアプリケーション外へのリンクは修正されず移行元のURLのまま移行されます。
※用語ナビゲーションを利用している場合、シンプル リンクまたはヘッダーのURLプロパティは修正されません。
[Copy content only]の場合
移行オプションの設定により、リンクを自動修正させるかさせないかを選択する事が可能です。自動修正する場合、同一リスト内のリンクは移行先に合わせて移行されますが、異なるリストやサイトへのリンクは修正されず移行元のURLのまま移行されます。
[共通]
ファイル（ドキュメント）内のリンク（例：Word等のハイパーリンク）は修正できません。
(5)ユーザーマッピングの作成有無
ShareGate は、移行元と移行先のユーザーやグループを自動でマッピングする機能がありますが、同姓同名や同じ名前のセキュリティグループに対して誤認識してしまう事があります。ShareGate の機能ではこれらを検知することが出来ない為、事前に Active Directory を管理している部門に確認しておく必要があります。もし、同姓同名や同じ名前のセキュリティグループが存在している場合は、ShareGate の機能でユーザーマッピングを作成しておく必要があります。
※複数の Active Directory で信頼関係を結んでいる場合は、全ての Active Directory に対して調査が必要になります。
(6)移行対象のサイトコレクションの移行順序
多くのサイトコレクションが移行対象となっている場合、移行期間が長くなります。移行する順番がランダムだと、統一性がなくなり、同じ部門が利用している複数のサイトコレクションが移行元と移行先に同時に存在する期間などが出てきます。要件確認の段階で、サイトコレクション毎に移行移行する順番や同じタイミングでリリースが必要なものがないかヒアリングを行う必要があります。
(7)移行計画後に作成されたサイトコレクションに対しての扱い
運用上、日常的にサイトコレクションが新たに作成されることは良くあります。移行計画後に新たに作成されたサイトコレクションを移行するかどうか、移行しないなら作成させないなどの制約を決める必要があります。
Step３．移行計画・移行準備
現状分析や移行方針に基づき、移行計画を立てます。
移行計画（スケジュール）
- 現状分析や要件確認の以下の結果から、すべてのサイトコレクションに対しての移行時間を割り出します。
● 移行対象サイトコレクション
● Source analysis のサイトコレクション数・サイト数、各サイトのサイズ
● サイト内のアイテム数
● 移行実行時間 - 1と移行順序を考慮しスケジュールを立てます。また、移行実行時間帯は 18 時から翌日 8 時頃までがベストです。（ShareGateが推奨している時間帯です）
- 一晩で移行しきれないなどがある場合、ShareGate を複数ライセンスにし同時に移行する事を検討します。
※ SPO への移行の場合で、ShareGateを複数ライセンスで実行する場合、複数の実行アカウントを用意した方がスロットリングを抑制できます。 - 増分移行が必要になる場合は、そのスケジュールも組み込んでおく。
移行計画（移行方針）
- 現状分析の結果や要件確認で確定した対応方針の内容を記載します。
● 3rd パーティー製品、カスタマイズ機能やテンプレート
● チェックアウトされたアイテム・ファイル
● サイトコレクションの URL の命名規則、クォーターサイズの設定
● 移行対象外のサイトコレクション一覧
● 移行計画後に作成されたサイトコレクションに対しての扱い
● ワークフローの移行有無・作業スコープ等
● IRM が移行対象の場合、IRM をオフにするタイミングや作業内容
● ページに対する、作業内容・作業スコープ
● ユーザーマッピングの作成有無・作業内容・作業スコープ、反映タイミング
（更新が必要な場合） - 現状分析で移行した結果のエラーや警告に対する対応策なども記載しておきます。
- 本番移行でエラーが初めて発生するエラーに対してどのように対応していくかも記載しておきます。
- 移行正常性確認に対する方針を記載します。
例：移行レポートのエラーチェック、アイテム数チェック、権限比較等を実施するか。
移行準備
- 移行ツールの開発
● 大規模移行プロジェクトでは移行の自動化が必須になります。
● ShareGate の PowerShell を利用し実装を行います。
● その際に、移行要件を満たすよう実装します。 - 移行手順書の作成：以下の観点で移行手順書を作成
● ツールを用いる場合の手順
● エラー対応などで個別移行する場合の手順書
● その他 ShareGate で移行出来ない部分の設定等の手順書（作業スコープ内のもの） - 開発する移行ツールの例
● サイト自動作成ツール
● サイトコレクション機能のアクティブ化ツール
● ユーザーマッピング・グループマッピングファイル生成ツール
● 構造コピーツール
● データコピーツール
● パスワード暗号化ツール
● リンク洗い替えツール
● 権限比較ツール
● エラーチェックツール
● アイテム数チェックツール
Step４．リハーサル・パイロット・本番移行
- リハーサル移行
作成したツールと手順書でタイムスケジュール通りに実施可能かを本番の環境で実施します。作成した手順書の中で時間のかかるタスクを洗い出すのが目的で、手順の見直しや、さらに効率化ができるツールの開発などを行います。 - パイロット移行
本番移行と同じではあるが、比較的移行が簡単なサイトか、移行しなくても良いようなサイトで本番移行と同じ手順で実施します。移行がスケジュール通り出来なかった場合のリカバリも考慮する必要があります。 - 本番移行
リハーサル移行で確定した手順書通りに実施します。必要に応じて、アイテム数チェックや権限チェックの結果を報告したり、要件確認などでユーザーの作業スコープとなっている箇所でエラーが発生している箇所は依頼事項などに記載し連携します。
まとめ
いかがでしたでしょうか。移行プロジェクトにおいて移行計画を作成するための事前検証段階で移行できないものを事前に把握しておくことが重要です。移行できないものをどのように扱うか？という移行方針により、移行の難易度や工数がかなり変わってきます。また、ユーザーとプロジェクトの作業者で役割分担を移行計画段階で決めておく事で移行がスムーズになります。
この記事が、皆さんの移行プロジェクトを成功させるために少しでもお役に立てば幸いです。
今後も、ShareGate に関する記事をアップしていきますので、ご期待ください。
SGプラスでは、Microsoft 365 導入支援サービスをご提供しております。移行について課題やお悩みなどがございましたら、ぜひ、弊社へお問い合わせください。
関連サービス：Microsoft 365 導入支援サービス