マネージドサービスプロバイダー向けデータ移行：PSAはクライアントのものではありません
「マネージドサービスプロバイダー向けデータ移行」で検索すると、クライアントのメールボックスをMicrosoft 365に移行する方法に関する記事が次々と見つかります。.
このページでは、PSA、チケット、サービスデスクなど、ビジネス運営に不可欠なシステムについて解説します。MSP（マネージドサービスプロバイダー）の場合、これらのデータは数十社、時には数百社ものクライアントに同時に紐づいているため、クライアントごとのデータ分離、請求の継続性、そしてスムーズな移行が何よりも重要になります。業界特有の移行計画の仕組みを理解した上で、リスクの高いMSPのPSA移行に適用してみましょう。.
クレジットカードは不要です 素早いセットアップ
6万社以上の企業から信頼されています
データ移行の種類：PSA移行で移動するもの
PSAの切り替えは、単なるチケット移行に手順を追加するものではありません。 内部的には、1つのチケットがボード、キュー、カスタムフィールド、SLAポリシー、構成などにリンクしており、これらすべてが移行後も維持される必要があります。以下に、ヘルプデスクデータから順に、ほとんどのMSPが行う手順で、より詳細な範囲を説明します。
| レコードセット | 内容物 | 映画で何を見るべきか | クライアントごとの隔離に関するメモ |
|---|---|---|---|
| ヘルプデスクとPSAチケット | ケース、チケット、チケットスレッド、ボード、キュー、ステータス、タグ、カスタムフィールド | プラットフォーム間でボードとキューの構造が1対1で一致することはほとんどない。 | チケットは、正しい企業または顧客との関係を維持する必要があります |
| タイムエントリーと契約 | タイムログ、契約記録、設定、請求参照 | 請求先の州は通常、記録と一緒に移動しません。以下を参照してください。 | 契約条件は特定の顧客ごとに限定され、複数の顧客間で統合されることはありません。 |
| ナレッジベース | 記事、カテゴリ、顧客ごとの表示設定と社内での表示設定、記事の添付ファイル | 可視性設定には、マッピングルールだけでなく、決定事項も必要です。 | 共有記事には、どのクライアントがアクセスできるかについて明確な決定が必要です。 |
| 顧客および連絡先データ | 企業、連絡先、サイト、組織階層、エージェントおよびグループ構造 | これは移行の残りの鍵となる基盤です | 隔離が最初に成功するか失敗するか |
| メディアと添付ファイル | インライン画像、ファイル添付、サイズおよび保持制限 | ターゲットのサイズ制限は、ソースのサイズ制限よりも厳しくなる可能性がある | 添付ファイルは、それが属するチケットまたはレコードから分離性を継承します。 |
| メール履歴 | チケットに関連付けられた受信および送信スレッド、ヘッダーの保持 | ヘッダーの保持方法はプラットフォームの組み合わせによって大きく異なります。 | スレッドは親チケットが分離されている限り分離されたままです |
| 通話記録と録音 | 電話記録およびチケットに添付された録音リンク | 録画リンクは、別々に動作するサードパーティシステムを指し示す場合がある。 | 添付ファイルと同じ依存関係 |
つまり、レコードセットは1つではなく7つです。 チケットはアンカーであり、最も大きなデータ群であるため、PSAの切り替えをチケットの移行と勘違いしやすいのです。しかし、他の6つのレコードセットはそれぞれ、移行中に保護するためにクライアントごとに独自の分離機能を備えています。タイムエントリや契約書は、チケットにはない金銭的な重みを持っています。クライアントデータは、他のすべての基盤となるものです。添付ファイルや通話ログといったごく一般的なものでさえ、関連付けられているチケットやレコードから分離機能を継承します。最初に言及されなかったからといって、どれもオプションではありません。
実際に何が転送されるかは、 ソースプラットフォームが何をリリースするか、そしてターゲットプラットフォームが何を捕捉できるかによって異なります。この表は、実際に移行する前に評価する範囲設定文書としてご利用ください。
MSP企業向けにサポートされている移行プラットフォーム
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
名前に誤字がないかご確認いただくか、 メッセージを残してください。
クライアントごとの隔離こそが真の要件であり、チケット数ではない理由
分離機能は、単にオンにするだけで済むものではありません。データの移行中に、データのマッピングと検証がどのように行われるかに依存します。これが、MSPヘルプデスクの移行がシングルテナントプロジェクトと異なる点です。データは複数のクライアントに属するため、マッピングと検証はデータセット全体に対して一度行うのではなく、クライアントごとに行う必要があります。.
その事実だけでも、レコード量以上にプロジェクトに時間を要する要因となります。中程度のデータ量を持つ40のクライアントが関わる移行は、レコード数がはるかに多い単一クライアントの移行よりも、範囲設定と検証に時間がかかる場合があります。切り替え前に、各クライアントごとにマッピングのレビューと検証が必要です。.
分離性はプラットフォームが無料で提供するものではありません。それはマッピング段階での決定に基づいており、切り替え前にクライアントごとの検証によって確認されるもので、両プラットフォームがマーケティングページに「マルチテナント」という言葉を掲げているからといって当然のこととして期待できるものではありません。.
Autotask PSAにおける意図的なマッピングとはどのようなものか
では、「意図的に構築された」とは具体的にどういうことでしょうか？ Autotask PSAでは、すべての連絡先は会社にリンクされている必要があります。回避策はありません。ソースシステムの独立した連絡先は、マッピング時に会社に割り当てられ、自動的に整理されることはありません。.
Autotask PSA では、連絡先の作成後に会社を変更することはできません。そのため、特にアカウントを統合する場合は、会社の割り当てを確認するためのデモ移行がより重要になります。.
レポート機能に関しては、移行ウィザードのライブダッシュボードで検証が実行され、転送中にチケット、エージェント、連絡先、会社を個別のエンティティとして追跡し、最後に何が移動され、何が移動されず、その理由をまとめたレポートが作成されます。これらはすべて自動で行われるわけではありません。マッピングルールと、実際に誰かが確認するダッシュボードが必要であり、「分離機能が組み込まれている」という主張よりも控えめな表現ですが、より真実味のある表現と言えるでしょう。.
クライアントごとのマッピングの例： ConnectWiseからの移行
考えてみましょう ConnectWise PSAを具体的な例として ConnectWise 移行 が企業に集約され、複数の拠点で事業を展開するクライアントの場合、企業は複数のサイトに分割されます。移行時には、これらの関係性をクライアントごとに正しくマッピングする必要があります。
ソースプラットフォームで複数のクライアントが1つの共有企業レコードにグループ化されている場合、この問題はさらに重要になります。これは移行開始前に解決すべき問題であり、移行中に解決すべき問題ではありません。混在したクライアントデータを自動的に分離できるツールは存在しません。そのためには、担当者による判断と綿密なマッピングが必要です。この原則は、 ITサービス企業のデータ移行 。データの分離はMSPに限ったことではありませんが、MSPの場合はよりリスクが高いと言えます。
もう一つ、払拭すべき誤解があります。 マルチテナントは製品の機能であって、移行の結果ではありません。 プラットフォームがマルチテナントであるということは、実行中にクライアント同士が互いに干渉することなく、複数のクライアントを保持できることを意味します。これは、2つのマルチテナントプラットフォーム間で移行する際に、レコードが適切な場所に格納されるかどうかについては何も言及していません。ベンダーの主張が曖昧になるのは、まさにこの部分です。移行サービスを売り込んでいる業者には、この曖昧さのどちら側を指しているのかを理解させるべきです。
切り替え前に各クライアントを検証する
実際には、切り替え前のクライアントごとの検証とは、集計データをサンプリングするのではなく、各クライアントのマッピングされたレコードを個別にチェックすることを意味します。
顧客数が数社程度のMSPであれば、その処理は迅速に進む。しかし、数十社、数百社もの顧客を抱えるMSPにとっては、データ転送そのものよりも、その処理に多くの時間を費やすことになる。.
良いアドバイスとしては、切り替え前に各クライアントを個別に検証することです。何らかの問題が発生した場合でも、検証に合格したクライアントに影響を与えることなく、問題のあるクライアントの移行をロールバックできます。これにより、問題が切り離され、移行全体の管理が容易になります。.
セキュリティとコンプライアンスに関する疑問は、移行パートナーを評価するMSPにとって早い段階で浮上するものであり、当然のことです。Help Help Desk Migrationのセキュリティポリシー と、ベンダーが提案する特定の移行のための隔離方法の両方を必ず確認してください。
価格タグ付きのPSAレコード
MSPのヘルプデスク移行は、チケットだけにとどまりません。PSAは、チケットと並んで時間入力や契約記録も保持しており、これら2つのカテゴリはチケットにはない財務的な重みを持っています。チケットの履歴を見失うと、サービス上の大きな問題になります。時間入力の請求状況を見失うと、切り替えから3週間後に、先月の請求対象時間の一部が請求対象として処理されずに残っているという事態に直面することになります。どのMSPオーナーも、これらが全く異なる事態であることは言うでしょう。.
| レコードタイプ | 直接移動します | マッピングが必要 | 請求に影響がある |
|---|---|---|---|
| チケット | はい | 現場レベルで、通常は単純明快 | いいえ |
| タイムエントリー | 記録として | はい、構造はペアごとに異なります | はい |
| 契約 | 部分的に | 下記のプレースホルダーをご覧ください | はい |
| 設定 | 部分的に | 資産モデルによって異なります | 時々 |
| 企業 | はい | 隔離が重要、上記参照 | いいえ |
| 連絡先 | はい | 企業マッピングに紐づいています | いいえ |
| サイト | はい | 企業マッピングに紐づいています | いいえ |
| SLAポリシー | めったに1対1ではない | 通常は再建され、移設されることはない。 | いいえ |
| カスタムフィールド | いいえ | ターゲット上での手動設定 | 時々 |
| 添付ファイル | はい | サイズと保持制限は異なります | いいえ |
時間入力と請求州
タイムエントリは通常、レコードとして移行されますが、請求ステータスとしては移行されません。その理由は構造的なものです。 請求ステータスは通常、チケットやタイムエントリ自体ではなく、プラットフォームの財務レイヤーに存在するためです。Autotask Autotask PSA この点をうまく説明しています。チケットに記録されたタイムエントリは、請求可能な明細行になる前に承認と転記が必要です。何が行われ、どれくらいの時間がかかったかは、レコードとともに問題なく移行されます。誰かがすでに承認、転記、または請求したかどうかは、別の問題です。
これは通常、自動的に引き継がれるのではなく、対象プラットフォーム独自の請求ワークフロー内で調整されるものです。.
ウィザードのオプションとプラットフォームのニュアンス
Help Desk Migration 移行ウィザードに「時間エントリの移行」という名前付きの選択可能なオプションが表示され、エージェントがチケットに対して時間を記録するために使用するレコードを移行するものと説明されています。これは実際にサポートされているオプションであり、特別なカスタム作業依頼ではありません。ただし、公開されている説明には、特定のプラットフォーム間で承認済み、投稿済み、または請求済みのステータスが移行されるかどうかは明記されていません。.
これは公開情報における正直な欠落部分です。したがって、上記の一般的な請求状態の動作は確実なものとして扱い、ペア固有のフラグに関する質問は、移行スペシャリストに直接問い合わせるべき事項としてください。.
カスタムオブジェクトとしての契約
契約書 ConnectWise 同様の扱いを受けます。ConnectWise PSAと Autotask PSAの公開フィールドリストには ConnectWise 契約書は標準レコードタイプとして含まれていません。ConnectWise PSAのドキュメントに記載されているフィールドは、メンバー、連絡先、会社、チケットを対象としています。Autotask Autotask PSAのドキュメントに記載されているフィールドは、エージェント、会社、連絡先、チケットを対象としています。契約書は、資産や保証書と同じカテゴリであるカスタムオブジェクト移行の対象となり、標準のフィールドマッピングフローではなく、プロフェッショナルサービスを通じて処理されます。.
要するに、契約はチケット移行に自動的に付随するものではありません。契約は独立したプロジェクトとして予算に計上する必要があります。.
企業と連絡先の関係構造
Help Desk Migration は、PSAプラットフォーム間でチケットと連絡先レコードを移動しますが、各クライアントのレコードを分離する企業と連絡先の構造は維持され、請求状態の調整は基となるレコードの移動とは別の独立したステップとして扱われます。評価が特定のペアにおける正確な請求フラグの動作に依存する場合は、スコープを設定する前に直接確認することをお勧めします。.
プラットフォーム固有の詳細については、 Autotask PSA データインポートを参照してください。
DIY、マネージド、カスタム：マネージドサービスプロバイダー向け移行方法の選択方法
MSP業務におけるヘルプデスク移行を実現するには3つの方法があり、どの方法が最適かはレコード数よりもクライアント数によって決まります。
移行ウィザード（セルフサービス）
小規模なMSPで、顧客数が少数、サポート体制の整ったプラットフォームペアを1つだけ移行する場合、複雑な顧客ごとのマッピングは不要です。フィールドの範囲を指定し、テスト移行を実行して結果を確認した後、完全な移行を自分で実行できます。.
マネージドサービス
ほとんどのMSPプロジェクトでは、クライアントごとのマッピングは、一人で記入するチェックリストではなく、対話を通じて行う必要があるため、これがデフォルトの方法となります。Help Help Desk Migrationの マネージド移行サービス、お客様とプロジェクトの範囲を決定し、マッピングを作成し、レビュー用のテスト移行を実行してから、移行作業を処理するというものです。
コンサルティング
より複雑なケースとしては、特殊なソースデータ、カスタムオブジェクト、一度に統合する必要のある複数のソースプラットフォーム、または別のクライアント側プロジェクトと並行して発生するシーケンスの問題などが挙げられます。.
ネイティブPSAインポーターは、ここで真価を発揮するに値する。 ほとんどのPSAプラットフォームには CSV またはネイティブインポートツールが備わっており、単一ソースからのクリーンで範囲が明確なデータセットであれば、そのツールで十分対応できる。 では、マネージド移行サービスは一体どのような場面で真価を発揮するのだろうか？それ は、ネイティブインポーターでは対応できないエッジ部分、つまり、大規模なクライアントごとのマッピング、異なる財務モデルを持つプラットフォーム間での請求記録の照合、そして集計データをサンプリングして問題ないとするのではなく、各クライアントのデータを個別にチェックする検証といった場面である。
2つのMSPが並んでいると想像してみてください。1 つは、ドキュメントが充実し、ほぼ1対1のマッピングが可能なプラットフォーム上で、2つのクライアントと控えめなチケット量を運用しています。このような場合、セルフサービス方式は最適です。もう1つは50のクライアントを運用しており、レコード総数は2クライアントのMSPよりも少なく見えるかもしれません。しかし、それは問題ではありません。50のクライアントは50のマッピングと50の検証を意味します。なぜなら、この作業は行数ではなくクライアント数に応じて拡張されるため、シングルテナント移行のようにボリュームが減少しても作業量が減ることはないからです。
ソースコードにAPIが全くない？ それは、プロジェクトの範囲設定に関する議論を最初から変えてしまう。古い、あるいは高度にカスタマイズされたPSA設定の中には CSVできないものもある。これは機能的には問題ないが、プロジェクトのどの部分を自動化できるか、どの部分を手動でマッピングする必要があるかという点が変わってくる。
プラットフォーム固有の例としては、 Halo Service Solutions の移行 と ConnectWise への Freshdesk 移行 が挙げられます。これらは、MSPが最も頻繁に移行を行う2つのプラットフォームの組み合わせです。
目に見えるサービスギャップを残さずに切断する
切り替え作業は、MSP（マネージドサービスプロバイダー）の業務におけるヘルプデスク移行が真価を発揮する場面です。顧客が気づくようなメンテナンス期間を設けることはできません。.
その制約があるからこそ、切り替えは単一のスイッチ切り替えではなく、並行作業のように見えるのです。メインの移行が実行された後も両方のプラットフォームはしばらくの間稼働し続け、デルタ移行では、ソースを完全に廃止する前に、その期間中に作成または更新されたすべてのもの（新しいチケット、返信、タイムエントリなど）が移行されます。.
2つのプラットフォームを同時に稼働させる場合、事前に計画しておくべき重要な点があります。それは、運用期間中にエージェントが両方のシステムでチケットを処理すること、そして両方のシステムで整合性の取れた番号体系が必要となることです。これは、切り替え当日に詰めるべきことではなく、事前に決定しておくべき事項です。.
具体的には2つの決定事項があり、いずれも切り替え開始前に予定されている。
まず、チケット番号について： ターゲットプラットフォームはソースの番号付けを維持できるのか、それとも独自の番号付けを開始するのか？
これは移行先によって大きく異なります。Autotask Autotask PSAのドキュメントに記載されているチケットフィールドでは、ID とチケット番号が別々のフィールドとしてリストされているため、ソース番号が収まる場所があります。ConnectWise PSA の ConnectWise に記載されているフィールドには ID はありますが、チケット番号のフィールドは別ではありません。つまり、チケット番号は ConnectWise独自のシーケンスを必ずしも再現するのではなく、値として渡されることになります。クライアントがチケット番号に注目している場合は、プロジェクトの範囲を定める前に、移行先のプラットフォームについて具体的に確認してください。移行前のプラットフォームは、移行先のプラットフォームを確実に予測するものではありません。.
第二に、 顧客向けポータルの切り替えはいつ行うべきか？ これは一見些細な問題に思えるかもしれませんが、その影響は想像以上に大きいものです。顧客はそのURLをブックマークしており、数えきれないほど何度もそこからログインしています。データ移行が完了した後に、後付けで切り替えをスケジュールしてしまうと、技術的には問題のない移行が、顧客体験の悪化につながる原因となります。
PSAの移行でダウンタイムがゼロになるということはあり得ません。そうでないと言う人は、説明ではなく売り込みをしているだけです。Help Help Desk Migrationの経験から言えば、現実的なのはクライアントへの影響をほぼゼロに抑えることであり、その実現度はクライアント数、ポータル構成、移行先のプラットフォームでのチケット番号の扱い方によって異なります。クライアントがメールのみで問い合わせを行うMSPは、頻繁にクライアントポータルを使用しているMSPよりも移行が容易です。稼働中のシステムを切り替える必要が1つ減れば、問題が発生する可能性も1つ減ります。.
MSP移行の実際の費用と所要時間
MSPのデータ移行の価格設定は、シングルテナントプロジェクトとは異なるロジックに基づいており、最初に浮かぶ疑問は同じです。「 費用はいくらかかるのか、そして完了までどれくらい時間がかかるのか？」これは もっともな疑問です。実際に価格を左右する要因は以下のとおりです。
クライアント数は、MSPプロジェクトとシングルテナントプロジェクトを区別する変数であり、多くの場合、レコードの総量よりもコストと期間に大きな影響を与えます。40社のクライアントに分散した低ボリュームの移行は、1社の高ボリュームの移行よりもコストが高く、時間がかかる場合があります。これは、マッピングと検証がレコード数ではなくクライアント数に応じてスケーリングされるためです。時間入力と契約の深さもこの問題を悪化させます。複数の契約タイプとクライアントごとの詳細な請求ルールを持つPSAは、チケット量に関係なく、シンプルなフラット構造のPSAよりもマッピングに時間がかかります。.
ソースにAPIがあるかどうかは、コストと期間に直接影響します。APIアクセスがあれば、一般的に自動化されたプロセスが実現します。CSVのみの CSVや高度にカスタマイズされたソースの場合は、移行開始前に手動でのマッピング作業が多く必要になります。Help Help Desk Migrationの移行料金は、これらの変動要因を反映したものであり、レコードごとの固定料金ではありません。.
回りくどい言い方はやめて、具体的な数字で説明しましょう。Help Help Desk Migration 料金はレコード数に基づいており、単価は直線的ではありません。移行するレコード数が多いほど、1レコードあたりの料金は安くなります。カスタマイズなしのStandardプランでは、 1,000レコードの 移行で 100ドル、 10,000レコードの 移行で 514ドル。計算上はボリュームが有利なので、小規模なクライアントごとの移行を40件行う場合と、大規模な単一テナントの移行を1件行う場合では、経済的なメリットが異なります。
サービスパッケージは複雑さに応じて拡張されます。 スタンダードプランでは、一度限りのハードスイッチ移行に対応し、プレミアムプランでは、専用サポート付きで最大 5万件の レコードを処理できます。シグネチャープランとエンタープライズプランでは、デルタ移行、インターバル移行、マルチスレッド移行、および大規模な複数クライアントプロジェクト向けの専用アカウントチームが追加されます。
これらはいずれも正式な見積もりに代わるものではありません。 Help Desk Migration 無料のデモ移行で実際の作業内容を確認した後で初めて、正式な価格を提示いたします。.
移行コストの見積もりは、 まず自社の顧客数とプラットフォームに基づいて行うのが良いでしょう。特に、小規模なMSPであれば、セルフサービスが最適な選択肢となる可能性があります。顧客数が多く、複雑なケースでは、ボリュームベースの見積もりよりも、スコープ設定のための打ち合わせの方がはるかに有益な回答が得られるでしょう。
2つのMSP、2つの移行、2つの実話
2つの実際のMSP向けPSA移行事例は、どんな約束よりも雄弁にその有効性を示している。.
VestaTech社が ConnectWise PSAに進出
ベルギーのアルドゥーイに拠点を置く、Vestagroupグループ傘下のITおよびセキュリティサービス企業であるVestaTechは、約2,000件のチケット、顧客、および関連する活動記録を Freshservice に ConnectWise 。移行前、チームは自社開発のエクスポートスクリプトに頼っていましたが、この量では手作業によるインポートは労力に見合わないとして既に除外していました。最初のテスト実行でいくつかの軽微なエラーが発見されましたが、VestaTechとサポートチームは、本格的な移行の前にそれらを解決しました。テスト結果を確認した後、VestaTechは、他に匹敵する選択肢はなかったと述べています。VestaTech の ConnectWise 、サービス企業が本格的なPSAに移行する際の優れた事例となります。これは、統合ではなく直接的なプラットフォーム切り替えを示しており、この点は次のストーリーにとって重要です。
ROIcode、2つのサポートインスタンスを1つに統合
コロラド州デンバーに拠点を置く情報技術・サービス企業ROIcodeは、 Kayako Classicと Zendesk単一のクラウドベースの Kayako どちらか一方を完全に停止するのではなく、 でアカウントを統合し Kayako、両方のヘルプデスクソースを単一のインスタンスに集約すると同時に、初日からのサポート履歴をすべて保持しました。買収後にプラットフォームを完全に切り替えることなくアカウントを統合する必要がある場合、このケーススタディは、そのプロセスをスムーズに実行する方法を示しています。
文書化された移行パスと顧客の成果
では、顧客事例に加えて、 Help Desk Migration MSPが最もよく利用するPSAおよびRMMプラットフォーム SuperOps 、 Syncro 、 Ateraの移行パスを文書化し、マッピングしています。さらに、 ConnectWise 移行、 Autotask PSA 移行、 SuperOps データ移行チェックリスト、 Halo Service Solutions データ移行チェックリストのステップバイステップガイドも提供しています。
これら2種類の証拠が実際に何を意味するのかを正確に理解しておくことは重要です。なぜなら、MSP（マネージドサービスプロバイダー）は、ベンダーを評価する際に、この区別が曖昧になっていることに気づくからです。VestaTech やROIcodeといった顧客事例は、結果を示すものです。つまり、1つの企業、1つの移行、1つの結果が一度報告され、それ以上の展開は行われません。 文書化された移行パスは異なります。 これは、 Help Desk Migration そのプラットフォームペアをサポートしており、既にマッピングが存在することを示すものであり、特定の規模や複雑さのプロジェクトが実際に実行されたことを示すものではありません。どちらも重要です。どちらかが他方を補うことはできません。これらを互換性があるかのように扱っているページは、信頼度が低いと言えるでしょう。
信頼性に関するもう一方の重要な要素は、規模です。Help Help Desk Migration 6万件以上の移行実績を持ち、100種類以上のプラットフォームをサポートし、 SOC 2 Type IIおよび SOC 3 認証を取得しています。これらの実績は、VestaTechやROIcodeの成功事例に取って代わるものではありません。ただ、両社が培ってきた規律あるサービスが、単発的なものではなく、大規模に展開できることを証明しているだけです。.
調査を開始する前に、まずはここから始めてください。
MSPの場合、移行対象をクライアントごとに絞り込み、大きなデータセットとして扱うべきではありません。.
切り替え作業を開始する前に、すべてのクライアントに対して以下の5つのチェック項目を実行してください。
違いを確認せずに、すべてのクライアントで同じマッピングを再利用しないでください。取引量の少ないクライアントは、企業構造やカスタムフィールドが異なる場合があり、大規模なクライアントとは異なるマッピングが必要になる可能性があります。.
Help Desk Migrationの SuperOps データ移行チェックリスト と Halo Service Solutions チェックリストは 、接続、構成、選択、マッピング、テストという同じ構造に従っています。この形式を参考に、クライアントごとの移行チェックリストを作成してください。
ルールはシンプルだ。クライアント1社につき、マッピングレビュー1回、切り替え前の検証1回。.
よくある質問
MSPヘルプデスクは、PSA（パーソナルサービスオートメーション）内のチケット管理およびサービスデスクレイヤー、あるいは場合によってはスタンドアロンツールとして機能し、技術者が1つのインスタンスから多数の顧客組織からのリクエストを記録、ルーティング、解決するために使用します。通常、サポートツールとして単独で機能するのではなく、請求、契約、資産記録と連携して使用されます。MSP 向けITSMソフトウェアの 導入を検討または見直している場合は、比較検討することをお勧めします。
MSPとは、契約に基づいて他社のIT管理を行う企業のビジネスモデルです。PSAとは、そのビジネスを運営するプロフェッショナルサービスオートメーションプラットフォームであり、チケット、タイムエントリ、契約、請求などを一元管理します。ほとんどのMSPは、一般的なヘルプデスクではなくPSA上で運用しています。これは、PSAにはヘルプデスクにはない財務管理機能があるためです。 ConnectWise 移行事例 。
MSPにとって、PSAはクライアント業務のオペレーティングシステムとして機能します。チケット、時間入力、契約、請求はすべて、特定のクライアント、サイト、または担当者に関連付けられ、多くの場合RMMデータとも関連付けられます。ヘルプデスクは「チケット解決済み」で処理を終了しますが、PSAは「記録された時間」や「請求書生成済み」まで続きます。 Autotask PSA 。
情報源によって分類方法は異なりますが、ほとんどのフレームワークでは、データ移行をストレージ移行、 database 移行、アプリケーション移行、ビジネスプロセス移行に分けています。これはインフラストラクチャ向けに構築されたモデルであり、PSAやチケットレコードに特化したものではありません。もしあなたがまさにそれを探していたのであれ ば Help Desk Migrationのプロセスは、 サービスデスクデータに適用されるレコードレベルのバージョンを網羅しています。
最適なツールは一つではありません。使用するプラットフォーム、ソースにAPIがあるかどうか、移行作業のうちカスタムマッピングが必要な部分と単純なフィールドマッチングが必要な部分によって異なります。特にPSAやヘルプデスクのデータに関しては、 Help Desk Migrationの 移行サービス ソースプラットフォームのネイティブインポートツールを比較検討することをお勧めします。
「最適」なソリューションは、顧客数、ネイティブな課金機能や時間追跡機能が必要かどうか、そしてどの程度の高度な連携が必要かによって異なります。一部のMSPは、専用のPSA、 ConnectWise 比較検討することをお勧めします。 、またはAutotaskを使用しています。また、別の課金システムと並行して、よりシンプルなヘルプデスク機能のみを使用しているMSPもあります。本格的なPSA導入が唯一の選択肢だと決めつける前に、 MSP向けに構築されたヘルプデスクおよびITSMソリューションを
PSA本体以外にも、ツールスタックには通常、リモート監視および管理用のRMMソフトウェア、ドキュメントプラットフォーム、そして場合によってはその上に独立したチケット管理レイヤーが含まれます。MSP向けのPSAおよびRMMの例としては ConnectWise PSA、 Autotask PSA、 Halo Service Solutions、 SuperOps、 Syncro、 Atera、 NinjaOne、 SherpaDeskのように、MSP向けに特化して構築されたITSMツールもありますeDesk 。、 などが挙げられます。さらに、ManageEngine Plus MSPより新しいオールインワンオプションについては、 SuperOps 競合製品をご覧ください。
CRMは、営業パイプライン、連絡先、取引を追跡します。PSAは、サービス提供状況（チケット、時間、契約、既存顧客に対する請求など）を追跡します。見込み客は対象外です。プラットフォームによっては両方の機能を統合しているものもありますが、MSPの場合、通常はPSAがサービス業務の記録システムとなり、CRM（もし導入しているとしても）は新規ビジネスに特化しています。ConnectWise ConnectWise データを構造化しているかをご覧ください。
「クラウドにおけるMSP」とは、通常、顧客のクラウドインフラストラクチャを管理するマネージドサービスプロバイダー、または顧客のMicrosoft 365などのクラウドサービスへの移行を支援するプロバイダーを指します。これは、このページで取り上げているプロジェクト（顧客のクラウド環境ではなく、自社のPSAおよびサービスデスクデータの移行）とは異なります。プラットフォーム側の問題については、 MSPがプラットフォームを切り替える理由をご覧ください。
一般的なフレームワークでは、リホスティング、リプラットフォーム、再購入、リファクタリング、廃止、保持、移転といった項目が挙げられていますが、これはインフラストラクチャやアプリケーションの移行を目的としたモデルであり、PSAやチケットデータには適用されません。クラウド移行に関する検索でこのページにたどり着いた場合は、サービスデスクやPSAデータに適用されるレコードレベルの移行プロセスについてご確認ください。