移行する履歴の選び方
過去の問い合わせ履歴は、Zendeskの専用取り込み機能を使って移行できます。ただし、元の管理画面や集計結果まで、そのまま再現できるとは限りません。先に「移行後に何を確認したいか」を決めることが重要です。
Zendesk公式は、チケットの移行にTicket Import APIを案内しています。画面でCSVを読み込むユーザー登録とは別の仕組みです。自社での対応が難しい場合は、移行用アプリや支援サービスも選択肢になります。
対象は、未完了の問い合わせ、直近の対応履歴、長期保管が必要な記録などに分けましょう。すべてを新システムへ入れる方法だけでなく、古い記録を別途保管し、日々使う履歴を優先する方法もあります。保存期間や社内ルールに合わせて選びます。
日時・担当者・添付ファイルの引き継ぎ
専用の取り込みでは、チケットの作成・更新・解決日時や、コメントの作成日時を指定できます。添付ファイルも取り込めますが、本文に古いリンクを残すだけではなく、ファイル自体の移行が必要です。操作には管理者権限が必要です。
準備では「依頼者」「担当者」「所属先」「問い合わせ分類」を、移行先のどの項目に対応させるか整理します。Zendesk間の移行でもIDはそのまま流用できません。退職者の担当履歴や廃止された分類をどう残すかも、先に決めておくと確認が楽になります。
また、顧客への返信と社内だけのメモは分けて残します。件数だけ合っていても、発言者や公開範囲が変わっていれば、正しく使える履歴にはなりません。
添付一覧にファイル名やURLがあっても、ファイル本体を取得できるとは限りません。元の問い合わせID、返信、添付ファイルの対応表を作り、移行後も同じやり取りから開けるかを試します。管理者だけでなく、実際に対応する担当者や顧客の権限でも、必要な情報が見え、社内メモが外部へ出ないことを点検しましょう。Re:lationを使っている場合は、履歴と添付ファイルの出力範囲も判断材料になります。
通知・集計の制約とテスト移行
取り込み時と、その後の更新時では通知の扱いが異なります。公式仕様では、移行時にCC宛て通知は送られませんが、その後の更新では通知が発生します。クローズ以外で取り込んだチケットも、更新後はトリガーが再び動きます。また、移行チケットのZendesk指標とSLAは非対応のため、通常の実績集計とは分ける必要があります。
ユーザー登録も別途確認が必要です。ナレッジベースを有効にしている環境での一括追加では、設定によって歓迎メールが送られます。チケットの通知だけ確認して終わりにせず、顧客情報を取り込む段階も点検しましょう。
本番移行の前には、未完了・完了・添付あり・社内メモありの少数例で試します。件数、日時、発言者、公開範囲、添付の閲覧まで確認し、切り替え中に増えた問い合わせの追加方法も決めます。移行対象の整理から相談したい場合は、Zendeskデータ移行支援をご覧ください。
FAQ記事の移行を検討している場合は、既存FAQの移行で確認する項目もご覧ください。
情報確認日：2026年10月22日