SharePointの運用経験が長いお客様にとっての問題の深刻度は、使用の強度、プラットフォームのカスタマイズの程度、およびサードパーティソリューションへのコミットメントに依存します。 これらの要因により、移行が遅くなったり、移行が妨げられたりする可能性があります。
SharePoint Onlineへの最大のSharePoint移行の1つは、内部のニーズのためにMicrosoftによって実装されましたが、すべての計画とソリューションはプロセスが始まるずっと前に準備されました。 Microsoft IT（MSIT）は詳細な方法論を開発し、各ファーム、グループ、および個々のサイトのコンテンツを定義し、さらなるアプリケーションの理解を深めました。 ワーキンググループは、ワークロード、ビジネス結果、およびアーキテクチャの複雑さに関するデータに基づいて、各サイトの移行場所を分類、優先順位付け、および概説しました。
アメリカの会社Gtconsultのコンサルタントであり、移行の専門家であるDorinda Reisは、いくつかのアプローチの存在に注目しています。 「リフトアンドシフト」手法は、SharePoint構造全体を保存し、新しい環境（ほとんどの場合はOffice 365）に移行する場合のアプローチです。ただし、オプションとして、この手法はSP2010からSP2013にアップグレードする場合にも適用できます。
多くの場合、専門家によると、「マップと再構築」アプローチが使用されます。 この場合、構造が変更され、コンテンツが再編成され、より便利な場所に再配布されます。 SharePoint環境がファイルリポジトリになり、すべてをクリーンアップしてユーザーに適用できるようにする必要がある場合があります。 ほとんどの移行では、組織の開発と、新しい環境を作成するための新しいアイデアと計画の出現に関連した再構築が必要です。
Office 365の移行が非常に遅いのはなぜですか？ この問題は、大規模な組織にとって最大の関心事です。 多くの理由があります。 マイクロソフトは、負荷分散やウイルススキャンなど、ユーザーとサーバーファームの整合性を保護するために多くの方法を使用しています。 それらはすべて、移行プロセス自体の速度に影響を与える可能性があります。
さらに、SharePoint Onlineのパフォーマンスは、チャネル幅とデータ転送速度だけでなく制限されます。 マルチユーザー環境は、データの分離性とセキュリティにもかかわらず、他の顧客に影響を与える可能性のあるアクティビティに制限があり、その目標はすべてのユーザーのサービス品質を維持することです。
この問題を解決するために、Microsoftは、SharePoint OnlineとAzure間のスループットを向上させる移行用APIを開発しました。 Igniteの発表中、コミュニティには製品を説明する製造業者のレビューが提示されました。 残念ながら、彼らは新しいMigration APIの機能と制限の明確な全体像を提供しませんでした。
Westernの専門家によると、この新製品は実際にOffice 365への移行を高速化することができますが、主にコンテンツを対象としています。 リスト、ライブラリ、およびサイトを転送するには、すべてのアイテムを手動で作成し、移行先に適切にルーティングするために移行パッケージを作成する必要があります。
移行とOffice 365 MVPの専門家であるBenjamin Niaulinは、プロセスを完全にセットアップして準備した後、Office 365に移行するギガバイトの情報を見ることほど良いものはないと指摘しました。 ただし、特にSharePointを再編成および再構築する場合は、単純で簡単なプロセスと見なすのは間違いです。 専門家によると、新しいAPIは、移行ソリューションを構築するマイクロソフトパートナーを対象としています。 大量のデータをOffice 365に転送するために必要な高速性と組み合わせて、必要な粒度と柔軟性をエンドカスタマーに提供するのはパートナーです。
Reisによれば、新しいAPIでサードパーティベンダーのツールを使用しても、移行プロセスを構成するために手作業が必要になります。 専門家によると、移行APIは、Lift and Shiftテクニックを使用した単純なデータ転送により適しています。 「マップと再構築」アプローチでは、特定の要件を満たした各データ要素をパッケージ化する必要があります。たとえば、エクスポートされたオブジェクトの特定のURLまたはGUID、パスを指定し、データ圧縮を無効にします。
Azureプロセスを使用すると速度は向上しますが、ここでは基本的な移行設定を制御できなくなります。 セキュリティ、メタデータ、およびバージョン管理は制限されています。 ポータブルデータブロックごとにパッケージを作成すると、いずれかのパーツが失われる可能性があります。 したがって、再構築を伴う複雑な移行の場合、設計と構成がコンテンツの転送と同じくらい重要である場合、スクリプトや特殊なパッケージの開発を含む従来のアプローチが優先されるオプションのままです。 このような場合に移行APIを使用すると、メリットよりも多くの問題が発生する可能性があります。 サードパーティのソリューションが作成されるのは、複雑な移行を簡素化するためです。
新しいAPIは、サードパーティのソリューションなしで使用できますか？ もちろん、はい。 ただし、カスタムソリューションを使用すると、ユーザーにより多くの制御が提供され、移行のリスクが軽減されます。 次の記事では、このようなソリューションを確認して比較してみます。
www.cmswire.comの資料に基づく