LiveAgentのクラウド版を利用することは、エンドカスタマーにとって非常に便利です。自動的に永続的なアップデートが提供されるため、自社サーバーのインフラを確保・維持する必要がありません。そのため、お客様からのマイグレーションリクエストは、双方にとってメリットのある状況として、私たちにとっても大変うれしいことです。では、具体的なプロセスはどのようなものでしょうか？何を準備すればよいのでしょうか？

事前要件：

マイグレーション自体を行う前に、マイグレーションはダウンタイムなしでは実施できないことをご理解ください。利用不可となる時間を考慮する必要があり、その時間はいくつかの要因（両側の回線速度、データベースのサイズ、マイグレーション時のインフラの状態）によって異なります。通常、これらのマイグレーションは平日（月曜〜金曜、GMT 8:00〜20:00）に無償で実施しています。

分析の一環として、利用可能なプラグインで十分かどうかを確認するためにテストトライアルを作成することをお勧めします。カスタムプラグインはクラウドインストールに移行できないためです。カスタムプラグインの機能は、チケットに外部情報を表示する を使用してアクセス・表示できるよう変更できる場合があります。また、カスタムの編集や変更はLiveAgentのクラウド版に100%移行できないことをご理解ください。独自のカスタムテーマは一切移行できません。Quality Unitの開発者は、これらのカスタマイズやカスタム変更の移行については責任を負いません。これらの移行は、既存のプラグイン、CSSの編集、その他のお客様側のツールを通じて実現可能です。

各お客様はそれぞれ固有の方法でLiveAgentを使用しているため、開発者がマイグレーションを成功させるためにはインストールの状態を分析する必要があります。そのため、既存のインストールに管理者権限を持つユーザーを作成してインストールへの管理者レベルのアクセスを提供すること、およびSQLの構造レベル（phpMyAdmin、adminer、緊急の場合はTeamViewer経由）でのデータベースへのアクセスを提供することが必要です。データベースダンプの転送にはSSH/SCPの方法を使用することが最適です。お客様から当社インフラへのダンプの転送方法は、安全かつ双方からアクセス可能でなければなりません（転送中の機密性と完全性を保証できないため、FTPは使用できません）。

また、サーバーにデータベースダンプファイルのための十分なディスクスペースがあることを確認し、ダンプを圧縮してください。

マイグレーションプロセスに同意いただける場合は、スタンドアローンインストールの移行先となるトライアルを作成してください（まだお持ちでない場合は https://www.liveagent.jp/trial/ から作成できます）。マイグレーション日が設定・合意されるまで、現在のスタンドアローンインストールのいかなる部分についても終了日を設定しないでください。

推奨事項：

  • まずこの記事をお読みいただき、不明な点があればサポートにご相談ください。
  • マイグレーション後も、メールの受信・送信にはIMAPおよびSMTPプロトコルの使用をお勧めします。より高速な転送ソリューションを使用する場合でも、LiveAgentからメールを送信するために独自のSMTPを接続することを強くお勧めします。

プロセス：

  • お客様がサポートチームに連絡し、マイグレーションについて話し合い・調整する
  • お客様が一時的なSSHアクセスとエージェントの地理的な場所の情報を提供する（地理的に近いデータセンターへのMTRを求める場合があります）
  • LA開発者がデータベースの状態とインストールを分析する
  • 現在の状態に応じて継続するか、既存のインストールに対して必要な調整を行う（例：LAのバージョンが古すぎる、不要なテーブル、不正なテーブル形式など）。これらの調整のほとんどについては記事を用意しており、お客様が最適なタイミングで実施できます。または当社がデータベース構造の必要な変更を行うことも可能です
  • 双方の都合に合わせてマイグレーション日を合意する
  • マイグレーション時、お客様はインストール内でエージェントが作業していないことを確認する
  • LiveAgentの管理パネルから外部ソースを無効にし、インストールを切り離す
    • Facebookページ
    • Twitterアカウント
    • POP3 / IMAPメールアカウント
    • メールパイプの一時停止
    • お問い合わせウィジェット、チャット、フォーム
    • など
  • お客様がIPホワイトリストを設定している場合、一時的に無効にし、マイグレーション後に再度有効にする必要があります。マイグレーション中、QualityUnitの担当者（通常は管理者と開発者）がプロセスに参加します（マイグレーション時にQualityUnitのオフィスにいない場合もあります）
  • お客様はWebサーバーサービスを停止する（Apacheを使用している場合は、コマンド：service apache stop）。それができない場合は、マイグレーション中にLAにアクセスできないようにすることが必須です（例：設定で無効なデータベースのユーザー名またはパスワードを設定するなど）
  • お客様はデータベースコンソールで以下のクエリを実行し、すべてのバックグラウンドタスクが完了していることを確認します：SELECT * FROM qu\_g\_queued\_jobs WHERE status != ‘F’; これは空の結果を返す必要があります（バックグラウンドジョブが完了している状態）。クエリが結果を返し、バックグラウンドがまだ実行中の場合は、数分待ってからクエリを繰り返し、空の結果が得られるまで繰り返してください
  • cronの実行を無効にする（crontab -e でスケジュールされたタスクのリストを開き、jobs.phpとqueue.phpの行の先頭に#を追加して実行を無効にします）
  • 以下のコマンドでデータベースダンプを作成する：
