KopanoメールボックスをGrommunioまたはZammadに移行する：最適な方法を選択する

適切な移行パスは、「メールボックス」の意味によって異なります。グループウェアメールボックスにメールを保持するKopanoの代替ソリューションが必要な場合は、grommunioのKopano移行パスを使用してください。受信メールが顧客との会話やチケットに変換される共有サポートキューが必要な場合は、Zammadが適しているかもしれませんが、Zammadはヘルプデスクであり、グループウェアメールボックスの代替ソリューションではありません。Zammadの現在の移行ドキュメントには、Kopanoが直接インポート元として記載されていません。

その違いによって、成功の定義が決まります。grommunioでは、ユーザーはメールを見つけることができ、別途移行作業を行った後、その他のサポート対象のグループウェアデータも確認できる必要があります。Zammadでは、エージェントは選択した通信内容が、サポートワークフローに従って顧客と所有者がマッピングされた、正しくグループ化されたチケットと記事として表示される必要があります。パイロットテストと受け入れチェックなしに、どちらのターゲットもKopanoのバイト単位のコピーとして扱うべきではありません。

データをコピーする前に、コピー先を選択してください。

grommunioの移行概要ではgromox-kdb2mt、Kopano/Zarafaへの移行を推奨しており、この移行方法ではMAPIプロパティを含むメールボックス全体を移行できると説明しています。IMAP移行の場合は、メールとフォルダは移行されますが、カレンダーや連絡先は移行されません。ツールを選択する前に、grommunioの最新の移行概要をお読みください。

移行計画を立て、受け入れチェックを定義する。

一括コピーではなく、まずはインベントリから始めましょう。各Kopanoユーザー、プライマリアドレスとエイリアスアドレス、ストア識別子、メールボックスサイズ、アイテム数、クォータ、共有フォルダ、委任先、パブリックフォルダ、およびユーザー認証を行うサービスを記録します。KopanoがLDAPを使用しているかどうか、添付ファイルがデータベースに保存されているかファイルシステムレイアウトに保存されているかをメモしておきます。メールボックス転送では、ディレクトリ構成、メールルーティング、およびアクセス許可を残したままコンテンツを移動できます。

実際の環境を代表する小規模なパイロットセットを選択します。通常のメールボックス1つ、大型メールボックス1つ、および共有アクセス、英語以外のフォルダ名、または通常とは異なる添付ファイルを持つメールボックスをそれぞれ1つずつ選びます。ソースとターゲットをバックアップし、最初のインポートを使い捨ての、またはクリーンなターゲットメールボックスに行います。ツールを実行する前に、測定可能なチェック項目を定義します。

• ネストされたフォルダを含め、ソースとターゲットのフォルダツリーとメッセージ数を比較します。
• 過去および最近のサンプルメッセージを開き、送信者と受信者の表示、日付、本文、添付ファイルを確認します。
• 移行方法が保持すると想定される未読状態とフラグ付き状態を確認してください。
• カレンダー、連絡先、タスク、代理人、共有リソースはそれぞれ個別にテストしてください。メールのインポートが成功したからといって、それらが成功したと推測しないでください。
• スキップされたオブジェクト、エラー、および差異を記録し、それらが許容範囲内であるか、または別の方法が必要かを判断する。

オプションA：Kopanoをgrommunioに移行する

メールボックスの整合性が必要な場合は、Kopanoデータベース移行パスを使用してください。

gromox-kdb2mtサポートされている Kopano データベースの場合、grommunio はと を組み合わせた直接パスを文書化していますgromox-mt2exm。最初のユーティリティは、Kopano SQL データベースとその関連付けられた添付ファイルストレージから 1 つのストアを読み取ります。2 番目のユーティリティは、転送ストリームを grommunio メールボックスにインポートします。別のデプロイメントから汎用コマンドラインをコピーするのではなく、インストールされているバージョンの呼び出し構文とオプションに従ってください。

移行プロセスでは、ソースSQLサービスと必要な添付ファイルにアクセスできる必要があります。現在のgromox-kdb2mtマニュアルには、サポートされているデータベーススキーマのバージョンが記載されており、インストールにはattachment_storage=files_v1-x-y対応するオプションが必要であること--l1が示されています--l2。ソースのレイアウトが異なる場合は、一時停止してストレージマッピングを解決してから、完全なインポートを試みてください。

インポート前に、対象ドメインとメールボックスを準備してください。KopanoがLDAPでサポートされている場合は、grommunioが同じディレクトリを使用するかどうかを決定し、ストアを転送する前にユーザーのマッチングをテストしてください。公式のKopano移行ガイドでは、複数ステップのフローが説明されています。該当する場合は、対象のディレクトリ統合を設定し、ストアを作成し、ユーザーデータを移行し、メールルーティングを切り替えます。また、このガイドがすべてのソースインストールを網羅しているとは限らない点にも注意が必要です。

ユーザーを意図的にマッピングしてください。Kopanoのデータベースでは、単純なメールアドレスではなく、数値またはGUIDメタデータによってストアを識別する場合があります。grommunioドキュメントは、kdb-uidextract稼働中のKopanoシステムからユーザーマップを作成するためのヘルパーとして機能します。kdb -uidextractマニュアルを参照してください。マッピングは、受信者アドレスとアクセス制御エントリに重要です。共有フォルダのアクセス許可がターゲットに存在しないIDを指していても、転送は技術的に成功する可能性があります。

IMAP同期は、その制限があなたの用途に合致する場合にのみ使用してください。

