デジタルトランスフォーメーションを進める企業では、オンプレ環境からクラウド環境に移行する企業も少なくありません。特に日常行うメールのやり取り・文書の社内共有について、オンプレからクラウド環境へ移行することも珍しくなくなっています。

Microsoft 365とSharePointOnlineへの移行は、クラウド移行の典型例です。これらのクラウド環境に移行を決めた場合、移行そのものは、開発行為を大規模に行わなくてもできることですが、プロジェクトマネジメントと、文書データのマイグレーション・オンプレ環境で利用していたアプリの利用の停止ないし切り替え、十分な通信容量の確保については、管理者・エンジニアともに知恵の絞りどころです。

そこで、移行手順の全体像をここでご説明します。移行前のオンプレ環境としては、Notesからの移行を主に想定して解説しますが、他のオンプレ環境でも生じる作業の多くが共通すると考えられます。

移行手順

1.前提条件となるAzure環境への移行

Microsoft 365とSharePointを利用する場合、双方ともAzureクラウドプラットフォームの上で動作することや、サーバの用意をするコストを考慮すると、Azure環境への移行が必要になってきます。

2.容量の計算および確保・管理者権限の設定

Azureは利用料に応じたサブスクリプションモデルで料金プランが用意されています。そこで、トラフィックと「専用サーバ」として利用できる領域の確保、通信サービス品質の確保を行うためのサイジングの作業が必要になります。また、今後の作業のために、管理者権限の設定を行います。

3.通信の確立

オンプレ環境からMicrosoftの提供するデータセンターに、現在のオンプレの環境からの通信を確立して、Azureへの移行作業を進めることになります。そのためには、オンプレミス側にVPNデバイスまたは、RRASを用意して、接続します。エンタープライズユーザーはVPNで接続して、通信の保護を行いながら接続するケースが多いようです。

そして、DC側でのゲートウェイサブネットの作成、仮想ネットワークゲートウェイの作成、ローカルネットワークゲートウェイの作成、差異サイトVPNの作成、そしてオンプレミスのVPNデバイスの構成、と作業を進めていきます。

4.テスト開始・モデルケースを社内で作る

Azure環境に移行が完了すると、Microsoft 365と、SharePoint Onlineへの移行準備は完了します。Microsoft 365とSharePoint Onlineの利用そのものはアカウントがあればできることなので、ここでテストの工程を挟みます。社内での利用モデルを確立する作業期間を作り、その後社内でテストや問題点の洗い出しを行います。

それまでの手順を大まかに紹介すると次の通りです。

①Microsoft 365への移行

Microsoft 365はOutlook OnlineとOfficeアプリケーション一式がSuiteとして提供されています。各アプリケーションで作成した文書は共有がオンラインで可能なため、ファイルサーバの役割はMicrosoft 365に担わせることが可能です。アカウントさえ用意できていれば、メールや各アプリケーションはユーザの設定が完了次第、Azure環境が構築されているもとで利用開始できます。

②SharePointへの移行

これに対して、SharePointは、自社のイントラやWebサイトに実装する作業が必要になります。典型的には、NotesDBにある文書データベースをSharePointに切り替える作業が必要になります。また、レガシーアプリのインターフェースを利用したSharePoint開発が必要になることもあります。後者の場合、レガシーアプリのサーバをAzure環境に移すのか、あるいは、オンプレサーバをレガシーアプリ用に残しておくのかを検討します。最終的にAzure環境に移すのであれば、レガシーアプリのAzure環境でのデプロイが可能かも検討しておきましょう。

イントラや、Webサイトに実装する場合は、SharePoint側のテンプレートを使って実装することができます。非常に簡単に言うと、テンプレートをもとにページを作成しサーバにアップすることができれば、SharePointを文書の格納場所として利用することができます。アドインやレガシーアプリのカスタマイズについては、それぞれの開発の難易度次第で期間が異なりますが、ツールなどがありますので、これらを利用して1ヵ月～3か月くらいの期間で開発の目途をつけるようにします。

