ITサービス企業向けデータ移行：チケット数からフルスコープまで
ほとんどのチームが手遅れになるまで気づかないことから始めましょう。サービスデスクは単なるツールではありません。それは、顧客とのあらゆる関係に関する情報そのものです。ですから、ITSMプラットフォームを切り替える際には、そのすべての履歴も一緒に移行する必要があるのです。.
Help Desk Migration 、エージェントを移動し、チケット、連絡先、および会社の履歴をきれいにマッピングすることで、完全なITSMデータの整合性を提供します。.
クレジットカードは不要です 素早いセットアップ
6万社以上の企業から信頼されています
データ移行の範囲：7つのレコードセット、1つのプロジェクト
データ移行の計画を立てる前に、サポートプラットフォーム内のすべてのレコードタイプを一覧化してください。現在のデータを確認して移行対象を決定し、ソースシステムとターゲットシステムを比較して、事前に正確なフィールドマッピング計画を作成します。.
| レコードセット | 内容物 | 映画で何を見るべきか |
|---|---|---|
| ヘルプデスクおよびサービスデスクのデータ | ケース、チケット、会話、ステータス、タグ、カスタムフィールド | これはプロジェクト全体の規模を左右する。まずは範囲を明確にしよう。. |
| ITSM記録 | インシデント、サービスリクエスト、変更記録、問題記録、SLAポリシー、承認チェーン、構成アイテム | これら7つのタイプのうち3つは、直接転送ではなく、再マッピングまたは再構築が必要となるのが一般的です。 |
| ナレッジベース | 記事、カテゴリ、フォルダ、内部公開と公開設定、記事の添付ファイル | 表示設定は、ターゲットプラットフォームの同等の設定に必ずしも対応するとは限りません。 |
| 顧客および連絡先データ | 企業、連絡先、サイト、組織階層、エージェントおよびグループ構造 | ターゲットプラットフォームがチームを異なる方法でモデル化する場合、グループ構造の再構築が必要になることがよくあります。 |
| メディアと添付ファイル | インライン画像、ファイル添付 | 添付ファイルの量は、チケット数よりも移行期間を長くする可能性があります。 |
| メール履歴 | チケットに関連付けられた受信および送信スレッド、ヘッダーの保持 | ヘッダーの保持は、ソースプラットフォームが実際に何を保存するかに依存し、何を表示するかだけに依存するわけではありません。 |
| 通話記録と録音 | 電話記録およびチケットに添付された録音リンク | 通常は電話システムへのリンクであり、保存された録音データではありません。移行するのは参照情報であり、音声データではありません。. |
注釈： レコードセットごとのカバレッジは、ソースプラットフォームが公開する情報とターゲットモデルによって異なります。
チケットのことだけを考えてここに来た？誰もがそう思うでしょう。しかし、リスト全体を見れば、ITSM レコードの範囲がすぐにずっと明確になります。典型的なプロジェクト、 の移行を Ivantiや ServiceNow。
特定のプラットフォームについてさらに詳しく知りたい場合は、 Freshservice 移行ページ または Jira Service Management 移行 ページを参照して、その移行先における単一レコードセットの動作を確認してください。
ナレッジ ベース移行 ページでは、記事の構造と表示方法について解説しています。移行に着手する前にプラットフォームを検討中ですか？それなら、 IT企業向けヘルプデスクソフトウェア。
明確に指摘しておきたい点が一つあります。「データ移行」には、このページでは触れていない2つのプロジェクトも含まれます。 Database とアプリケーションの移行は、 ビジネスを支えるシステムを移行するものであり、サービスデスクを移行するものではありません。 エンドポイントまたはテナントの移行は 、デバイスとユーザーアカウントを移行するものであり、ケースやチケットを移行するものではありません。どちらも実際に存在するプロジェクトですが、以下のプレイブックは必要ありません。
サポートされているITSM移行統合
Accelo
Atera
Atlas
Autotask PSA
BMCHelixITSM
BoldDesk
Chatwoot
ConnectWise
Crisp
CSV
Custify
Deskpro
DevRev
Dixa
Document360
Drift
Dynamics 365
eDesk
eGain
Enchant
Forumbee
FreeScout
Freshchat
Freshdesk
Freshservice
Front
FyneDesk
Gladly
Glassix
Gleap
GLPI
Gmail
Google Docs
Gorgias
Groove
Halo Service Solutions
HappyFox
Harmony
HelpCrunch
HelpDesk
HelpDocs
Helpjuice
Help Scout
HelpShift
HelpSpot
HubSpot Service Hub
InstantDocs
Intercom
Ivanti
Jira Service Management
Jitbit HelpDesk
Kayako
Kayako Classic
KnowledgeOwl
Kundo
Kustomer
Lansweeper
Live Agent
LiveChat
Manage Engine
Mayday
Missive
NinjaOne
Odoo Helpdesk
Oracle Service Cloud (RightNow)
osTicket
((OTRS)) Community Edition
Outlook
Paligo
Plain
Planhat
Pylon
Reamaze
Request Tracker
Respond.io
Richpanel
Salesforce Service Cloud
ServiceDesk Plus
ServiceNow
SherpaDesk
Siit
SmarterTrack
SolarWinds Service Desk
SolarWinds Web Help Desk
SparrowDesk
Spiceworks
Spiceworks Cloud
SQLite
SuperOps
SupportBee
SupportPal
Syncro
SysAid
SysAid (Cloud)
Tawk.to
TeamSupport
TeamworkDesk
Thena
Thulium
Tidio
TOPdesk
Trengo
Unthread
Vitally
Vivantio
Zammad
Zendesk
Znuny
Zoho Desk
Zoho Mail
名前に誤字がないかご確認いただくか、 メッセージを残してください。
スムーズに売れるレコードの種類と、めったに売れない3種類のレコードの種類
すべてのレコードタイプが同じように移行できるわけではありません。チケットや添付ファイルといったコアITSMレコードはほぼ完全に忠実に移行できますが、運用ロジック（特にSLA、承認チェーン、構成アイテム（CI）の関係）は単純に移動することはできません。移行計画を成功させるには、これら3つのプラットフォーム依存資産に必要なカスタム再マッピングと再構築を考慮に入れる必要があります。.
| レコードタイプ | 典型的なパターン | 状態 |
|---|---|---|
| 事件 | 直接移動します | コアチケット構造は通常、プラットフォーム間で1対1で対応します。 |
| サービスリクエスト | 直接移動します | ほとんどのターゲットスキーマにおけるインシデントと同じ構造パターン |
| 変更記録 | 直接移動します | ほとんどのITSMプラットフォームのチケットと構造的に類似している |
| 問題記録 | 直接移動します | ほとんどのITSMプラットフォームのチケットと構造的に類似している |
| カスタムフィールド | スキーマの一致を条件として直接移動します | 忠実度は、対象スキーマに同等のフィールドが存在するかどうかに依存する。 |
| 添付ファイル | 直接移動します | ファイルレベルの転送、通常は変更なし |
| SLAポリシー | 再マッピングが必要 | メインのデータ転送を行う前に、ターゲットシステムでSLA目標（初回応答時間や解決時間制限など）を手動で再構築してください。 また、カスタマイズによって、過去のSLA指標を個々のチケットの静的な読み取り専用データとして保存することもできます。 |
| 承認チェーン | 通常はターゲットで再構築されます | このプラットフォームは、承認ロジックとステータスをポータブルレコードとして保存するのではなく、自身で計算します。 |
| 構成アイテム | 再マッピングが必要 | CIの関係は、ターゲットのCMDBが資産と依存関係をどのようにモデル化するかに依存します。 |
なぜたった3種類のレコードタイプだけが問題になるのでしょうか？ それは、SLAポリシーと承認チェーンはそもそも「データ」ではなく、ロジックだからです。ターゲットプラットフォームは、独自のエスカレーションルールとワークフローエンジンを通じてSLAクロックと承認状態を再計算します。あるプラットフォームから数値をそのまま別のプラットフォームに貼り付けて、同じ意味になることを期待することはできません。構成アイテムも、別の角度から同様の壁にぶつかります。CIの関係は、ターゲットCMDBが資産と依存関係をどのように構造化しているかに依存しますが、その構造はソースプラットフォームの構造とフィールドごとに一致することはほとんどありません。
インシデント、サービスリクエスト、変更記録、問題記録には、この問題はありません。これらはほとんどがフラットなレコードで、ステータス、説明、カスタムフィールド、添付ファイルで構成されています。構造を維持し、スキーマが一致しないフィールドを再マッピングすれば、大きな問題なく相互に連携できます。.
顧客事例
e-Coreは、クライアントを Zendesk から Jira Service Managementに移行させた。
Zendesk から Jira Service Management への移行
チケット、連絡先、エージェント、会社、添付ファイル、メモなど、すべてがきちんと整理されていました。ところが、チームは一つだけ問題に直面しました。移行後、すべてのチケットの組織割り当てが勝手に変更されてしまい、それを固定するために独自の仕組みを構築する必要があったのです。.
そこで彼らは作業を2段階に分け、 まずクローズ済みのチケットを処理し、次に残りのチケットを処理することにした。 これはITSM移行において繰り返し見られるパターンだ。サービスデスクの構造の大部分は移行後もそのまま残る。例外となるのは、切り替え後に慌てて修正するのではなく、切り替え前に計画を立てておくべき部分である。
テストを実施することで、修正コストが低い段階でこれら3つの例外を検出できます。プロジェクトの範囲を定める 前に、このマトリックスに基づいて自社のレコードタイプを監査してください。後から監査するのは避けてください。
ITサービス企業におけるデータ移行の実際の運用方法
Help Desk Migration を使用した IT サービス デスクの移行は、セルフサービス型の移行ウィザードの 5 つの明確な手順に従って行います。.
プラットフォームを接続する
移行ウィザード内で、ソースプラットフォームとターゲットプラットフォームを接続します。両方のITSMツールのアクセス認証情報を入力すると、 Help Desk Migration 各接続を認証します。インストールやスクリプトは不要です。ウィザードは両方のスキーマを読み込み、転送可能なすべてのレコードタイプを一覧表示します。.
データを選択してください
移行するレコードセット（インシデント、エージェント、チケット、タスク、ナレッジベース記事）を選択してください。すべてを移行することも、移行範囲を定義済みのサブセットに限定することも可能です。ウィザードは選択したものだけを正確に移動し、それ以外のものは移動しません。ソースからレコードが1つでも離れる前に、ここでプロジェクトの境界を設定できます。.
畑を地図に描く
スキーマが一致しないフィールドはマッピングしてください。チケットのステータス、優先度、リクエストの種類、エージェント、カスタムフィールドをソースとターゲット間で整合させることで、誤った場所にデータが移動することを防ぎます。ウィザードはデフォルトのマッピングを自動的に提案し、個別の処理が必要な項目はユーザーが調整できます。この手順により、大量のレコードが移動する際に参照整合性が保護されます。.
デモ移行を実行する
本格的に導入する前に、無料のデモ移行を実行してください。ウィザードが少量のレコードを転送するので、ターゲットプラットフォーム上でフィールドマッピング、添付ファイル、およびリレーションシップを確認できます。結果を確認し、レポートをダウンロードして、すべてが正しくマッピングされていることを確認してください。必要に応じて、デモを何度でも調整して再実行できます。.
完全移行を開始する
デモが問題なく動作したら、フル移行を開始してください。 Help Desk Migration では、選択したすべてのレコードセットがダウンタイムなしでターゲットプラットフォームに転送されるため、チームは作業を継続できます。その後、デルタ移行を実行して、転送中に作成されたチケットを移動し、移行作業を完了させてください。.
移行にかかる費用と期間
コストと納期はどちらも、以下の4つの変数によって決まります。
記録的なボリューム
移動中のチケット、インシデント、および関連記録の数
カスタムフィールド深度
各分野に必要なマッピング作業の量
ソースインスタンスの数
1つの机を1つに統合する、または複数の机を1つに統合する
APIの利用可能性
ソースプラットフォームがフィールドパスを公開しているか、Hexagon Software Group のようにカスタムフィールドパスが必要かに関わらず
Help Desk Migrationのスタンダードプランでは、事前設定なしの基本的な移行は1,000レコードで100ドルですが、同じ条件で10,000レコードの場合は514ドルとなり、10倍の価格には遠く及びません。移行規模が大きくなるほど、レコードあたりの料金は安くなります。そして、カスタムフィールドの深さは、レコード数よりもこの価格に大きな影響を与えます。.
ITSMデータ移行の成功事例
エコシステム横断的なITSMの動き
ブラジルのポルト・アレグレに拠点を置くアトラシアンのコンサルティングおよびアプリケーションアウトソーシング企業であるe-Coreは、顧客の1社を Zendesk から Jira Service Deskに移行する必要がありました。顧客の database 大規模で、新規に作成するのではなく、すべてのデータを保持したいと考えていました。Help Help Desk Migration 、転送を2つのパスに分割しました。まずクローズされたチケットを処理し、次に残りのボリュームを処理し、すべてのチケットが移行後に正しい組織割り当てを持つようにカスタム修正を作成しました。チケット、連絡先、エージェント、会社、添付ファイル、メモなど、その他のすべてのデータは問題なく移行されました。e-Coreは、本格的な移行に着手する前に複数のテスト移行を実行しました。これは、このページ全体が繰り返し言及している検証ステップです。同社のテクニカルリードは、必要なデータが Jira Service Deskに無傷で到着したことを確認しました。.
e-Coreの移行ストーリー
短い期間、 Zendesk 統合、パートナーのインスタンスをソースとして使用
Lenovo Private Cloud Solutionは、ルーマニアのブカレストに拠点を置く部門のために、パートナーの Zendesk インスタンスから自社のインスタンスへ大量のチケットを迅速に移行する必要がありました。完全マネージド型の契約ではなく、チームは移行ウィザードを使用してセルフサービス方式を採用し、短期間でインスタンス間のチケット移行を完了しました。しかし、スピードだけが目的ではありませんでした。Lenovo Lenovo 、将来の参照のために履歴データを保存する必要があり、運用マネージャーは後に、プロセス全体を通してアカウントチームが行ったフォローアップを高く評価しました。.
Lenovo プライベートクラウドソリューションの移行事例
APIのないレガシーソース
英国の不動産および財務管理専門ソフトウェア開発会社であるHexagon Software Groupは、ソース側でAPI接続を使用せずにReadyDeskから Freshdesk への移行を必要としていました。Help Help Desk Migration ヘルプデスクデータとナレッジベースの両方を網羅するカスタム移行パスを構築しました。通話履歴の保持は、想像以上に重要でした。Hexagonの収益はソフトウェアライセンスだけでなく、プロフェッショナルサービスに大きく依存しており、クライアントのシニアコンサルタントは後に、移行された履歴によって、チームはゼロから始めるのではなく、必要に応じて検索可能な記録を参照できるようになったと指摘しました。.
Hexagon Software Groupの移行事例ここに、3つの異なる形態の問題が存在します。エコシステム横断的なプラットフォーム移行、レコード量とタイムラインの両方における制約、そしてAPIのないレガシーソースです。これら3つを合わせると、おそらく貴社の移行作業の大部分を網羅することになるでしょう。ITサービスプロバイダー向けのデータ移行と呼ぶか、ITSM移行と呼ぶかは関係ありません。どちらにしても、作業内容は同じです。レコードを移動させるのです。チケットだけではなく。.
プロジェクトの範囲を定める前に、独自のレコードタイプをマッピングしてください。
要点はこうです。上記の表は、 Help Desk Migrationのパターンであり、推測ではなく実際のプロジェクトに基づいて構築されています。しかし、これはまだあなたのパターンではありません。ぜひ活用してください。そして、あなたのプラットフォームの組み合わせに当てはめてみてください。そうすれば、3週間後に修正費用がかさむ前に、どこで問題が発生するかを事前に把握した上で、スコープ設定の打ち合わせに臨むことができます。.
| レコードタイプ | 一般的なパターン | お使いのプラットフォームペアで確認済みですか？ | 再マッピングが必要ですか？ | 所有者 |
|---|---|---|---|---|
| 事件 | 直接移動します | はい（API対応） | 標準ステータスと優先順位のマッピング | サービスデスクリーダー |
| サービスリクエスト | 直接移動します | はい（API対応） | カタログアイテムのマッピングをリクエストする | サービスデスクリーダー |
| 変更記録 | 直接移動します | はい（スキーマ一致） | リスク、タイプ、理由のフィールドマッピング | 変更マネージャー |
| 問題記録 | 直接移動します | はい（スキーマ一致） | 根本原因と関連する事象の関係 | 問題管理者 |
| カスタムフィールド | スキーマの一致を条件として直接移動します | 監査が必要 | ターゲットに一致するカスタムフィールドを作成する | ITSM管理者 |
| 添付ファイル | 直接移動します | はい（直接ファイル転送） | いいえ（インラインとファイル添付を保持） | 移行リード |
| SLAポリシー | 再マッピングが必要 | ターゲットで再構築 | ターゲットの再作成、カスタムフィールドによる履歴指標 | サービスデリバリーマネージャー |
| 承認チェーン | 通常はターゲットで再構築されます | ターゲットで再構築 | 対象システムでワークフローエンジンを構成する | ITSMプロセスオーナー |
| 構成アイテム | 再マッピングが必要 | モデル依存 | アセットモデルとCI依存関係階層を整合させる | 資産管理／CMDB管理者 |
こちらのフォームにご記入ください。無料デモ移行の際にお持ちください。これは、推測で臨むのと計画を持って臨むのとでは大きな違いであり、スコープ設定に関する話し合いが始まる前にリスクを軽減する方法でもあります。.
よくある質問：ITサービス企業向けデータ移行
ITSM移行とは、ITサービス管理プラットフォーム内のレコード（インシデント、サービスリクエスト、変更レコード、問題レコード、SLAポリシー、承認チェーン、構成アイテムなど）を、あるプラットフォームから別のプラットフォームへ移動させることを意味します。これは一般的なヘルプデスク移行とは異なり、プラットフォームはこれらのレコードタイプのいくつかを保存するのではなく、その場で計算するため、通常は直接転送するのではなく、再マッピングを行います。ServiceNowや競合するITSMツールにプラットフォームを移行する際には、必ずこの移行作業ServiceNow発生します。
4つの移行に絞って論じています database 移行、アプリケーション移行、クラウド移行という Database 間で database データを移動します。アプリケーションは、あるソフトウェアシステムを別のソフトウェアシステムに切り替える際にデータを移動します。クラウドは、クラウドインフラストラクチャにデータを移動します。これら4つの移行はいずれも、サービスデスクを中心とするものではありません。 Help Desk Migrationのプロセスを 。
料金は、レコード数、カスタムフィールドの深さ、統合するソースインスタンスの数、およびソースプラットフォームがAPIを公開しているかどうかによって異なります。ここで注意すべき点は、カスタムフィールドのロジックが複雑な小規模なチケットは、大規模でシンプルなチケットよりもコストが高くなる場合があるということです。これは、チケット数よりもマッピング作業の方が価格に大きく影響するためです。最新の 料金 詳細をご覧ください。
ソースプラットフォーム、ターゲットプラットフォーム、そして作業のうちどの程度がマネージドサービスを必要とし、どの程度がセルフサービスで済むかによって異なります。特にサービスデスクやITSMの移行においては、 Help Desk Migration 間でファーストパーティのプロジェクトデータを移行できる 100以上の 向けに構築された汎用ETLツールとは一線を画しています databaseで、各配信モードを比較してください Help Desk Migration サービス ページ
これは通常、インシデント、リクエスト、変更レコード、構成アイテムを ServiceNow から ServiceNow 別のプラットフォームへ移行することを意味します。ServiceNow ServiceNow SLAと承認状態を内部的に計算するため、ServiceNowへの移行またはServiceNowからの移行では、これらのレコードタイプをそのまま転送するのではなく、再マッピングすることが一般的です。別のプラットフォームからへ、またはプラットフォーム固有の詳細については、 参照してください ServiceNow 移行ページを。
ITILフレームワークでは、サービス戦略、サービス設計、サービス移行、サービス運用、継続的サービス改善の5つの段階があります。プラットフォーム移行は、既存のサービスの提供方法を変更するだけで、その背後にある戦略を必ずしも変更するわけではないため、通常はサービス移行の段階に含まれます。移行先のプラットフォームにおけるAI支援機能も、この段階に影響を与えることが増えています。移行履歴への影響については、 「ITSMにおけるAI」を参照してください。
すべてのITサービス企業にとって最適なプロバイダーは存在しません。重要なのは、データ量、プラットフォームの組み合わせ、そしてソース側のAPIの可用性です。Help Help Desk Migration ており、規模の異なるITサービスデータ移行プロジェクトを 、これまで6万件以上のデータ移行プロジェクトを完了し数多く手掛けてきました。決定を下す前に、 Help Desk Migrationの顧客事例を、自社の業界やプラットフォームの組み合わせと比較検討することをお勧めします。
対象となるITSMプラットフォームとレコードの種類によって異なります。 Help Desk Migration に対応しています ServiceNow、 Jira Service Management、 Freshservice、 Zendesk、 SysAid、 Ivanti、ManageEngine ServiceDeskeDesk など、様々なは、 プラットフォーム。プロバイダーを選択する前に、ご自身のプラットフォーム構成に近いITSM固有の移行事例に関する公開されているケーススタディをご確認ください。
これらはしばしば「7つのR」と呼ばれます。クラウドインフラストラクチャの移行から派生したもので、リホスト、リプラットフォーム、再購入、リファクタリング、廃止、保持、再配置です。これらは、アプリケーションとワークロードをクラウドに移行する方法を説明するものであり、サービスデスクのレコードをプラットフォーム間で移行する方法を説明するものではありません。サービスデスクの移行は、独自のレコードタイプとシーケンスを持つ独自のプロジェクトです。ヘルプ ご覧ください Help Desk Migration 処理するかについては、こちらを。
ITSM（ITサービスマネジメント）とは、ITサービスの設計、提供、サポートに使用する手法全般を指します。具体的には、インシデント管理、変更管理、リクエスト処理などが含まれます。ITSMは、 Jira Service Management参照してください のような専用プラットフォーム上で動作し、これらのプロセスは構造化されたレコードとして管理されます。レコードセットがプラットフォーム間でどのように移行されるかについては、 への移行」を Jira Service Management。
ITSMサービスデスクの移行準備はできていますか？
無料のデモ移行を実行して、ターゲットプラットフォーム上で実際のデータをテストしてください。ステージング環境もダミーデータも不要です。実際のデータが適切な場所に配置され、すぐに検証できます。.
クレジットカードは不要です SOC 2 認証取得済み 4万件以上の移行が完了しました