複数のITSMシステムを1つに統合する方法（データ損失やチームの混乱を招くことなく）

による投稿 クリス・ブランド

2026年5月27日更新

最近、あるクライアントが、成長中のサービス企業なら誰もが経験するであろう問題を抱えて当社に相談に来ました。彼らの業務はClickUpと Freshserviceへの移行を HaloPSA決定し、このツールで両方のツールを置き換えることができると判断しました。しかし、これには障壁がありました。顧客がサービスの継続性のために依存している長年の履歴データを保持する必要があったのです。つまり、新しいツールへの移行を阻む最大の障害は、誰もやりたがらない作業、つまり データ移行だった。

技術的な解決策は、私たちが呼ばれる頃にはたいてい明確になっています。より適したプラットフォームが存在するからです。問題は どのツールを、そこに至るまでに時間がかかり、費用がかさみ、予測不可能になるのではないかという不安です。チケットが紛失したり、レポートが機能しなくなったり、チームが反発したり、規制当局や顧客から異議が出たり、コストが超過したりするかもしれません。
しかし、これらはどれも避けられないことではありません。適切に行えば、データ移行は適切なツールでビジネスを運営する上での障壁にはならないはずです。統合は、単にデータをAからBに移動させるだけでなく、ビジネスの実際の運営方法を改善する機会となるべきなのです。私たちの取り組み方をご紹介します。

統合の二つの側面

統合プロジェクトは、混同しやすいものの、性質が大きく異なる2つの部分から成り立っています。.

まず一つ目は データ移行 。チケット、コメント、添付ファイル、ユーザー、カスタムフィールド、履歴レコードなどをソースプラットフォームからターゲットプラットフォームに移行する必要があります。これはまさに技術的な作業です。最も単純なケース以外では、APIを介して作業を行う必要があり、添付ファイルはチケットに依存し、コメントはユーザーに依存し、カスタムフィールドはスキーマに依存するなど、厳密な順序で処理する必要があります。フラットファイルインポートでは一部の処理は可能ですが、すべてを網羅することはできません。まさにこのような作業こそ、 Help Desk Migration 処理するために存在するのです。

2つ目は、 運用モデルの 再設計です。新しいプラットフォームが実際にビジネスでどのように機能すべきかを決定します。どのような種類のワークフローがプラットフォームを通過するのか？優れたレポートとはどのようなものか？どのキューを誰が管理するのか？以前は不可能だった、請求と請求書発行、顧客セルフサービス、統合された変更管理など、どのような新機能が利用可能になったのか、そしてそれらの機能のうち、どれを今すぐ有効にするべきか、それとも後で有効にするべきか？

この2つの要素は互いに必要不可欠です。前者だけを行うと、新しいシステムでも古い混乱状態がそのまま残ります。後者だけを行うと、履歴データが取り込まれないため行き詰まってしまいます。
統合プロジェクトの多くが失敗する原因は、それを単なるデータ移行作業として捉えてしまうことです。最大のメリットと最大のリスクは、運用モデルにあります。

統合が見た目より難しい理由

