Migrating standalone version of LiveAgent to cloud

Due to the growing challenges associated with migration from the Standalone version to our Cloud, we have decided that these migrations will no longer be possible after your Standalone installation has been updated past version 5.44.

Using the cloud version of LiveAgent is much more convenient for you, the end customer, as you get automatic lifetime updates, and there is also no need to secure and maintain your own server infrastructure. Therefore, every single request from the customer is very pleasing to us, as this situation is a win-win for both parties. So, how does the process look like? What you should prepare for?

 

Pre-requirements:

Before the migration itself, it is necessary to realize that migration cannot be carried out without downtime. It is necessary to take into account the unavailability time, which depends on several factors (link speed on both sides, database size, infrastructure status at the time of migration). Usually we perform these migrations free of charge on working days (monday - friday, 8:00-20:00 GMT).

As a part of our analysis, we recommend that you create a test trial to see if the available plugins are sufficient, since custom plugins cannot be migrated to a cloud installation. Custom plug-in functionality can sometimes be modified to be accessible / viewed using https://support.liveagent.com/993318-Display-external-info-in-ticket. We recommend our customers to realise the fact, that custom edits and modifications can not be 100% transferred to the cloud version of LiveAgent. Own custom themes can not be migrated at all. The developers of Quality Unit are not responsible for migrating these customizations and custom changes as their transfer can be achieved through existing plugins, CSS edits and others tools on the side of customer.

Because each customer is unique and uses LA according to their own needs, our developer needs to analyze the installation status for successful migration. For this purpose, it is necessary to provide access to the installation at the administrator level, thus creating users with administrative privileges in the existing installation, as well as to access the database at the SQL structure level (phpMyAdmin, adminer,… in emergency case via TeamViewer). It is best to use the SSH / SCP approach to transfer the database dump. Way of transferring the dump from the customer to our infrastructure must be secure & reachable from both sides (we can't use FTP as we can't guarantee in-transfer confidentiality and integrity).

Also don't forget to make sure there is enough disk space on your server for the database dump file, and to compress the dump.

If you agree to the migration process, please create a trial (if you do not already have it at: https://www.liveagent.com/trial/) to which the standalone installation will be migrated. Do not schedule a termination date for any parts of your current Standalone installation until the migration date is set & agreed upon.

 

Recommendations:

  • We recommend that you read this short article first and consult it with our support if anything is not 100% clear. 
  • We recommend the use of IMAP and SMTP protocols for receiving and sending emails also after migration. Even for using the faster Forwarding solution, we strongly recommend connecting your own SMTP to send out emails from LiveAgent.

Process:

  • Customer contacts support team to discuss & arrange the migration
  • Customer provides temporary SSH access and info about geographical location of their agents (we might ask for MTR to geographically close Data centers)
  • LA developer will analyze database status and installation
  • Depending on the current state it is possible to continue, or if necessary to make adjustments to an existing installation (eg too outdated version of LA, unnecessary tables, incorrect table format, ...). For most of these adjustments we have prepared articles and it can be made by customers at the time when it is the most appropriate for them, or we can perform the necessary modifications of the database structure
  • agree on the date of migration according to the possibilities of both parties
  • at the time of migration, the customer ensures that no agent is working in the installation
  • disable external sources via LiveAgent admin panel, isolating the installation
    • Facebook pages
    • Twitter accounts
    • POP3 / IMAP email accounts
    • pause mail pipe
    • contact widgets, chats, forms
    • ...
  • If a customer has a defined IP whitelist, it must be temporarily disabled and re-enabled after migration. During migration, QualityUnit (QU) employees will enter the process, typically an administrator and developer (who may not be available at QU Office at the time of migration)
  • The customer disables the web server service (if using Apache, with the command: servise apache stop), if possible. If not, it is essential to ensure that LA is not available at the time of migration (e.g. by setting invalid database username or password in settings)
  • The customer traces through the database console that all background tasks have been completed as a query: SELECT * FROM `qu_g_queued_jobs` WHERE` status`! = 'F', should return an empty result, i. Background jobs are completed. If the query returns any result and the background is still running, it is necessary to wait a few minutes and repeat the query, respectively. repeat until empty result.
  • Disable the cron run (use crontab -e to go to the list of scheduled tasks and add a # to the beginning of the line with jobs.php and queue.php to disable execution)
  • Create a database dump with the command:
/usr/bin/mysqldump -v --single-transaction --skip-add-drop-table --max_allowed_packet=1G --hex-blob --no-create-db --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'{password}' -h localhost {db_name} > dump.sql

Where

{db_name} = database name
{user} = user name to access this database
{password} = user password to access this database

  • Compress the dump file with the command: gzip -9 dump.sql
  • It is possible to use another compression format, but it must be supported on both sides (eg 7z)
  • The command deletes the original file after successful compression
  • Before confirming a successful dump, it is recommended to test the resulting file with the following command: gzip -tv dump.sql.gz
  • File transfer will be encrypted, but it is possible to add password protection for the compressed file
  • Inform QU that the dump is ready for pickup
  • The QU administrator downloads the dump to the infrastructure and imports it
  • Developer checks the database status after importing and adjusts the database values ​​needed for cloud installation
  • The customer is informed that their account is ready and can start checking their status as there is a chance that the developer may miss a change. He will still be available and address minor deficiencies during the transition
  • The customer activates external resources, making cloud installation full-fledged

Conclusion:

As with any data migration, some small problems might occure. Of course, our developers will try to minimize this risk as much as possible. Should any of these errors / problems appear, please contact our customer support at support@liveagent.com. By migrating your data to the cloud, our care for the process doesn't stop, our support is available for our customers 24/7.

×