IBM Notes から Microsoft Exchange または Office 365 への移行は、組織に多くのメリットをもたらしますが、移行プロジェクト自体は困難に見え、どこから移行を始めるべきか完全には明確ではありません。 Exchange 自体には、Notes と Exchange を完全に移行または共存させるための独自のツールは含まれていません。 実際、一部の移行および共存タスクはサードパーティ製品なしでは実行できません。 この記事では、ベスト プラクティスと成功した移行の経験に基づいて、従うべき XNUMX つの重要な手順を概説します。

移行が成功するには、次の手順が必要です。

1. 移行の予備評価。
2. Notes と Exchange の共存を確立します。
3. 最適な移行精度を計画します。
4. 最大限の移行効率を確保します。
5. テスト移行を実行します。
6. 組織への影響を最小限に抑えるために移行のタイミングを計画します。
7. 移行を開始し、その進行状況を追跡します。

この記事では、Quest の XNUMX つのソリューションを使用して移行を準備し、完了する方法について説明します。 Notes の共存マネージャー и Notes to Exchange の移行ツール。 カットの下には詳細がいくつかあります。

ステップ 1: 移行の事前評価

現在の環境の棚卸しを行う

Exchange が組織にとって適切なプラットフォームであると判断した場合は、そこに移行するだけです。 まず、現在の環境に関する情報を収集し、移行を計画しているデータのインベントリ情報を収集し、ディスク領域の使用率を削減するために何を削除できるかを判断し、環境間で利用可能な帯域幅を計算するなどの作業を行う必要があります。事前評価には、以下の内容が含まれる必要があります。次の質問:

• Notes ドメインと Domino サーバーはいくつありますか?
• メールボックスはいくつありますか? そのうち未使用のものは何個ありますか?
• プライマリメールファイルはどれくらいのディスクスペースを占有しますか? アーカイブには何件ありますか? ローカルレプリカにはいくつありますか?
• アーカイブはどこにありますか?
• 暗号化を使用しているユーザーは何人いますか? 暗号化されたコンテンツを転送する必要がありますか?
• 環境内に個人フォルダーはいくつありますか?
• どのユーザーがドキュメント リンクを使用しますか? 他のユーザーやアプリケーションからリンクを受け取ったユーザーは何人いますか?
• どれくらいの量のデータを転送するつもりですか? たとえば、過去 XNUMX か月間のデータのみを転送したいとします。
• ネイティブ アーカイブは個人用 Exchange アーカイブまたは Outlook *.pst ファイルに移行されますか?
• 帯域幅の制限は何ですか? どれくらいのデータを転送できるか
  一定期間?
• 移行後にどれくらいのストレージが必要になりますか?

移行がビジネスと運営に与える影響

プロジェクトは、ダウンタイムを最小限に抑え、生産性の損失を最小限に抑えるために慎重に計画する必要があります。

たとえば、ユーザー間の委任を考慮することが重要です。ユーザーが移行しても、その委任者が元のプラットフォームに残っている場合、それは日常の作業にどのような影響を与えるでしょうか? より広範に、移行プロジェクトが会社のすべての重要なビジネス プロセスとワークフローにどのような影響を与えるかを考慮する必要があります。

Notes 内の重要なタッチポイントを考慮することも重要です。 たとえば、メッセージングを扱う場合、移行中および移行後のビジネス プロセスの中断を避けるために、アプリケーションを分析し、メール ルーティングとアプリケーション間の相互作用を考慮することが重要です。 必ず次の質問をしてください。

• どのユーザーが代理人を持っていますか? この関係が壊れるとビジネス プロセスにどのような影響が及ぶ可能性がありますか?
• 電子メール環境にはどのようなアプリケーションやビジネス プロセスが関連付けられていますか? 承認プロセスなど、アプリケーションと電子メール サービス間の重要な統合は、移行を計画する際に重要になります。
• アプリケーションのどのコンポーネントと重要な機能を保持する必要がありますか?
• 新しいプラットフォームの組み込み機能をどのように使用して、必要な機能を実現できるでしょうか?
• 非アクティブなコンテンツは将来の保存のためにアーカイブする必要がありますか?
• 新しい環境で正しく実行するためにアプリケーションを再構築する必要がありますか?
• 成功はどのように測定されるのでしょうか?