複雑さの一部は、本当に技術的なものです。一部は組織的なものです。最もよく見られる落とし穴は
次のとおりです。1. データマッピングが整然としていない。 異なるツールは同じ概念を異なる方法で構造化します。ステータス名、優先度レベル、チケットタイプ、カスタムフィールド、カテゴリ、リクエストタイプなど、1対1でマッピングできるものはほとんどありません。難しいのはマッピングを書くことではなく、マッピングがどうあるべきかを決定することです。そのため、準備が整う前に運用モデルの決定を強いられます。2
. エージェント/ユーザー/顧客モデルがツールによって異なります。 一部のプラットフォームは、内部エージェント、外部ユーザー、外部顧客を3つの異なるエンティティタイプとして分離します。他のプラットフォームはそれらを統合します。エージェントを外部パートナーにできるものもあれば、できないものもあります。Freshservice Freshservice 人をモデル化する Halo 方法とでは異なります Jira Service Management 。ユーザーの移行はコピー＆ペーストで済むことはほとんどなく、翻訳であり、ここで下す選択が、何年にもわたって権限、レポート、ライセンスに影響を与えます。3
. カスタムフィールドとチケットタイプが蓄積される。 ほとんどのソースシステムには、長年にわたって蓄積されたカスタマイズがあり、その一部は有用ですが、多くは忘れられています。全体を移行すると、新しいツールで同じメンテナンスの問題が再現されます。必要なものだけを移行すると、それらのフィールドを作成した人々と難しい話し合いを強いられます。
4. 権限は、簡単になるのではなく、より複雑になります。統合されたプラットフォームでは、通常、個々のソースよりも多くのチームがそれを使用します。つまり、新しい権限モデル、新しい可視性ルール、そして正しく行うためのより高いハードルが必要になります。なぜなら、間違いがより目立つからです。
5. レポートは、間違いが最初に現れる場所です。 ソースシステムには、特定のフィールド構造、ステータス、または命名規則に依存するレポートがあることがよくあります。ターゲットでこれらが変更されると、レポートが壊れ、関係者はすぐに気づきます。レポート要件は、移行の設計に組み込まれるべきであり、後から追加するべきではありません。
6. 通常、完全なリハーサル移行が必要になります。 サンプルでも部分的なものでもなく、実際のデータを使用して、構成済みのターゲットに対して、新しいシステムを実際に使用する人々によって実行される完全なUAT移行です。ここで、予想外のデータ構造、間違ったマッピング決定、調整が必要な統合など、本当の驚きが現れます。時間とコストを予算に計上してください。この段階を省略しようとすると、統合において最もコストのかかる近道となります。
7. 規制要件や顧客要件によって、保持しなければならないものが決まること がよくあります。顧客が「古いシステムを捨てて、新たに始めたい」と望む場合でも、顧客自身の顧客や規制当局が、監査目的で過去のチケット、コメント、添付ファイルを保持することを要求することがあります。コメントと添付ファイルの履歴は、最も多くのAPI作業と最も慎重な順序付けを必要とする部分であるため、移行の範囲は完全に変わります。データ保持要件が移行設計を複雑にした唯一の理由だったプロジェクトもありました。早期に把握してください。

実践的なアプローチ

これまで当社が実施してきた統合は、いずれもほぼ同じような流れをたどってきました。ラベルよりも順序の方が重要です。.

1. 実際に使用されているものを理解する。 マッピングを行う前に、ソースシステムが現在実際にどのように使用されているかを把握します。これは、本来の使用方法やドキュメントに記載されている内容ではありません。使用状況レポートを取得し、作業を行っている担当者に話を聞きます。通常、ソースシステムのカスタマイズのかなりの部分が休止状態にあるか、もはや関係がないことがわかります。これは問題ではなく、よりシンプルなターゲットに統合する機会です。
2. ターゲットオペレーティングモデルを定義する。 これは、私たちが何度も立ち返る質問です。新しいプラットフォームで、古いプラットフォームではできないビジネス上の機能を実現したいですか？より優れたSLAレポート？統合された請求とインボイス？セルフサービスリクエストポータル？CMDBにリンクされた変更管理？これらのそれぞれが、構成を特定の方向に引き寄せます。データのマッピングを開始する前に、何を最適化しているかを決定します。
3. 古いモデルではなく、新しいモデルに基づいてデータマッピングを設計する。 ほとんどのチームが犯す間違いは、ソースデータ構造をターゲットに直接マッピングすることです。正しいアプローチは、ソース データをターゲットのオペレーティング モデルにマッピングすることです。どのフィールドがその場所を占めるか、どのフィールドがアーカイブされるか、どのフィールドが廃止されるか、どのフィールドが統合されるかを決定します。ここで、オペレーティング モデルの決定と技術的な移行が収束します。
4. ターゲットを絞ったトライアル移行を実行します。 本格的なリハーサルの前に、 小規模なターゲット移行 (単一チームのチケット、1 つのカスタム ワークフロー、または 1 つのユーザー グループ) を実行して、マッピング ロジックと API シーケンスが実際にエンド エンドで機能することを検証します。これらの短いトライアルにより、修正コ​​ストが低いうちに問題を検出できます。
5. 完全な UAT 移行を実行します。 リハーサルです。完全なデータ、完全な構成、実際のユーザーが実際のシナリオをテストします。時間を予算化します。これは、実際の切り替えが穏やかか混乱するかを決定する段階です。
6. 希望ではなく計画を持って切り替えます。 コミュニケーション、ロールバック基準、サポート体制、期間中に誰が何を決定するか。UAT が徹底的であれば、切り替え自体は通常、盛り上がりに欠けます。
7. 適切なサポートの導入 完璧に機能する新しいツールでも、誰も使わなければ、それは失敗プロジェクトと言えるでしょう。導入には、社内の推進者、明確なドキュメント、実際の業務内容に合わせたトレーニング、そして目に見える形での経営陣の支援が必要です。純粋に技術的な移行プロジェクトでは、この点が常に軽視されがちです。