直接データベース移行が利用できない場合、またはメールのみが必要な場合は、KopanoでIMAPが有効になっていてアクセス可能な場合、IMAP同期が実用的な代替手段となります。grommunioのドキュメント化されたimapsyncワークフローは、繰り返し実行可能なフル実行とデルタ実行をサポートし、メールフォルダ、標準フラグ、内部日付を保持します。ただし、重要な制限事項があります。IMAPでは、カレンダー、連絡先、タスク、メモ、サーバー側ルール、委任、パブリックフォルダ、パスワードは転送されません。

まず、ターゲットメールボックスとクォータを準備し、認証情報を保護されたファイルに安全に保管し、最初のコピーを実行する前に接続テストを実施してください。パイロットメールボックス1つに対して初期同期を実行し、grommunio Webで結果を確認してから、メールフローのリダイレクト後に差分同期を繰り返してください。詳細なgrommunio IMAP移行ガイドには、準備、ドライランチェック、フォルダマッピング、差分同期、切り替え、トラブルシューティングに関する情報が含まれています。削除する内容を正確に確認しない限り、ミラーリングや削除オプションは使用しないでください。

オプションB：選択した通信をZammadに移行する

Zammadは、記事、顧客、グループ、エージェントを含むチケット形式で作業を整理します。カレンダー、連絡先、タスク、フォルダ権限、通常のメールクライアントの動作を備えたExchangeスタイルのメールボックスは再現しません。移行に関するドキュメントには、現在サポートされているソースシステムとしてFreshdesk、Kayako、OTRS、Zendeskなどが挙げられていますが、Kopanoは含まれていません。ドキュメントによると、サポートされていないソースからの移行には、APIベースのアプローチまたはカスタム移行作業が必要となります。

インポーターを作成する前に、変換ルールを定義してください。どの Kopano メールボックスまたはフォルダがサポートリクエストを表すか、メッセージを会話にグループ化する方法、送信者を Zammad の顧客にマッピングする方法、古い所有権やカテゴリを Zammad グループやエージェントにマッピングする方法を決定します。メールボックスは自動的にチケットキューになるわけではありません。個人的なやり取り、ニュースレター、下書き、自動通知などは、顧客向けのチケットには適さない場合があります。

履歴データについては、サポートされている Zammad API またはカスタムマイグレーターを使用して、管理されたエクスポートおよびインポートプロセスを計画してください。ターゲットデータモデルで可能な場合は、元のメッセージの日付とヘッダーを保持し、添付ファイルを保持し、追跡可能性のためにソースメールボックスとメッセージの識別子をログに記録してください。まず、少量のサンプルを新しい Zammad インスタンスにインポートしてください。Zammad の一般的な移行ルールでは、ソース移行はすべてかゼロかで、新しいインスタンスが必要であると規定されています。これらのルールは、ドキュメント化された移行モジュールに関するものであるため、カスタムインポーターの動作は別途確認してください。

切り替え後に新しいサポートメールを作成または受信するアドレスを接続するには、Zammadのメールチャネルを使用してください。Zammadのメールチャネルに関する最新のドキュメントでは、メールプロバイダの接続と受信メッセージのルーティングについて説明しています。チャネルの設定と過去のメールボックスのインポートは、別々のタスクとして扱ってください。テストされていないインポーターに実際の顧客の受信トレイを向けないでください。チケットの重複、予期しない返信、またはルーティングの誤りにより、実際のユーザーに影響が出る可能性があります。

受信メールを失うことなく切り替えが可能

承認期間中は、Kopano を常に利用可能な状態にし、バックアップを取っておいてください。パイロットテストが成功したら、メインの移行を実行し、ソースのベースラインを記録します。短い変更期間を設けて、配信を一時停止またはリダイレクトし、最終的な差分インポートまたはキャッチアップインポートを実行し、MX または内部ルーティングを切り替えてから、組織内外からテストメッセージを送信します。grommunio の移行概要では、移行中に到着したメッセージが漏れないように、DNS/MX 切り替え後に最終的な差分を実行することを特に推奨しています。

ユーザーサインイン、クライアント設定、自動検出、モバイルデバイス、エイリアス、リレールール、およびKopano経由で送信するすべてのアプリケーションを更新してください。これらはメールボックスデータのコピーとは別個の作業です。ロールバック計画を策定し、メールを元のサーバーにルーティングする方法、ユーザーが元のサーバーにアクセスする方法、およびターゲットサーバーが受信に失敗した場合のロールバックを承認できる人物を把握しておいてください。

結果をどのように判断するか、そしてアプローチを変えるべきタイミングは何か

移行が通常使用できる状態になったのは、移行先のフォルダと代表的なコンテンツが合意された許容範囲内で移行元と一致し、ユーザーが最近のメッセージと過去のメッセージを見つけられ、添付ファイルが開き、メールの送受信が双方向で正常に機能する場合です。grommunio の場合は、カレンダーと連絡先の移行、共有アクセス、ディレクトリへのログイン、クライアントの動作を個別に確認してください。Zammad の場合は、チケットの境界、記事の順序、顧客の一致、可視性、割り当て、および古いメッセージが意図しない送信応答をトリガーしていないことを確認してください。

パイロットテストで、MAPI データの欠落、添付ファイルの破損、未解決の ACL、または IMAP コピーでは引き継げないグループウェア機能の保持が必要であることが判明した場合は、方法を変更してください。Zammad の場合、主な要件が個人用メールボックスの継続性またはカレンダー/連絡先のサポートである場合は、移行先を再検討してください。カスタム移行ではデータ モデルを橋渡しできますが、マッピング、テスト、およびメンテナンス作業が追加されます。これは、ネイティブの Kopano メールボックスのインポートとは異なります。ユーザーと管理者が必要なレコードを確認できるようになるまで、Kopano を読み取り専用にするか、別のアーカイブを保持してください。