移行を開始する前に、成功を評価する基準を定義する必要があります。 特に、100% のデータ転送を期待するのは無理があることを理解する必要があります。 すべての Notes アイテム タイプが Exchange に同等のものを持っているわけではありません (Active Mail が最も悪質な例です)。 したがって、実際には、Notes のすべてのアイテムが移行後に Exchange に存在するわけではありません。 達成可能で測定可能な目標は、アイテムの 95% がメールボックスの 95% に移動されることです。 結果を測定して文書化することは、移行を確実に成功させるために重要です。真の結果は、電子メール移行プロジェクトの開始時に成功基準が定義されている場合にのみ可能です。

ステップ 2: Notes と Exchange の共存を確立する

ほとんどの組織にとって、移行はイベントではなくプロセスです。 したがって、メールボックスの移行とアプリケーションの移行は、技術的な要件に基づいたものではなく、ビジネスと運用に最適なスケジュールに従う必要があります。

共存戦略の策定

移行の価値を最大化するには、移行プロセスの早い段階で完全な共存計画を作成し、実装する必要があります。 「共存」の定義は組織によって異なる場合があります。 空き時間情報データを積極的に使用している組織もあれば、この機能をまったく使用していない組織もあります。 カレンダー データの移行に重点を置いているものもあれば、ユーザー ディレクトリ全体の移行の微調整に重点を置いているものもあります。 各関係者と協力して本当に重要なことを明確に把握し、効果的な共存戦略の重要性を全員が理解できるようにすることが重要です。

Notes から Exchange および Office 365 に移行するには、メールボックスとアプリケーションの移行を同時に計画する必要があります。 現在の Notes アプリケーションの機能は、現在の電子メール プラットフォームに関係なく、すべてのユーザーに対してサポートされている必要があります。 Exchange および Office 365 に移行するユーザーは、既存のワークフローの一部として Notes アプリにアクセスして使用できる必要があります。 この機能は、Notes アプリケーションが SharePoint または別のプラットフォームに移行されるまで継続されます。

アプリケーションの共存に加えて、移行を開始する前に、異なるプラットフォーム上のユーザー間の対話を実装する必要があります。 これには、現在のプラットフォームに関係なく、すべてのユーザーの自動ディレクトリ ルーティングと更新、空き時間情報ステータスとカレンダーが含まれます。

最後に、電子メール サービスだけでなく、カレンダーや会議室などの共有リソース間のコラボレーションも考慮する必要があります。 ユーザーは会議のスケジュール情報をダウンロードできる必要があります。 これには、XNUMX 回限りのミーティングと定期的なミーティングの両方が含まれます。 予定が移行前にスケジュールされたか、移行中に作成されたかにかかわらず、プロジェクト全体を通じてカレンダー データの正確性を維持する必要があります。 たとえば、ユーザーが、後続の会議で競合や混乱を引き起こすことなく、定期的な会議の次の会議の会議室を変更したり、ある会議をキャンセルしたりできるようにする必要があります。

ステップ 3: 最適な移行精度を計画する

Notes から Exchange または Office 365 への移行を計画するには、プラットフォーム間のいくつかの具体的な違いを理解する必要があります。

メールアドレス

通常、Notes データには独自のアドレスが含まれており、メッセージ ヘッダー、アーカイブに埋め込まれたアドレス、個人の連絡先、配布リストなど、さまざまな場所に表示されます。 Exchange 環境で完全な機能を確保するには、移行プロセスの一環として、これらの独自アドレスを SMTP アドレスに更新する必要があります。 多くの組織は、移行中に SMTP ドメインまたはアドレス標準を更新することも選択します。 これが組織に当てはまる場合、一部の移行ソリューションでは各ユーザーの履歴 SMTP アドレス インスタンスが自動的に更新されることを理解することが重要です。

フォルダー構造

多くの組織では、ユーザーは独自のメールボックスとアーカイブを使用するため、このデータを保存することが重要です。 ユーザーが完全なフォルダー構造を表示できるかどうかも、移行の結果としてユーザー エクスペリエンスに影響します。 フォルダーとデータ構造の整合性を維持するソリューションと移行を選択することが重要です。

ローカルレプリカとアーカイブ

ストレージ コストを制御し、データ増加をより適切に管理するために、多くの組織はメールボックス クォータを設定しています。 このポリシーの意図しない結果として、アーカイブの数とサイズが増加することがよくあります。 これらの追加のデータ ソースを評価し、移行計画中にその移行を検討する必要があります。 重要なデータのみを移行できるセルフサービス コンポーネントをユーザーに提供できます。 Exchange ストレージを最適化するには、別の Quest 製品を使用することをお勧めします。 Exchange のアーカイブ マネージャー特に、添付ファイルの重複排除に便利な機能があり、Notes の DAOS に似ています。

ACLと委任