/usr/bin/mysqldump -v --single-transaction --no-create-db --skip-add-drop-table --hex-blob --max_allowed_packet=1G --net_buffer_length=16M \
--ignore-table={db_name}.qu_g_logs \
--ignore-table={db_name}.qu_g_mail_message_sources  \
--ignore_table={db_name}.qu_g_eventqueues \
--ignore_table={db_name}.qu_g_eventsubscriptions \
--ignore_table={db_name}.qu_g_news \
--ignore_table={db_name}.qu_g_usernews \
--ignore_table={db_name}.qu_g_passwd_requests \
--ignore_table={db_name}.qu_g_queued_jobs  \
--ignore_table={db_name}.qu_g_queued_plans  \
--ignore_table={db_name}.qu_g_queue_delayed_jobs  \
--ignore_table={db_name}.qu_g_queue_failures  \
--ignore_table={db_name}.qu_g_queue_jobs  \
--ignore_table={db_name}.qu_g_queue_planed_jobs  \
--ignore_table={db_name}.qu_g_sessions \
--ignore_table={db_name}.qu_g_session_values \
--ignore_table={db_name}.qu_g_token_buckets \
--ignore_table={db_name}.qu_la_browser_visits \
--ignore_table={db_name}.qu_la_conversations_search  \
--ignore_table={db_name}.qu_la_message_drafts \
--ignore_table={db_name}.qu_la_page_visits \
-u'{user}' -p -h localhost {db_name} > dump.sql

パラメータ

{db_name} = データベース名 {user} = データベースにアクセスするためのユーザー名

  • 次のコマンドを実行して、ダンプが正常に作成されたことを確認します：tail -n 100 dump.sql | grep “Dump completed” （ダンプファイルの末尾にある"Dump completed"というテキストを検索します）
  • 以下のコマンドでダンプファイルを圧縮します：pigz -9 dump.sql または pigz が利用できない場合は gzip -9 dump.sql（pigz は並列gzipユーティリティのコマンドです）
    • このコマンドは圧縮成功後に元のファイルを削除することに注意してください
  • 別の圧縮形式を使用することも可能ですが、双方でサポートされている必要があります（例：7z）
  • ダンプが成功したことを確認する前に、次のコマンドで結果ファイルを検証します：gzip -tv dump.sql.gz
  • ファイル転送は暗号化されますが、圧縮ファイルにパスワード保護を追加することも可能です
  • ダンプの準備ができたらQualityUnitに通知する
  • QualityUnitの管理者がインフラにダンプをダウンロードしてインポートする
  • 開発者がインポート後のデータベースの状態を確認し、クラウドインストールに必要なデータベースの値を調整する
  • お客様にアカウントの準備が整ったことを通知し、状態の確認を開始できる。QualityUnitの開発者は引き続き対応可能で、移行中の細かな不具合に対応する
  • お客様が外部リソースを有効にし、クラウドインストールを本格稼働させる

まとめ：

データマイグレーションと同様に、小さな問題が発生する可能性があります。もちろん、開発者はこのリスクを最小限に抑えるよう努めます。これらのエラーや問題が発生した場合は、お問い合わせフォームよりカスタマーサポートにお問い合わせください。データをクラウドに移行した後も、私たちのサポートは終わりません。お客様のサポートは24時間365日対応しています。