エージェント型信頼プラットフォームであるVantaは、カスタムフィールドマッピングと履歴データ保存機能を使用して、 Freshservice へ Jira Service Managementから128,000件以上のチケット、512,000件のコメント、86,000件の添付ファイルを移行し、 を使用して21日間で移行を完了しました Help Desk Migration。
Vantaについて
Vantaは 、企業がコンプライアンスを自動化し、リスクを管理し、継続的に信頼性を証明できるよう支援するために2018年に設立された、ナンバーワンのエージェント型信頼プラットフォームです。同社は、より強力なデータ保護に対するニーズの高まりに応える形で設立され、当初は SOC 2、 HIPAA、ISO 27001などの規格に準拠したコンプライアンスプロセスの自動化に注力していました。
現在、VantaはAIを活用した単一のプラットフォームを提供し、組織がセキュリティ、コンプライアンス、リスクを継続的に管理できるよう支援しています。15,000社以上の顧客から信頼を得ているVantaは、Atlassian、Duolingo、Icelandair、Ramp、Synthesiaなどの企業にサービスを提供しています。Vantaのプラットフォームは、企業が継続的なリアルタイムプロセスを通じて信頼を構築、維持、実証することを可能にします。同社は、企業がデータを保護し、コンプライアンスを効率化し、大規模な信頼性を証明できるよう支援することに引き続き注力しています。.
VantaのコーポレートエンジニアリングチームでITオペレーションを統括するジャニース・コールドウェル氏に、 Freshservice から Jira Service Management への移行についてお話を伺いました。彼女はヘルプデスクサポート、社内チケット管理、ITシステムを統括し、自動化、拡張性、効率的なサービス提供に重点を置いています。ジャニース氏は、 Help Desk Migrationを通じて、Vantaの移行目標、主な課題、JSMへの移行経験について語ってくれました。.
Freshservice → Jira Service Management 移行:数字で見る概要
Freshservice から Jira Service Managementに移行されたチケット
コメントは元のチケットのコンテキストとともに転送されます
添付ファイルは移行され、保存されました
リクエスターとエージェントが移行しました
プロジェクト開始からエンドツーエンドの完了までの日数
Vantaが Freshservice から Jira Service Managementへの移行を決めた理由
JSM は社内リクエストポータルです。IT部門はハードウェア、ソフトウェアへのアクセス、トラブルシューティングのリクエストに利用していますが、人事部門、ワークプレイス、GTMシステム、HR、アクセス管理部門の共有プラットフォームとしても活用されています。基本的に、Vantanの全従業員がリクエスト元としてJSMを利用しており、IT/エンタープライズエンジニアリング担当者も日々JSM上で業務を行っています。また、Slackとの連携機能も備えているため、チケットはSlackとJSM間で双方向に同期されます。
Freshservice 私たちのニーズに追いつかなくなっていました。拡張性、柔軟性、そしてシステム連携のいずれも、私たちの成長に伴って不足していたのです。より優れたワークフロー、より詳細なレポート機能、そして他のエンジニアリング/ITツールとのより緊密な連携を求めて、私たちはJSMへの移行を決断しました。.
移行の概要
移行されたデータの範囲
チケット数12万8000枚以上、
コメント数51万
、添付ファイル数8万6000件
移動されたデータ型
チケット、コメント、添付ファイル、依頼者、エージェント、グループ
カスタマイズ内容は保持されます
ステータスワークフロー、カスタムフィールド、優先度スキーム、チーム
移行オプション
デモ移行、インライン画像、移行済みチケットへのタグ追加、再移行。.
タイムライン
21日間、最初から最後まで
結果
JSM上で統合されたITSMにより、移行全体を通して完全な監査証跡の整合性が維持されます。.
課題
- Freshservice とJSMのフィールドは、フィールドごとに完全に一致するわけではありません。.
- すべてのチケットには、元の記者と担当者の情報が記載されていなければならなかった。.
- カタログ項目、承認フロー、および自動化機能はJSMで再構築する必要がありました。.
- 重複または時代遅れの要求タイプは、単に複製するのではなく削除してください。.
- デモ移行を実施することで、本格的な移行を行う前に、報告者と担当者のマッピングに関する問題など、ギャップを早期に特定することができました。.
Vantaのニーズに合わせたカスタマイズ機能とすぐに使える移行オプション
Jira Service Managementにおいて、最も重要視して保存すべきデータはどれでしたか?
過去のチケットデータを保存することは、継続性と監査の観点から重要でした。当社はコンプライアンス企業であるため、タイムスタンプやリクエスト履歴を表示できることは、自社の SOC 2 監査などにおいて重要です。また、組織的な知識が失われることなく、新しいシステムでもチームが過去のチケットを検索できるようにしたいと考えていました。.
チームの具体的な要件に合わせて移行をカスタマイズできる機能はどれほど重要でしたか?また、どのカスタマイズが最も価値がありましたか?
カスタマイズは重要でした。Freshservice Freshservice すべての項目でJSMに完全に対応していたわけではありませんでした。例えば、JSMには直接対応する項目がなかったにもかかわらず、元の報告者名と担当者名が引き継がれるようにする必要がありました。.
また、移行を機に冗長なリクエストタイプや時代遅れのリクエストタイプを整理したため、カタログアイテム、承認フロー、自動化機能は単にコピーするのではなく、再構築する必要がありました。
デモ移行を実施することで、本格的な履歴データ移行に着手する前に、フィールドマッピングとデータ整合性を検証することができました。報告者/担当者フィールドの問題など、いくつかの問題点が早期に明らかになり、実際の移行を実行する前に修正することができたため、事後的に問題が発覚する事態を避けることができました。.
Vantaのデータとコンテキストを維持するために構築されたカスタマイズ
するように、移行には標準的なデータ転送以上の処理が必要でした Freshservice データが Jira Service Management 環境 移行は カスタマイズされました。これらのカスタマイズされたマッピングにより、移行されたデータは構造化され、検索可能で、VantaのチームがJSMで簡単に使用できるようになりました。
- チケットの説明に、以下のフィールド値を移行します:元のID、グループ、ソース、問題タイプ、人物問題タイプ、法的問題タイプ、AWSロール、カテゴリ。ソースフィールドが空の場合は、
空の値で移行します。 - サービスリクエスト(SR)のサービス項目をチケットの説明欄に移行します。
- 承認情報をチケットの説明欄に移行し、承認者の名前、メールアドレス、承認日を含めます。
- チケット作成時に、担当者と報告者のフィールドは渡さないでください。課題を「未割り当て」に設定し、報告者を「匿名」としてインターフェースに表示してください。
- 元の担当者をカスタム 「元の担当者 、元の依頼者を 「元の報告者 。
- エージェントが残したコメントには、コメントの冒頭に以下の形式で元のコメント投稿者の詳細を追加してください:
氏名(姓と名)email@vanta.com - 従業員のオンボーディングを 特定し、チケットの説明に反映させます。
- チケットの説明文中のフィールド名を 太字。
データ管理を強化するための、すぐに使える移行オプション
追加の移行オプションを使用することで、重要なチケットコンテンツが移行後もアクセスしやすく、管理しやすい状態を維持できるようにしました。インライン画像はチケットの添付ファイルとして保持され、カスタムタグは移行されたレコードの識別と整理に役立ちました。.
- インライン画像をチケット添付ファイルとして移行する: チケットコンテンツに直接埋め込まれた画像を、個別のチケット添付ファイルとして転送することで、移行後もアクセス可能な状態を維持します。
- 新しいタグを追加します。グループフィールドに基づいてチケットにタグを付けます。グループが指定されていない場合は、「
migrated-no group」タグを追加します。これらのタグすべてに「FS-」という接頭辞を追加します。 - プレミアムサポートパッケージに は再移行が含まれており、これはまさにVantaチームが必要としていたものでした。必要なカスタマイズと初期テストをすべて完了した後、再移行によって最終的なデータ転送をエラーなく実行することができました。
結果:履歴データがそのまま保持された統合JSMプラットフォーム
複数のシステムをやりくりする必要がなくなり、統合されたプラットフォームが利用できるようになりました。新しいポータルでは、レポート機能と自動化機能が向上し、過去のチケットも検索可能になっています。ローンチ後には通常通りの調整期間がありましたが、大きな問題はなく、ほとんどが想定内の整理作業でした。.
フィードバック

「調査から完全な切り替えまで、プロジェクト全体で数ヶ月かかりました。9月上旬にJSM自体を稼働させ、その後 Help Desk Migration を使って過去のチケットを移行しました。当初の目標期日より少し遅れましたが、急いで作業するのではなく、マッピングを正確に行うために時間をかけたので、結果的には良かったと思っています。」.
同様の移行を検討している他のチームにも、 Help Desk Migration お勧めします。チームは迅速に対応してくれ、非常に複雑な過去のデータ移行をスムーズに進めてくれました。