アクセス制御リスト (ACL) と委任は、Notes 環境で運用するための重要な要素であり、整合性を保護するためにも重要です。 そのため、関連付けられた権限とアクセス権を、Exchange Server および Office 365 の同等の権限に正確に変換することが重要です。理想的には、これを自動的に実行することで、プロセスが高速化され、人的エラーが排除されます。 組織の情報資産を保護する効果を維持するには、ACL と委任マッピングをメール データと同時に実行する必要があります。 組織によっては、データ移行の完了後に、手動またはスクリプトを使用して同等の権限を割り当てようとします。 ただし、このアプローチは生産性に悪影響を及ぼし、組織のデータにセキュリティ ホールを追加する可能性があります。

メモ独自のコンテンツ

同じアクティブメールです。 IBM Notes から移行する際のもう 365 つの一般的な問題は、大量のリッチ テキストが発生することです。 Exchange および Office XNUMX は、Notes の統合されたタブ付きテーブル、ボタン、保存されたフォーム、およびその他の独自コンテンツをサポートしていません。 そのため、この機能が失われることに備えるか、これらの要素を移行可能な形式に変換できる移行ソリューションに投資する必要があります。 Quest のソリューションはこれをいかなる方法でも変換せず、ユーザーが Notes クライアントを通じて開くことができるように、そのような手紙を添付ファイルとして転送することしかできないと言いましょう。

グループと個人のアドレス帳

多くの組織は、社内および社内向けに公開メーリング リストを広範囲に利用しています。
外部コミュニケーション。 さらに、Notes ユーザーは多くの場合、ビジネス上の連絡先を個人のアドレス帳に保存することが重要であると考えています。 これらのデータ ソースはビジネス運営にとって重要であり、Microsoft プラットフォームへの移行中に効率的に変換する必要があります。 そのため、Active Directory への移行に備えてグループを自動的に準備し、ユーザーのデスクトップに保存されているものも含め、すべての個人アドレスを効率的に変換することが重要です。

Notes アプリとの対話

調整プロセスなど、アプリケーションとメール サービス間の統合ポイントは、移行を計画およびスケジュールするときに重要です。 IBM Notes では、他のプラットフォームに比べて電子メールとアプリケーションが緊密に統合されています。 これらの統合には、単純なドキュメントリンクからビジネス プロセスまであらゆるものを含めることができます。

リソースとメールデータベース

多くの組織は、Notes のリソース予約データベース、メール データベース、その他の共有データベースを使用しています。 結果として、これらのデータベースは組織の機能において重要な役割を果たします。 ビジネスの継続性と従業員の生産性を確保するには、以下のアプローチと実装のタイミングを考慮することが非常に重要です。

• ターゲット環境でのリソース メールボックスの作成。
• 予約データベースからExchangeへのデータの転送。
• 両方のシステムのユーザーが Notes と Exchange のリソースを共同作業して使用できるようにします。

ステップ 4: 移行効率を最大化する

データの正確性を確保することに加えて、組織の要件を考慮して移行が可能な限り効率的に行われるようにすることも重要です。 移行の有効性は、直接的なコストだけでなく、ビジネスへの影響の程度にも直接依存します。

移行ソリューションのアーキテクチャ

効率に影響を与える最も重要な要素の 30 つは、移行ソリューションのアーキテクチャです。 5000 つの移行サーバーで複数のユーザーを同時に移行できるマルチスレッド アーキテクチャを備えたソリューションを選択することが重要です。 マルチスレッド アーキテクチャにより、移行ハードウェア要件が軽減され、移行速度が向上し、プロジェクト全体のコストが大幅に削減されます。 マルチスレッドであると主張しながら、実際には一度に 365 ユーザーのみを移行し、一度により多くのユーザーを移行するにはワークステーションを追加する必要がある移行ソリューションに騙されないでください。 構成と環境に応じて、真のマルチスレッド ソリューションは、Exchange および Office XNUMX にデータを移行する際の効率が XNUMX ～ XNUMX パーセント向上します。

移行プロセス

移行には多くの手順が含まれており、スムーズな移行を実現するには適切なタイミングでプロセスを実行する必要があります。 ビジネスの中断を最小限に抑え、移行のメリットを最大化するには、移行のすべてのステップをタイムリーに処理できる単一のアプリケーションによってすべてのプロセスを統合および制御する必要があります。

柔軟性とセルフサービス

