多くのガイドでは、ヘルプデスクの移行には4週間から12週間かかるとされています。この期間は、手作業で計画・テストを行い、移行スクリプトをゼロから作成する場合を想定しています。しかし、実績のある移行ツールを使えば、これらの期間のほとんどは発生しません。ウィザードでマッピングを数分で完了し、テスト実行も数分で済み、移行はバックグラウンドで実行されるため、チームは作業を続けることができます。.
真の決定要因はプラットフォームです。Zendesk Zendesk チームプランで 1 分あたり 200 回の API リクエスト、エンタープライズ プラスでは 2,500 回の API リクエストが許可されています (Zendesk 開発者向けドキュメント)。Halo Halo 、API の使用が 5 分あたり 300 回の呼び出しに制限されています (HaloPSA 公正使用ポリシー)。2026 年 3 月 2 日以降、Atlassian は Jira Cloud アプリをポイントベースの時間単位のクォータで計測しています (Atlassian 開発者向けドキュメント)。以下に、プロジェクトの種類、データ量、プラットフォームごとの一般的な所要時間と、移行プロジェクトを構成する手順を示します。
ヘルプデスク移行プロジェクトの開始から完了までの所要時間
データ転送はあくまでも一つのステップに過ぎません。プロジェクトの大部分は準備と確認作業なので、実行段階だけでなく、全体のスケジュールを計画してください。.
Help Desk Migration 準備：本番稼働前の10ステップ
まずプロジェクトの目標を定義し、既存の記録を監査します。次に、データのクリーンアップ、対象プラットフォームの設定、フィールドマッピングのテストを行います。各ステップは、遅延やデータの問題を防ぐのに役立ちます。以下に、主要な移行段階とその一般的なタイムラインを示します。.
| 段階 | 何をするか | 標準時間 |
|---|---|---|
| 1. 範囲と目標を定義する | 移行の理由、移行先のプラットフォーム、および稼働開始日について合意する | 1～2日 |
| 2. チームの方向性を合わせる | プロジェクトオーナーを指名し、エージェントとマネージャーに説明を行い、切り替え期間について合意する。 | 1～3日 |
| 3. データの監査を行う | 所有しているものをリストアップしてください：チケット、連絡先、企業、添付ファイル、カスタムフィールド、マクロ | 2～5日 |
| 4. 移行するデータを決定する | データを移動必須、後で移動、またはアーカイブとしてマークします。古いクローズ済みチケットは、多くの場合そのままにしておいても問題ありません。 | 1～2日 |
| 5. データをクリーンアップする | 重複を統合し、古いチケットを閉じ、不要なものを削除します。 | 2～7日 |
| 6. ターゲットを準備する | インポートされたレコードが保存されるように、カスタムフィールド、エージェント、および自動化を設定します。 | 3～10日 |
| 7. デモ移行を実行する | サンプルでテストし、フィールドマッピングと添付ファイルを確認し、問題を修正します。 | 1～3日 |
| 8. 完全移行 | すべてのレコードを転送します（転送量とAPI制限に応じて、数時間から数日かかります）。 | 1～5日 |
| 9. 切り替え | フル実行以降に作成されたレコードを移動し、エージェントを切り替えます | 1日 |
| 10. 検証とサポート | 記録件数を比較し、データを抜き打ち検査し、エージェントを訓練する | 1～2週間 |
総括すると、 ほとんどの移行プロジェクト全体は 2～6週間、データ転送自体は通常そのうち1週間以内です。フェーズ3～6は重複する可能性があるため、プロジェクト期間を短縮するには、早めに準備を開始するのが最善策です。
移行プロセス：プロジェクトの規模と複雑さに基づく推定移行期間
以下の表は、3つの一般的なシナリオにおけるプロジェクトの各段階の合計時間を示しています。転送時間はログデータに基づいています。その他の段階は、この記事の後半で説明する各ステップの所要時間に基づいた計画範囲です。.
| シナリオ | セットアップとデモ | テストと修正のマッピング | 完全移行（データ転送） | デルタとカットオーバー | 標準的な合計 |
|---|---|---|---|---|---|
| 小規模で標準的な設定： レコード数が1万件未満、カスタムフィールドは少なめ | 15～30分 | 1～2時間 | 約35分（10回中9回、約4.5時間以内） | 1～2時間 | 約1日 |
| カスタムフィールドを備えた中規模： 1万～10万件のレコード、デモの再実行が複数回 | 1～2時間 | 1～3日 | 約4時間（10回中9回は1日以内に完了） | 2～4時間 | 2～5日 |
| エンタープライズまたは複数のヘルプデスクの統合： 100万件以上のレコード、カスタムオブジェクト、低上限ターゲット | 1～2日間の計画期間 | 3～7日 | 約2日（10回中9回は約8.5日以内） | 半日 | 2～6週間 |
大規模プロジェクトでは、ほとんどの時間がレビューと意思決定に費やされ、機械の処理時間はそれほど重要ではありません。そのため、早期にテストを実施し、スコープを厳密に管理することが最大のコスト削減につながります。以下のスピードアップのヒントは、その両方を網羅しています。.
データ量別の典型的なデータ移行時間
以下の表は、観測された Help Desk Migration 実行におけるデータ転送にかかった時間を、移動されたレコード数ごとにグループ分けして示しています。各列には、実行回数、実行の中央半分の範囲、中央値、および10回の実行のうち9回が完了した時間を示します。.
| データ量（レコード数） | 走る | 標準範囲（中央50％） | 中央値 | 10人中9人が |
|---|---|---|---|---|
| 小規模：1万ドル未満 | 496 | 15分～1.5時間 | 約35分 | 約5時間 |
| 中規模: 10,000～100,000 | 572 | 1.5時間～11時間 | 約4時間 | 約1日 |
| 大：10万～100万 | 457 | 5時間～1日 | 約12時間 | 約2日間 |
| 非常に大きい：1メートル以上 | 263 | 21時間～5日間 | 約46時間 | 約8.5日 |
これらは実際の移行から得られた観測所要時間であり、計算式に基づくものではありません。各顧客が利用したプランティアに関わらず、API間ルーティングを対象としています。CSV、 CSV、メールボックスソースは処理速度が異なるため、除外されています。同じ3万件のレコードで database、次のセクションで説明するプラットフォームによっては、1時間で移行できる場合もあれば、ほぼ1日かかる場合もあります。.
プラットフォーム別移行時間（API制限）
各プラットフォームのAPI制限は、レコードの読み出し（エクスポート）または書き込み（インポート）の速度を決定します。この表には、標準ティアと最上位ティアにおける13のプラットフォームの公式API制限、および約10万件のレコード移行における実際のエクスポートおよびインポート時間が示されています。.
| プラットフォーム | API制限（標準／最上位） | エクスポート、約10万件のレコード | インポート、約10万件のレコード | 注記 |
|---|---|---|---|---|
| Zendesk | 200 / 2,500 rpm | 7時間 | 24時間 | 最速の共通ターゲット |
| Freshdesk | 100 / 700 rpm | 6.5時間 | 23時間 | どちらの方向も高速 |
| Freshservice | 100 / 500 rpm | 17時 | 23時間 | ソースとしては遅い。エクスポート速度はボリュームが増えてもほとんど上がらない。 |
| Jira Service Management | ポイント制（時間当たりのノルマ） | 25時間 | 25時間 | 最も遅い一般的なターゲット: あらゆるサイズで約1,250レコード/時 |
| Intercom | アプリあたり10,000rpm。ご要望に応じてそれ以上の回転数も可能です。 | 5時間 | 5時間 | 往復とも高速。制限時間は10秒単位で計測。 |
| HubSpot Service Hub | 600 / 1,140 rpm | 1時間 | 6時間 | 非常に高速なエクスポート |
| Salesforce Service Cloud | 日次：約10万件のリクエスト/日 | 30時間 | 70時間 | 日次上限あり。100万件を超えると急激に減速する（下記参照）。 |
| Zoho Desk | デイリークレジット | 2.5時間 | 13時間 | 日々のクレジット; 広範囲 |
| ServiceNow | 管理者設定可能 | 2時間 | 19時 | インスタンス自体の制限によります |
| Halo | 60rpm（300回/5分） | 4.5時間 | 12時間 | 表に記載されている最低制限値 |
| Pylon | 文書化されていない | 該当なし（対象のみ） | 23時間 | Pylonで制限を確認してください |
| Front | 50 / 200 rpm | 32時間 | 20時間 | 低レートマッチはスロータイム |
| Gorgias | 120rpm（40回/20秒） | 該当なし | 19時 | 遅いターゲット |
API制限は、2026年11月に各ベンダーの開発者向けドキュメントに基づいて確認されました。ベンダーはこれらの制限を頻繁に変更し、ほとんどのベンダーは上位プランやアドオンを販売しているため、切り替えを計画する前にご自身のプランを確認してください。ご自身のデータに関する正確な数値を取得するには、
RelokiaによるHelp Desk Migration Vantaの Freshservice から Jira Service Management への移行をわずか21日間で完了させ、12万8千件以上のチケットを移行すると同時に、履歴コンテキスト、添付ファイル、監査証跡の整合性を維持しました。その実現方法をご紹介します。
Vanta：わずか21日間で12万8千件以上のチケットを移行
RelokiaによるHelp Desk Migration Vantaの Freshservice から Jira Service Management への移行をわずか21日間で完了させ、12万8千件以上のチケットを移行すると同時に、履歴コンテキスト、添付ファイル、監査証跡の整合性を維持しました。その実現方法をご紹介します。
プロジェクトの開始から完了までわずか21日間で、 Vantaは 12万8千件以上のチケット、51万2千件のコメント、8万6千件の添付ファイル、4,200人以上のリクエスターとエージェントを Freshservice に Jira Service Management、履歴コンテキストと完全な監査証跡の整合性を維持しました。
タイトなスケジュールは、自動移行オプション、カスタマイズされた構成、および反復的なアプローチによって実現されました。インライン画像はチケットの添付ファイルとして転送され、グループフィールドに基づいたカスタムタグによって、移行されたレコードが整理され、容易に識別できるようになりました。.
プレミアムサポートパッケージには再移行が含まれており、Vantaはカスタマイズの適用、結果の検証、最終転送の完了を行うための時間を確保でき、21日間のプロジェクト期間を延長することなく作業を進めることができました。.
データ移行にかかる時間に影響を与える要因は何ですか？
APIの制限が上限を設定する。移行がその上限にどれだけ近づくか、そしてプロジェクトにどれくらいの時間がかかるかは、他の4つの要因によって決まる。.
- レコード数。 すべてのチケットにはコメントが付随し、1つのチケットには数百、数千ものコメントが含まれる場合があり、すべてのコメントが転送の一部となります。ボリュームが基準値となります。
- 添付ファイル。 各ファイルは個別のアップロードとなるため、チケット数よりも添付ファイルの数が重要になる場合があります。添付ファイルが少ない大規模なアカウントは、スクリーンショットやPDFファイルが多い小規模なアカウントよりも早く完了する可能性があります。また、ファイルの数を事前に見積もることは難しいため、添付ファイルが多い移行は予測が最も困難です。
- 両側にプランの階層があります。 ほとんどのベンダーは、プランに応じてAPIの制限を調整します。プランが高いほど、使用できるAPI呼び出しの数が増えます。たとえば、 Freshservice Starterプランでは1分あたり100リクエストですが、Enterpriseプランでは500リクエストになり、アドオンパックでは最大2,000リクエストまで可能です（Freshservice APIドキュメント）。
- 複数のヘルプデスクを1つに統合します。 統合とは、1回の移行ではなく、同じターゲットへの複数回の移行です。各ソースはそれぞれ独立した移行として実行され、最初の実行以降は、既にデータが格納されているターゲットにデータが移行されます。当社の技術エンジニアがお客様の移行要件を評価し、並列（マルチスレッド）移行と逐次移行のどちらが最も効率的な結果をもたらすかを判断いたします。Mayvik は データを移行しました Freshdesk、 Zendesk、Desk.com、 Groove へ Help Scout 。
顧客サポートのデータ移行における課題に関するガイドでは、プロジェクトの遅延につながる可能性のあるすべての要因と、その解決策を一覧で紹介しています。
データ移行のタイムライン（ステップバイステップ）
移行作業において、データ転送時間はプロジェクト全体のほんの一部に過ぎません。以下のタイムラインは、移行プロセス全体と各ステップにかかる通常時間を示しています。.
ステップ1：データのマッピングを行い、デモ移行を実行します（15～30分）。
データ移行方法を選択する際に検討すべき主な選択肢は以下のとおりです。
無料デモは通常15～30分程度で完了します。移行ウィザードでは、ソースプラットフォームとターゲットプラットフォームを接続します（両方のプラットフォームへの管理者権限が必要です）。次に、転送するレコードを選択し、エージェントとグループを照合し、組織、顧客、チケット、記事の各フィールドをマッピングします。具体的なマッピング手順は、移行ペアによって異なります。また、インポートをカスタマイズするために、事前に構築された自動化オプションを選択することもできます。
移行前の設定が完了していない場合、デモの実行時間が長くなります。開始する前に、両方のプラットフォームのアクセス認証情報を収集し、ターゲット側で対応するエージェントプロファイルとグループを作成し、必要なチケットのカスタムフィールドを設定してください。カスタムフィールドが多い場合は、マッピングを1回ではなく複数回行うことを想定してください。.
ステップ2：デモ結果を確認する（数分～2時間）
デモの確認は数分で済みます。フルデータ移行の結果テストには少なくとも1～2時間かかります。デモはフル移行をそのまま反映しているため、デモで移行されないものはフル移行でも移行されません。マッピングを調整するために、デモを必要なだけ繰り返し実行してください。
以下の点を確認してください。
- コメントには正しい著者が記載されています
- チケットは適切なエージェントに割り当てられます
- カスタムフィールドには正しい値が格納されている
- 企業と顧客はつながっている
- 添付ファイルには名前が付けられています
- 記事は正しいセクションとカテゴリに分類されている。
- 移行へのアクセス権を共有することで、チームメンバーが検証を支援できるようになります。.
移行へのアクセス権を共有する ことで、チームメンバーが検証を支援できるようになります。
ステップ3：チームと対象となるヘルプデスクの準備（2時間以内）
エージェントのオンボーディングはできるだけ早く開始してください。所要時間はエージェントの数と対象プラットフォームによって異なります。切り替え自体は短時間で済みます。
- 対象の自動化機能をオフにするか、タグをリクエストしてください：5～30分
- サポートチームがソースでの作業を停止します：5分
- 送信元側の通信チャネルをオフにする：5～15分
- 対象物との通信チャネルを有効化する：15分～1時間
ステップ4：完全移行を実行する（数時間～数日）
これは、ボリュームテーブルとプラットフォームテーブルに表示される転送時間です。処理中も、チームはソースヘルプデスクで作業を続けることができます。取得済みレコードと転送済みレコードが表示されるレコードテーブルで進捗状況を追跡でき、移行が完了するとメールが届きます。処理を営業時間内に行う必要がある場合は、インターバル移行機能を使用すると、弊社チームと連携してフル移行を一時停止および再開できます。.
ステップ5：新規レコードのデルタ移行を実行する
フルマイグレーション中にソース側で作成または更新されたチケットは、 デルタマイグレーション、後続のマイグレーションで移行できます。エージェントをターゲット側に切り替える前に、結果を検証してください。
データ移行を高速化する8つの方法
ヘルプデスク、ITSM、またはRMMの移行を迅速化するには、データ転送時間の短縮、準備の簡素化、不要な遅延の回避など、いくつかの対策を講じることができます。API制限の最適化やソースデータのクリーンアップから、フィールドマッピングの効率化、並列移行の活用まで、適切なアプローチを採用することで、プロジェクト全体のスピードアップと予測可能性の向上を実現できます。データの正確性や事業継続性を損なうことなく移行を加速させるための以下の方法を検討してみてください。.
- ベンダーに一時的なAPI制限の引き上げを依頼してください。Intercom Intercom 制限引き上げのリクエストを受け付けており、 Freshdesk 追加のAPI呼び出しを販売しています。また Zendesk 、対象となるプランのAPI呼び出し数を1分あたり2,500件に引き上げる高負荷APIアドオンを提供しています。
- 添付ファイルをスキップします。 「添付ファイルをスキップ」オプションでは、
ファイルなしでレコードを移動します。すべてのチケット、または最終更新日が 6、12、24 か月以上前のチケットから添付ファイルを除外します。チームに必要なファイルのみを転送することで、移行時間とストレージコストを削減できます。大規模な移行、古いファイル、ストレージ容量超過の回避に最適です。 - 古いレコードや無関係なレコードは除外してください。 レコード数が少なければ、API呼び出しも少なくなります。すべてのデータを新しいプラットフォームに移行する必要はありません。移行ウィザードのフィルタリングオプションを使用して、転送するレコードを選択し、すべてのチケットや6か月以上前に最終更新されたチケットなど、無関係なデータを除外してください。標準のフィルタで要件を満たせない場合は、テクニカルチームに追加のフィルタリングオプションをリクエストできます。テクニカルチームは、移行範囲に基づいてカスタムフィルタを設定するお手伝いをしますので、必要なデータのみを転送し、API呼び出しを減らし、移行時間を節約できます。
- によるマルチスレッド移行 Help Desk Migration。 並列移行を実現します。非同期マルチスレッド転送は並列スレッドとして実行され、リクエストを1つずつ送信するのではなく、一度に多数送信するため、応答待ち時間を短縮できます。並列リクエストもAPI制限にカウントされるため、より高いAPI制限と組み合わせて使用することをお勧めします。この機能は、プレミアムプランとエンタープライズプランでご利用いただけます。
- 移行中はプランのティアをアップグレードしてください。 処理速度の遅いプラットフォームで上位ティアにアップグレードすると、通常、移行期間中はAPI制限が引き上げられます。
- 最新のレコードから優先的に移行します。 最新のチケットを最初に転送することで、古いレコードがバックグラウンドで移行される間、チームはアクティブな顧客の問題に優先的に対応できます。このオプションは、ダウンタイムが限られている場合、サポートが中断されない場合、予算が限られている場合、および切り替え前にアクティブなチケットをテストする場合に最適です。フル移行の場合のみ利用可能です。
- 切り替えにはデルタ移行を使用してください。 完全移行後にソースで作成または更新されたチケットを転送することで、稼働開始前に新しいプラットフォームに最新のデータが確実に反映されます。これにより、ダウンタイムを最小限に抑え、データの欠落を防ぐことができます。プレミアムプランでご利用いただけます。
- 業務時間に合わせて、インターバル移行をご利用ください。 ピーク時間帯にはフル移行を一時停止し、その後再開できます。弊社チームと連携の上、最大5回まで、1回につき最大5日間まで一時停止できます。
複雑な移行の場合、 当社のマネージド移行サービスは、 計画策定、カスタマイズ、データマッピング、API制限、検証などに関する専門的なサポートを提供し、最小限の混乱でスムーズな移行を実現します。
Pandora：全社規模の移行をわずか4週間で完了
Pandoraわずか4週間で、ダウンタイムゼロで、 全社規模の移行を完了し Zendesk への Salesforce Service Cloud、世界中の6,500以上の販売拠点と37,000人の従業員にわたる顧客サポートデータを統合しました。から
この移行では、チケットと顧客の履歴、通話録音、添付ファイル、内部メモ、付随的な会話、および業務ワークフローがすべて転送され、データ間の関連性も維持されました。.
プロジェクトを予定通りに進めるため、チームは反復的なアプローチを採用し、最終移行前に5回のデモ移行を実施してフィールドマッピングと設定を検証しました。システムのブロックを防ぎ、スムーズな移行を確実にするため、 Salesforce バックエンドトリガーは一時的に無効化されました。.
手動移行、自動移行、または管理された移行：それぞれの所要時間を比較してみましょう
チームで作成したスクリプト、セルフサービス型の移行ツール、そしてマネージド型の移行サービスとの主な違いは、移行中ではなく、移行前後に費やす時間にある。.
| 基準 | 手動（カスタムスクリプト） | 自動化された（セルフサービスツール） Help Desk Migration ツール | Help Desk Migration サポートおよび技術チームによるマネージド移行サービス |
|---|---|---|---|
| セットアップ時間 | 両方のAPIを数週間から数ヶ月かけて研究する | ウィザードで数分で接続とマッピングが完了 | 私たちのチームはプロジェクトの範囲を定め、お客様と共にデータをマッピングします。 |
| テスト | チームによって構築され、繰り返される | サンプルでデモ移行を実行し、必要に応じて再実行してください。 | プロジェクトのデモ実行と検証計画 |
| API制限の処理 | コードはスロットリングとリトライを行う必要があります | ツールに組み込まれています | 組み込み済み、さらにベンダー制限リクエストは事前に計画済み |
| カスタムフィールド、フィルター、マージ | あなたのチームが何を作るにせよ | 標準マッピングと自動オプション、フィルタリング機能をご利用いただけます。お客様のデータとプロジェクトのニーズに合わせてプロセスをカスタマイズするため、カスタムフィルタや追加の移行カスタマイズを弊社の技術チームにご依頼ください。. | カスタムフィルタリング、カスタムマッピング、複数ソースの統合 |
| 標準的なプロジェクト期間 | 数週間から数ヶ月 | 数時間から数日 | 範囲にもよるが、数日から数週間。 |
| 料金 | エンジニアリングの時間、しばしば隠されている | レコード枚数とオプション、サポートパッケージによって価格が異なります（価格設定） | 記録的な取引量、オプション、サポートパッケージ（移行サービス） |
マネージドサービスだからといって、プロジェクトごとにカスタムコードを作成する必要はありません。Help Help Desk Migrationのチームは、セルフサービスツールと同じ実績のあるエンジンを使用しているため、移行速度は変わりませんが、計画、マッピング、検証といった作業はお客様のチームから切り離されます。.
ご自身のレコードがルート上でどのように動作するかを確認するか、エンタープライズプロジェクトや複数ソースプロジェクトについて 専門家にご相談ください。
よくある質問
ログによると、100万件を超えるレコードの移行には、平均で約46時間かかりました。実行の中間半分は21時間から5日で完了し、10件中9件は約8.5日以内に完了しました。Jira Jira Service Management ような低制限ターゲットの場合、約1か月かかります。Salesforce Salesforce Service Cloudのような日単位の制限がある場合は、実行時間はこの範囲の長い方にずれ込みます。移行前後のマッピングとテストに数日から1週間かかることを考慮すると、100万件のチケットのプロジェクトは通常1週間から3週間で完了し、3か月もかかりません。.
これらの期間は通常、手動またはカスタム構築によるアプローチでプロジェクト全体にかかる時間を示しています。具体的には、数週間の計画、スクリプトによるテスト移行、データ転送、そして数週間の品質保証（QA）です。テスト済みの移行ツールを使用すれば、マッピングとテストは数分から数日で完了し、データ転送自体はほとんどの場合数時間で済みます。非常に大規模なプロジェクトや複数のソースを扱うプロジェクトでも、綿密な計画は必要ですが、数ヶ月単位の期間は通常、多くの手作業を伴うことを意味します。.
はい。添付ファイルはそれぞれ個別にアップロードされるため、ファイル数の多いアカウントは、ファイル数が少ないアカウントよりも時間がかかる場合があります。ナレッジベースの記事は通常、チケットに比べて数は少ないですが、インライン画像や記事の構造（セクションやカテゴリ）によって、マッピングや確認に時間がかかります。添付ファイルによって転送速度が低下している場合は、「添付ファイルをスキップ」オプションを使用すると、ファイルを含まないレコードを転送できます。.
のヘルプデスクデータ Salesforce Service Cloud (ケース、連絡先、ナレッジ記事) の場合、 ZendeskからSalesforce ログに記録された Salesforceの 1 日あたりの API リクエストの上限により処理速度が低下し始め、 ZendeskからSalesforce をご覧くださいへの移行には、10,000 ～ 100,000 レコードで平均約 6 時間、100,000 ～ 100 レコードで平均約 12 時間かかりました。100 万レコードを超えると、 この規模のへの移行には平均 3.4 日かかりました。これらの数値は、Sales Cloud CRM 全体の移行を網羅するものではありません。サポートされているレコードについては、 Salesforce Service Cloud 移行ページ。
並列移行は複数のスレッドで実行され、多数のリクエストを一度に送信することで、応答待ち時間を短縮します。レコードの種類が多い大規模アカウントで特に効果を発揮しますが、ベンダーのAPI制限に達している場合は効果が薄れるため、その場合はまず制限を引き上げてください。チケットとそのリクエスト元などの関連レコードは正しい順序で作成され、デモ移行を実行することで、本格的な実行前に結果を確認できます。.
はい。フルマイグレーションの実行中も、エージェントはソースヘルプデスクで作業を続けることができます。これは、転送処理がアカウントをロックすることなくAPI経由でデータを読み取るためです。インポートされたチケットによって顧客にメールが送信されないように、まずターゲット側で自動化機能を無効にしてください。 ダウンタイムゼロのマイグレーションガイドで 、切り替え手順について説明しています。
フルマイグレーション開始後にソースで作成または更新されたチケットは、フルマイグレーションの対象に含まれません。デルタマイグレーションでは、これらのチケットを後日、より短時間で移行するため、エージェントは完全な履歴を保持したままターゲットに切り替えることができます。デルタマイグレーションはプレミアムプランで利用可能です。 一般的なデータ移行チェックリスト 、デルタマイグレーションが切り替えプロセスの中でどの位置にあるかが示されています。
はい、インターバルマイグレーションなら可能です。フルマイグレーションは最大5回まで、1回につき最大5日間一時停止でき、 Help Desk Migration チームと連携して再開できます。例えば、サポートのピーク時間帯にAPIへの負荷を軽減できます。インターバルマイグレーションは、メイン実行後に作成されたレコードを移動するデルタマイグレーションとは異なります。一時停止と再開の手順については、「 はじめに」ヘルプセクション。
デモ移行中は、移行ウィザードにサンプルデータの転送率を示すプログレスバーが表示されます。フルデータ移行中は、レコードテーブルに取得および転送されたレコード数が表示されます。デモ移行またはフル移行が完了すると、メールが送信されます。.
ターゲットとソースを比較します。レコードの種類別件数、コメント作成者、チケット担当者、カスタムフィールド値、添付ファイル、記事カテゴリなどを確認します。古いチケット、最近のチケット、添付ファイルが多いチケットのサンプルをチェックし、ターゲットでトリガー、自動化、通知を有効にします。新しいヘルプデスクでの最初の数日間で、エージェントからフィードバックを収集します。 移行後のチェックリスト は、すべてのチェック項目が記載されています。
の低制限ターゲットへの処理が遅くなるのは、 Jira Service Management、 Halo、 Front 多くの場合正常です。進捗テーブルのレコード数が数時間変化していない場合は、1日のAPI上限またはトークンの期限切れにより処理が一時停止している可能性があります。その場合は、 サポートチームにご連絡ください 。ログを確認いたします。
