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