一部のユーザーおよび部門は、標準の移行プロセスから逸脱する必要があります。 たとえば、法務部門にはさまざまなストレージ要件がある場合や、管理者はメールボックスとアーカイブ全体を移行する必要がある場合があります。 したがって、移行チームがこれらの要件に簡単に適応できる柔軟な移行ソリューションを選択することが重要です。 この柔軟性を提供する最も効果的な方法の XNUMX つは、一部のユーザーに対してセルフサービスを有効にすることです。 たとえば、一部のユーザーは、メインのメール ファイルまたはローカル データから追加データを転送して、後でそれをサーバー上の個人アーカイブに変換することが許可される場合があります。

ステップ 5: テスト移行を実行する

移行前評価が完了し、共存戦略が最終決定され、最適化計画が定義されたら、XNUMX つ以上のパイロット移行を通じて戦略の確認を得ることが重要です。

パイロット移行の目的は、開発された手順をテストし、完全な移行の開始後に発生する可能性のある問題を特定し、ライブ マイグレーションを開始する前に問題を解決する機会を与えることです。 その結果、パイロット移行中に問題が発生することが予想され、さらには歓迎されることになります。

パイロット移行の量の決定

パイロット移行は、データの代表的なサンプルを収集し、戦闘移行中に遭遇する可能性のある関連質問に答えるのに十分な規模である必要があります。 数千のメールボックスを移行する場合は、サンプル サイズで十分です。 非常に大規模な移行の場合、パーセンテージはこれより少なくなる場合があります。

データとシステムの選択

パイロット移行プロセスでは、戦闘データと戦闘システムを使用することが重要です。 これはいくつかの理由から非常に重要です。

• 戦闘環境がどのように動作するかを理解する必要があります。 合成的に生成された環境は戦闘環境を表すものではありません。
• サンプル データに基づいて、暗号化されたメッセージ、Exchange にないメッセージ タイプの頻度、およびストレージ要件に関する詳細情報を取得できます。

期待を設定する

パイロット移行プロセスは、プロジェクトに概要が示されている成功基準をテストし、残りの移行に対する期待値を調整する優れた機会も提供します。 調整が必要な場合は、それを文書化し、戦闘移行中に考慮する必要があります。

ステップ 6: 組織への影響を最小限に抑えるために移行時間を計画する

ユーザーのグループ化

ユーザーと組織全体への影響を最小限に抑えるには、一緒に作業するユーザーを同時に移行する必要があります。 これらのグループを作成するときに考慮すべき主な要素には、委任が含まれます。 ソース環境のユーザー関係に関する情報に基づいて、移行用のコレクションを推奨できるソリューションを探してください。

移行のタイミング

グループの移行が完了したら、必ず移行時間をスケジュールしてください。
これらのユーザーへの影響は最小限です。 これは、営業時間中、月末、またはメンテナンス期間中の移行を避けるために、移行期間を XNUMX 日の特定の時間帯にスケジュールすることを意味します。 たとえば、営業チームはおそらく四半期の終わり近くまで移行すべきではありませんし、会計部門や法務部門は移行できる時期に制限がある可能性があります。

ステップ 7: 移行を開始し、その進行状況を追跡する

試験的に検証されたデータ移行アプローチが導入されれば、戦闘移行は日常的なイベントになるはずです。 特定のグループのニーズに対応するために、プロセス全体で若干の調整が行われる可能性があります。 計画と試験段階ですべての不測の事態が考慮されていることを確認するには、引き続き注意深い監視が必要です。 ただし、プロセスはますます自動化する必要があります。 戦闘移行スケジュールの実行は、進捗状況を文書化して組織全体に伝達し、期待が満たされていることを確認するために重要です。 モニタリングとフィードバックは、プロセス全体を通じて移行を成功させるための重要な要素であり続けます。

まとめ

郵便サービスを移行する際に考慮する必要がある事項について説明しました。 現在、移行ソリューションの選択中である場合、またはちょうどそれを検討している場合は、これらすべてを考慮することが重要です。 当社は Quest の移行ソリューションと連携しており、手動手順の数を減らし、移行の結果として転送されるデータ量を増やすのに最も効果的なソリューションとして推奨する用意があります。

移行に対する効果的なアプローチについて詳しく知りたい場合は、リクエストを送信してください。 フィードバックフォーム 当社の Web サイトまたは電話でお問い合わせください。また、以下のリンクを使用して追加の資料を学習することもできます。

Habr 記事: IBM Lotus Notes/Domino から Microsoft Exchange への移行

Gals Web サイトの Notes to Exchange 用 Quest Migrator

Gals Web サイトのメモ用 Quest Coexistance Manager

Quest Web サイトの Notes to Exchange 用 Quest Migrator

Quest Web サイトのメモ用 Quest Coexistent Manager

出所： habr.com