③文書データの移行

Notes環境に依存するアプリケーション・DBを利用していた場合、Notesの企業内サポートをもう行わない場合は、DBをテンプレート化し、Microsoft 365またはSharePointに移行・代替する承認フローや、文書管理システムのUIを利用したSharePointのソリューションなどに移行します。

このうち、承認フローについては、Microsoft 365でも開発で実装することができます（詳しくは別稿説明。リンクを参照してください）。

④テストとその期間

ここまでの作業が終わると、限られた数のユーザに、機能を解放し、問題点を抽出します。
問題点の抽出期間に3か月～1年（会社の規模によります）の期間をとり、技術的な問題点を記録・重大な問題があれば追加購入・追加開発を行います。

⑤文書の準備

また、多くのユーザに機能を解放することに備え、ユーザマニュアルやセキュリティ要件の遵守のための手順書などをユーザ向けに準備します。問題点が生じた場合は、ユーザサイドのPL・PMと連携をし、技術的問題点とオペレーションで解消できる問題との切り分けを明確にするようにしておきます。

問題点が生じた場合、NoteでできたことがSharePointではできなくなった、といった問題点は、主にユーザサイドの問題として解消してもらうことが望ましいといえます。これに対して、技術サイドはこの期間に、確保したAzure基盤のテスト用に割り当てている環境で容量は足りるのか、またパフォーマンスが十分か等、障害時の対応に集中しておくようにしましょう。

5.メール移行工程は2日ほどでも完了可能

テスト期間が終わると、ユーザアカウント作成、メール・DBの移行を開始します。ユーザアカウントの割り当てと、メールの設定方法についてはユーザに案内をあらかじめ出しておき、移行期間を設定したらメールを順次移行してもらいます。

メールデータの一括移行サービスや、メールアドレスの新アドレスへの変換サービスなどは、ユーザ数にもよりますが、サービスプロバイダ―にアウトソーシングして行うことが一般的になっています。サービスを受けない場合でもツールを使い、工数の削減をしながら移行したほうが効率よく、失敗なく移行ができます。この工程は2日もあれば完了できます。

6.文書データ移行を進めるうえでのポイント

Domino ServerからDB内のデータを移行する場合、DB内のデータをSharePointで書き出すためのツールがあります。

DB単位で移行する場合、移行用テンポラリサイトをあらかじめ作成→ツールで書き出し→テンプレートと紐づけ→イントラ・Webにアップ、といった手順で比較的にスムースに移行ができます。

IT部門の介入は、テンポラリサイトを作成しておくことや、ツールによる書き出し作業をしておくことは必要と考えられますが、その他についてはユーザ主導で移行することが可能です。

SharePoint Online移行の失敗例

SharePointという製品は組織の情報共有スペースになったり、チームサイトを作成したり、またはアプリケーションを開発したりと実に多岐にわたる機能を備えています。SharePoint Onlineも同様な役割を持ちます。機能数でいうと、実に400以上もの機能が搭載されているのがSharePointおよびSharePoint Onlineです。

SharePoint Online移行に失敗する企業の共通点は、機能を使いこなせていないことにあります。ここでいう「使いこなせない」というのは、SharePoint Onlineすべての機能を活用できていない、という意味ではありません。

組織および部門ごとに必要な機能を取捨選択し、適切な利用を心がけることができていない、という意味です。

そもそも400以上もの機能すべてを、専門家ではない人が使いこなすことは土台無理な話です。したがって、SharePoint Onlineへ移行する際は、機能要件を確実に定義した上で、システムが定着するよう展開していくことが大切です。

もう一つの失敗例は、要件定義を煮詰めて考えられていないことです。SharePoint Onlineへの移行は導入・構築、展開、運用と大まかに3つのフェーズで進んでいきます。しかし、要件定義が煮詰まっていないと、各フェーズでさまざまなトラブルが発生してしまいます。要件定義には導入プロジェクト全期間のうち80%を割くのが適切だという専門家もいるほど、SharePoint Online移行での要件定義は重要です。