最近の例

移行では、3種類の異なるデータ形式に対応する必要がありました。

• ClickUpのドキュメント。構造はWikiのような形式で、プロジェクトと結び付けられていた。
• ClickUpのタスク。モデルはネストされており、依存関係を考慮している。
• Freshserviceのチケットは、コメント、添付ファイル、リクエスター関係を備えた古典的なチケットスキーマのモデルでした。

これらはそれぞれ、 元のシステムにおける状態をそのまま再現するのではなく、ターゲットシステム向けに設計した運用モデルにマッピングする必要がありました。ドキュメントは一方へ、タスクは別の方向へ、チケットはさらに別の方向へと処理され、場合によっては、同じ業務内容が複数のシステムで表現されているため、相互参照が必要でした。

この種の作業には、ソースAPIとターゲットAPIに対して直接移行スクリプトを作成するという、DIY的な代替手段もあります。これは過去のプロジェクトで実際に行ってきた方法で、AIツールによってさらに高速化されています。しかし、データ構造が多様で、移行先の構成が複雑で、納期が重要なプロジェクトでは、 Help Desk Migrationの専門ツールを使用することで、データ移行のリスクを大幅に軽減し、納期を短縮できます。これにより、お客様が実際に当社に依頼した内容、つまり構成、自動化設計、権限モデルに集中することが可能になりました。.

顧客が重視していた成果は、「データの移行に成功した」ことではありませんでした。顧客が求めていたのは、新しいプラットフォームによって、自社の顧客が頼りにしている過去の記録を失うことなく、ビジネスに必要な制御機能と自動化機能が実現できたことでした。これこそが、データ移行プロジェクトとデータ統合プロジェクトの違いです。.

移行先がPSAプラットフォームの場合も同様の傾向が見られます。運用業務に加えて、請求、請求書発行、プロジェクトの収益性、時間追跡機能も統合 Haloれます。Halo PSAへの統合の具体的な事例については、bdq.cloudに関する最近のケーススタディをご覧ください。.

Help Desk Migration が適合する場所

私たちはデータ移行ツールを提供する企業を自称するつもりはありません。複数のプラットフォームAPIに対して適切な順序で移行スクリプトを構築・実行し、添付ファイルやコメント、ユーザーマッピングといった特殊なケースを処理するという技術的な作業は、専門的なスキルを要するものであり、 Help Desk Migration まさにその分野で卓越した能力を発揮します。.

同様に重要なのは、専門ツールを使用することで、データ移行のコストと期間の両方を予測可能にできる点です。移行費用は、明確な予算項目であるべきであり、際限のないリスクであってはなりません。費用が明確であれば、より広範な統合のビジネスケースを承認しやすくなります。.

私たちが繰り返し立ち返るポイント

データ移行は、適切なツールでビジネスを運営する上での障壁となるべきではありません。コストがかかり、時間もかかり、リスクも伴いますが、適切なパートナーと適切なアプローチがあれば、もはや役に立たないプラットフォームに留まる理由にはなりません。
統合から最大限の恩恵を受ける組織は、単にデータを転送するだけでなく、運用モデルを改善する機会として捉えています。APIスクリプトやフィールドマッピングの技術的な側面にビジネス価値が宿るべきではありません。ビジネス価値は、より優れたレポート、より優れたプロセス、より優れた自動化、そして重要な業務を実際に把握し、実行できるチームにあります。
統合を検討している場合、まず最初に考えるべき質問は「どのようにデータを移動するか？」ではなく、「統合が完了したら、どのような状態になるべきか？」です。データの部分は後から考えれば良いのです。