Moving cloud CRM to boxed version
When the capacity of the cloud service is already becoming scarce, and the transition to the boxed version is seen as the next logical step for the further development of the corporate portal and the CRM system, then the companies have a question: how to do it, what is waiting for them and will everything remain after transfer?
It would seem that everything is quite simple:
But practice shows that the transition from the cloud to the boxed version is far from trivial and requires a clear plan of action, analysis of possible risks and readiness for the fact that everything goes wrong.
We were approached by a major developer with a high-loaded CRM system on the cloudy Bitrix24. CRM actively worked with sales managers from several branches of the company, the portal was integrated with Asterisk IP telephony for automated lead creation, recording conversations with customers and recording the facts of a call on a client card in CRM. More than 100 leads were created per day in CRM through various channels.
')
It was clear that any idle time in the process of transferring to the boxed version threatens the Customer with huge losses. After talking with the customer about the seriousness of the transition and possible risks, we set to work.
First of all, we analyzed the existing cases and publications on the transfer of the cloud to the box, made a detailed check-list of errors that we may encounter:
Next, a rosary algorithm of actions was broken down by roles, which had to be performed both by the Contractor and by the Customer:
Phase 1 (Medium Urgency)
2 phase (high urgency)
3 phase (low urgency)
Having made this plan and having a checklist with possible errors, we realized that we have too great risks due to the large number of uncertainties:
We realized that we have an indefinite time lag, which, as it increases, would bring more and more losses for the client. To minimize the time lag, it was necessary to understand how much time we would spend on porting the portal and debugging it.
So we came to the conclusion that one backup from the cloud will not be enough, and in order to minimize losses, it is necessary to deploy one backup - to identify all possible risks and estimate the time lag, and then the second backup, which we could plan so as to minimize losses .
Bitrix provides only one backup and only once, since the process of transferring from cloud to box is technically complex. Contacting technical support and connecting the Customer to this issue, we still got the go-ahead to provide two backups from the cloud at different times. The time of the first backup was agreed upon and the transfer work began.
In order to understand how much and what time it will take for us, we began to keep a journal in which we recorded every step.
So, the portal started backing up the service on Thursday night, that is, CRM had the latest data at the end of Thursday, and provided us with a link to the backup on Friday lunch. Here we faced the first difficulty - the backup weighed about 30 GB, and the download speed from Amazon.com servers that hosted the cloud was far from ideal (800 Kb / s on average). Having calculated approximately the time for which several parts of the backup were loaded, we realized that in total, it would take about 10 hours to download the backup.
The next problem was the appearance of errors during the pumping of various parts of the backup, which was detected only during deployment. These parts, as a rule, also caused a hash sum mismatch error, because of this, it was necessary to detect the broken part of the archive in the error text and manually transfer it over SSH, after which the unpacking was restarted from scratch of the entire backup.
Successfully downloading and deploying a backup on our hosts, we received a working copy of the cloud in the box and proceeded to the next stage - testing and debugging the portal.
To our surprise, the testing of the box went relatively smoothly. We tested the CRM, went through all the service tools, checked the performance of the messenger, drove the internal tests and revealed only 3 errors:
We knew about the impossibility of logging in after the transfer in advance, the service immediately warns about this when providing a backup. Unfortunately, this problem is solved only by recovering the password by users or manually changing the password for each user by the administrator, since the passwords from Bitrix24.Network are not stored on the portal.
The error with the links in the notifications was resolved quite quickly - by prescribing the portal domain in the site settings and the settings of the main module.
But the missing file attachment icon in the messenger delivered quite a few worries. The task took another couple of hours of unsuccessful attempts to understand the cause of the missing icon. As a result, we found that the reason was far from being in the disk module, as was originally supposed. The reason was in the disconnected push server in the settings of the push & pull module, which automatically disconnected the file transfer in the messenger.
After successful testing and debugging of the portal, a detailed report was made to the Customer and the next step was in-depth testing by the Customer’s CRM sales department, as well as setting up the telephony server to work with the box and testing calls.
During testing, significant problems have been identified. We deployed the test host and rolled a full copy of the combat portal onto it, in case we had a 100% working version of the portal and we could make a comparison in the settings if non-standard errors occurred that were not detected during testing of the first backup.
After deploying a copy of the portal, we went over to an analysis of the journal, in which we fixed errors and the time they were resolved. After analyzing the magazine in detail, we updated the second backup transfer plan, realized how much we can lose leads during the final transfer and put additional time on manual import of lost leads from the cloud version. All the details and risks were also spoken to the Customer and made up a letter to the technical support of the service with a request to prepare a second backup.
Having coordinated the time for creating a backup also on Thursday, we prepared the team for operational actions by 12 noon on Friday. In the area of ​​12-13 hours we received a long-awaited link and launched the download. A few hours later it was clear that the archive would be pumped out no longer than 10 hours, but about 14! The bandwidth of our provider's channel and Amazon.com servers on this day left much to be desired. We were preparing for night work, as the leads continued to fall, and the Customer was waiting for a report to begin setting up the telephony server.
As it often happens - not everything went according to plan. The next step was to transfer the accumulated leads from the cloud version to the box - the process is simple and straightforward, but has its own nuances. If in the list of leads you select those leads that need to be exported and click “Export to CSV”, then all existing leads in CRM will be unloaded, not just the selected ones. Logically, with a large lead database, the cloud fell into error. The solution was to use a filter, only in this case the leads were unloaded correctly.
Further testing has passed without surprises, since we already knew: what will not work, how to edit it and where. Having successfully connected and tested the telephony, on Monday, sales managers have already fully worked with CRM in the boxed version. And already in working order, during the week, we tweaked the portal, backing up, made the final copy of the portal to the test host.
The entire transfer process took about a week of work from the moment of planning to the final settings.
As a result, I would like to note the importance of planning such complex and risky projects, the mandatory involvement of the customer in the process and the disclosure of possible risks, although, as practice shows, deviations from the plan are no exception.
It would seem that everything is quite simple:
- Expand the host with the box;
- We write in technical support;
- We order backup;
- Looking forward to receive it;
- We expand the backup and enjoy the wide possibilities of the boxed version.
But practice shows that the transition from the cloud to the boxed version is far from trivial and requires a clear plan of action, analysis of possible risks and readiness for the fact that everything goes wrong.
We were approached by a major developer with a high-loaded CRM system on the cloudy Bitrix24. CRM actively worked with sales managers from several branches of the company, the portal was integrated with Asterisk IP telephony for automated lead creation, recording conversations with customers and recording the facts of a call on a client card in CRM. More than 100 leads were created per day in CRM through various channels.
')
It was clear that any idle time in the process of transferring to the boxed version threatens the Customer with huge losses. After talking with the customer about the seriousness of the transition and possible risks, we set to work.
First of all, we analyzed the existing cases and publications on the transfer of the cloud to the box, made a detailed check-list of errors that we may encounter:
- Applications running in the cloud are not on the box;
- The cost of licenses for applications for the cloud version and the box may vary;
- The risk of losing data due to temporary lag during the transfer;
- Some users from different branches will continue to work on the cloud service after the transfer, and it will be necessary to additionally search and transfer the entities they have created to CRM;
- The service’s mobile application will not work on the closed portal;
- After the transfer, some users will not be able to log in with their old password;
- There may be a malfunction in chat bots;
- Frequent dropping of authorization when working on the portal;
- Only a portion of task comments can be displayed;
- The database will be without a search index.
Next, a rosary algorithm of actions was broken down by roles, which had to be performed both by the Contractor and by the Customer:
Phase 1 (Medium Urgency)
- Deploying the Production Environment (Artist);
- Testing the deployed environment (Contractor);
- Deploying the boxed version on hosts (Contractor);
- Purchase and installation of SSL-certificate for telephony operation (Customer-purchase, Contractor-installation);
- Testing the boxed version - performance, parameters, internal tests (Contractor).
- Deploying the Pre-Production Environment - a full copy of Production (Artist).
2 phase (high urgency)
- Application for unloading backup. Coordination with the technical support of the service date of the backup (Customer);
- Informing users about the backup date and drawing up a plan for temporary storage of information from CRM (Customer);
- Deploying a backup to Production (Contractor);
- Portal configuration after backup (Contractor);
- Setting up a telephony server for working with the portal (Customer);
- Telephony module setup (Contractor);
- Primary telephony testing (Customer);
- In-depth testing of CRM, telephony, business processes CRM (Customer Sales Department);
- Health statement. Delete test data (Customer);
- Stopping the work of sales managers in the cloud service (Customer);
- Transfer of transactions, leads, contacts since the backup was created from the cloud version to the box (Contractor);
- Start of work of sales managers on the boxed version (Customer).
3 phase (low urgency)
- Testing the boxed version within 2-3 days (Customer);
- Approval of full working capacity (Customer);
- Pre-Production Update - Transfer a full copy of Production (Artist).
Having made this plan and having a checklist with possible errors, we realized that we have too great risks due to the large number of uncertainties:
- How fast will the service provide backup?
- How long will it take to deploy a backup, given that the CRM database is huge?
- How quickly can I reconfigure the module and telephony server to work correctly with CRM?
- What specific bugs can appear on the portal, how critical will they be for users, and how long will it take to fix them?
We realized that we have an indefinite time lag, which, as it increases, would bring more and more losses for the client. To minimize the time lag, it was necessary to understand how much time we would spend on porting the portal and debugging it.
So we came to the conclusion that one backup from the cloud will not be enough, and in order to minimize losses, it is necessary to deploy one backup - to identify all possible risks and estimate the time lag, and then the second backup, which we could plan so as to minimize losses .
Bitrix provides only one backup and only once, since the process of transferring from cloud to box is technically complex. Contacting technical support and connecting the Customer to this issue, we still got the go-ahead to provide two backups from the cloud at different times. The time of the first backup was agreed upon and the transfer work began.
Volume, speed and broken parts
In order to understand how much and what time it will take for us, we began to keep a journal in which we recorded every step.
So, the portal started backing up the service on Thursday night, that is, CRM had the latest data at the end of Thursday, and provided us with a link to the backup on Friday lunch. Here we faced the first difficulty - the backup weighed about 30 GB, and the download speed from Amazon.com servers that hosted the cloud was far from ideal (800 Kb / s on average). Having calculated approximately the time for which several parts of the backup were loaded, we realized that in total, it would take about 10 hours to download the backup.
The next problem was the appearance of errors during the pumping of various parts of the backup, which was detected only during deployment. These parts, as a rule, also caused a hash sum mismatch error, because of this, it was necessary to detect the broken part of the archive in the error text and manually transfer it over SSH, after which the unpacking was restarted from scratch of the entire backup.
Successfully downloading and deploying a backup on our hosts, we received a working copy of the cloud in the box and proceeded to the next stage - testing and debugging the portal.
Small bugs and insidious push & pull
To our surprise, the testing of the box went relatively smoothly. We tested the CRM, went through all the service tools, checked the performance of the messenger, drove the internal tests and revealed only 3 errors:
- The file attachment icon disappeared in the messenger and the sending of files in the messenger as a whole did not work;
- The links in the notifications had an address without a domain, for example: company / personal / user / 1250 / tasks / task / view , respectively, were not working;
- Some users could not log in to the portal with an incorrect login / password error.
We knew about the impossibility of logging in after the transfer in advance, the service immediately warns about this when providing a backup. Unfortunately, this problem is solved only by recovering the password by users or manually changing the password for each user by the administrator, since the passwords from Bitrix24.Network are not stored on the portal.
The error with the links in the notifications was resolved quite quickly - by prescribing the portal domain in the site settings and the settings of the main module.
But the missing file attachment icon in the messenger delivered quite a few worries. The task took another couple of hours of unsuccessful attempts to understand the cause of the missing icon. As a result, we found that the reason was far from being in the disk module, as was originally supposed. The reason was in the disconnected push server in the settings of the push & pull module, which automatically disconnected the file transfer in the messenger.
Final Testing
After successful testing and debugging of the portal, a detailed report was made to the Customer and the next step was in-depth testing by the Customer’s CRM sales department, as well as setting up the telephony server to work with the box and testing calls.
During testing, significant problems have been identified. We deployed the test host and rolled a full copy of the combat portal onto it, in case we had a 100% working version of the portal and we could make a comparison in the settings if non-standard errors occurred that were not detected during testing of the first backup.
After deploying a copy of the portal, we went over to an analysis of the journal, in which we fixed errors and the time they were resolved. After analyzing the magazine in detail, we updated the second backup transfer plan, realized how much we can lose leads during the final transfer and put additional time on manual import of lost leads from the cloud version. All the details and risks were also spoken to the Customer and made up a letter to the technical support of the service with a request to prepare a second backup.
The second backup and why can things go wrong?
Having coordinated the time for creating a backup also on Thursday, we prepared the team for operational actions by 12 noon on Friday. In the area of ​​12-13 hours we received a long-awaited link and launched the download. A few hours later it was clear that the archive would be pumped out no longer than 10 hours, but about 14! The bandwidth of our provider's channel and Amazon.com servers on this day left much to be desired. We were preparing for night work, as the leads continued to fall, and the Customer was waiting for a report to begin setting up the telephony server.
As it often happens - not everything went according to plan. The next step was to transfer the accumulated leads from the cloud version to the box - the process is simple and straightforward, but has its own nuances. If in the list of leads you select those leads that need to be exported and click “Export to CSV”, then all existing leads in CRM will be unloaded, not just the selected ones. Logically, with a large lead database, the cloud fell into error. The solution was to use a filter, only in this case the leads were unloaded correctly.
Further testing has passed without surprises, since we already knew: what will not work, how to edit it and where. Having successfully connected and tested the telephony, on Monday, sales managers have already fully worked with CRM in the boxed version. And already in working order, during the week, we tweaked the portal, backing up, made the final copy of the portal to the test host.
The entire transfer process took about a week of work from the moment of planning to the final settings.
As a result, I would like to note the importance of planning such complex and risky projects, the mandatory involvement of the customer in the process and the disclosure of possible risks, although, as practice shows, deviations from the plan are no exception.
Source: https://habr.com/ru/post/425911/
All Articles