SharePoint Online移行で考慮すべきポイント

移行に際し、考慮すべきポイントを紹介します。

移行元環境の分析

まず最初に行うべきことは、移行元環境にどれくらいのコンテンツがあるかの分析です。同じSharePointといってもサーバ環境とオンライン環境では違う点も多いので、まずは移行元環境を現状について把握することが大切です。そのためのツールとして、Microsoftは「SharePoint移行評価ツール(SMAT)」を提供しています。このツールは既存のSharePoint環境におけるコンテンツをスキャンするものであり、簡単なコマンドライン実行ファイルです。ユーザーはSharePoint Onlineへ移行する前に、現状環境の把握と問題発見ができます。

コンテンツの要不要を分ける

SharePoint Onlineへの移行にあたって、全てのコンテンツを移行する必要はありません。今あるコンテンツの中には、すでに使用しない不要になったものが必ず存在します。日頃からSharePointの情報整理ができている企業は珍しいので、この機会にコンテンツの要不要を明確にしましょう。ちなみにSharePoint Onlineでは容量制限があり、場合によっては記憶域を買い足す必要もあるので、不要なコンテンツは極力排除するのがベストです。

段階的な移行を検討する

400以上もの機能を持つSharePoint Onlineを、いきなり目の前に突きつけられて使いこなせるようなユーザーは、はっきりといって皆無です。熟練の情報システム担当者でさえ、SharePointの全ての機能を把握していないこともあります。そこで、部門ユーザーにSharePoint Onlineを定着させるためには、2通りの段階的移行を検討してください。

単機能と全導入

使用できる機能をかなり制限した上で全社導入し、中長期的な計画で徐々に新しい機能をリリースしていきます。使える機能が絞られていれば、部門ユーザーも迷うことなくSharePoint Onlineを利用できます。ただし、全社的にSharePoint Onlineをフル活用できるようになるまで、1年以上は確実にかかります。

多機能と単部門導入

ファイル共有、チームサイト、ワークフローなどSharePoint Onlineが持つ多彩な機能の制限を最小限にして、単部門に導入する方法です。対象部門での導入が成功事例になれば、そこで培ったノウハウを持って徐々に他部門へと展開していきます。一見時間がかかる方法のように思えるものの、いち早くSharePoint Onlineを定着させたいという考えを持つ企業におすすめの方法です。

必要なリソースを中長期的に計画する

SharePoint Onlineへの移行が完了しても、コンテンツは増え続けます。この際増えたコンテンツ分はストレージを買い足せばよいという安直な考えを持っていると、あっという間にコストが肥大化して、運用が苦しくなってしまいます。そのため、要件定義段階から将来的に必要なリソースを計画して、それに沿った運用を行えるよう心がけます。

テスト移行を必ず行う

Microsoft 365とSharePoint OnlineはどちらもMicrosoft製品なので、連携はスムーズに取れます。ただし、移行時には予期せぬトラブルが起こる可能性もあるので、必ずテスト移行を実施して、移行時に起こる可能性のあるトラブルを事前に確認します。

まとめ　トータルの移行期間と移行のコツ

容量の計算、管理者権限の設定、テスト環境の構築およびテスト、本番環境でのデータ移行・開発とトータルで最短で1年以内、ユーザ数によっては1年半から2年かかるケースも珍しくはありません。既存のNotes環境をすぐに廃止してしまう、となるとユーザ主導でのデータ移行もうまくいかない場合が多いので、移行期間を長めにとるなどしてデータ移行の工程にあまり力を割かないことがポイントになります。

移行に際しては、SharePointとNotesの設計思想の差から「NotesでできることをなるべくSharePointでも実現しよう」と考えがちになってしまいますが、双方は設計思想が異なります。ユーザにデータの管理を行わせるSharePointでは、管理者の介入はより本質的なところに絞り、例えば、通信やセキュリティ規則の実行などの場面で機能することが望ましいのです。これを踏まえて、移行をできるだけ小工数で納めることを狙いましょう。