当云服务的功能已经变得稀缺，并且过渡到盒装版本被视为进一步发展企业门户和CRM系统的下一个逻辑步骤时，企业会遇到问题，如何做，等待他们什么，转移后将保留所有内容？
似乎一切都很简单：
- 用方框展开主机；
- 我们正在编写技术支持；
- 我们订购备份；
- 我们期待收到它；
- 我们部署备份，享受盒装版本的广泛可能性。
但是实践表明，从云到盒装版本的过渡绝非易事，需要明确的行动计划，对可能的风险进行分析并为一切都会出错的事实做好准备。
一家大型开发人员向我们提供了基于Bitrix24云的高负载CRM系统。 该公司多个分支机构的销售经理积极参与CRM，该门户与Asterisk IP电话集成在一起，可以自动创建销售线索，记录与客户的对话并在CRM中的客户卡中记录通话事实。 每天通过各种渠道在CRM中创建100多个潜在客户。
显然，在转换为盒装版本期间，任何简单的时间都会给客户带来巨大损失。 与客户讨论了过渡的严重性和可能的风险之后，我们开始工作。
首先，我们分析了将云转移到盒子上的现有案例和出版物，并详细列出了我们可能遇到的错误：
- 云中运行的应用程序不是包装盒；
- 云版本和包装盒的应用程序许可费用可能有所不同；
- 传输过程中由于时间延迟而丢失某些数据的风险；
- 转移后，来自不同分支机构的一些用户将继续使用云服务，并且有必要额外搜索和转移他们在CRM中创建的实体；
- 在封闭的门户网站上，该服务的移动应用程序将无法运行；
- 转移后，某些用户将无法使用旧密码登录；
- 聊天机器人可能存在故障；
- 在门户网站上工作时，频繁的授权重置；
- 只能显示一部分任务注释。
- 该数据库将没有搜索索引。
接下来，编译了一个清晰的动作算法，并按角色细分，必须由承包商和客户共同执行：
1阶段（紧急媒介）- 部署生产环境（承包商）；
- 测试部署的环境（承包商）；
- 盒装版本在主机上的部署（承包商）；
- 购买和安装用于电话的SSL证书（客户购买，承包商安装）；
- 测试盒装版本-性能，参数，内部测试（承包商）。
- 部署生产前环境-生产（承包商）的完整副本。
2阶段（紧急程度高）- 卸载备份的应用程序。 与备份日期服务的技术支持（客户）协调；
- 通知用户备份日期，并制定计划以临时存储来自CRM（客户）的信息；
- 在生产（承包商）上部署备份；
- 备份后设置门户（承包商）；
- 设置电话服务器以与门户网站（客户）一起使用；
- 设置电话模块（承包商）；
- 初始电话测试（客户）；
- 深入测试CRM，电话，CRM业务流程（客户销售部门）；
- 健康声明。 删除测试数据（客户）；
- 在云服务中停止销售经理（客户）；
- 从创建备份到云版本到盒子（承包商）的那一刻起，交易，潜在客户，联系人的转移；
- 盒装版本（客户）上的销售经理工作开始。
三相（紧急度低）- 在2-3天内测试盒装版本（客户）；
- 批准全部绩效（客户）；
- 更新预生产-传输生产（承包商）的完整副本。
制定了该计划并准备了可能存在错误的清单之后，我们意识到由于存在大量不确定因素，我们承担了太多风险：
- 服务将以多快的速度提供备份？
- 鉴于CRM数据库庞大，部署备份需要多长时间？
- 如何快速重新配置模块和电话服务器以使其与CRM一起正常工作？
- 门户上会出现哪些特定的错误，这些错误对用户的工作有多重要，以及修复这些错误需要多长时间？
我们意识到我们存在不确定的时间滞后，随着时间的延长，将会给客户带来越来越多的损失。 为了最大程度地减少时间延迟，有必要了解我们在移植门户和调试门户上花费了多少时间。
因此，我们得出的结论是，从云中进行一次备份是不够的，并且为了最大程度地减少损失，有必要部署一个备份-确定所有可能的风险并估算时滞，然后再进行第二次备份，我们可以通过这种方式进行计划以最大程度地减少损失。
Bitrix仅提供一次备份，并且仅提供一次备份，因为从云到盒子的传输技术上很复杂。 转向技术支持并将客户与该问题联系起来，我们仍然可以在不同时间从云提供两个备份。 第一次备份的时间已经约定，传输工作开始了。
体积，速度和损坏的零件
为了了解需要多少时间以及需要什么时间，我们开始保留一份日记，记录每个步骤。
因此，门户网站在周四晚上开始备份服务，也就是说，CRM在周四结束时具有最新数据，并在星期五下午为我们提供了备份的链接。 在这里，我们面临的第一个困难是-备份重约30 GB，并且托管云的Amazon.com服务器的下载速度远非理想（平均800 Kb / s）。 计算了大约几部分备份的加载时间后，我们意识到总共只花10个小时就可以下载备份。
下一个问题是在备份的各个部分被抽出期间出现错误，这些错误只有在部署时才被发现。 通常，这些部分还导致哈希不匹配错误，因此，有必要在错误文本中标识归档的损坏部分，并通过SSH手动传输它，然后从整个备份的重新开始重新解压缩。
在主机上成功下载并部署了备份后，我们在框中收到了云的工作副本，然后继续下一步-测试和调试门户。
小错误和阴险推拉
令我们惊讶的是，盒子测试相对顺利。 我们测试了CRM，检查了服务的所有工具，检查了Messenger的功能，运行了内部测试并仅发现3个错误：
我们知道在提前传输后无法登录，该服务在提供备份时会立即发出警告。 不幸的是，此问题只能由用户恢复密码或由管理员手动更改每个用户的密码来解决，因为Bitrix24.Network的密码未存储在门户中。
通过在站点设置和主模块的设置中注册门户网站域，可以足够快地解决通知中的链接错误。
但是Messenger中丢失的文件附件图标引起了很多麻烦。 该任务又花了两个小时尝试失败，以了解丢失图标的原因。 结果，我们发现原因远非最初设想的那样在磁盘模块中。 原因在于push＆pull模块的设置中已断开的push服务器，该服务器会自动关闭Messenger中的文件传输。
最终测试
在成功测试和调试门户之后，已为客户准备了一份详细的报告，下一步是CRM客户销售部门进行的全面测试，以及设置电话服务器以处理电话箱和测试呼叫。
在测试过程中，未发现重大问题。 我们部署了一个测试主机，并在其上滚动了战斗门户的完整副本，以防万一我们拥有该门户的100％工作版本，并且根据该版本我们可以对设置进行比较，如果发生了在测试首次备份时未检测到的非标准错误，则可以对设置进行比较。
部署门户副本后，我们进行了日记分析，在其中修复了错误以及解决错误的时间。 在对杂志进行了详细分析之后，我们更新了第二份备份的转移计划，意识到在最终转移过程中可能损失多少线索，并预留了更多时间从云版本手动导入损失的线索。 还与客户讨论了所有详细信息和风险，并给服务的技术支持发送了一封信，要求准备第二份备份。
第二次备份，为什么一切都会出错？
在周四还约定了备份创建时间之后，我们为团队在周五中午12点之前准备好采取行动做好了准备。 在12-13个小时的时间内，我们收到了期待已久的链接，并开始下载。 几个小时后，很明显，存档不会在10个小时内被抽出，而是大约14个小时！ 今天，我们的提供商和Amazon.com服务器的通道带宽还有很多不足之处。 我们正在为夜间工作做准备，因为潜在客户继续下降，并且客户正在等待报告以开始设置电话服务器。
经常会发生，并非一切都按计划进行。 下一步是将累积的销售线索从云版本转移到包装盒中-过程简单明了，但有其细微差别。 如果在销售线索列表中选择需要导出的销售线索，然后单击“导出为CSV”，则CRM中所有现有的销售线索都将被卸载，而不仅仅是选定的销售线索。 在大型潜在客户数据库中，云陷入错误是合乎逻辑的。 解决的办法是使用过滤器，只有在这种情况下，才能正确卸载引线。
我们已经知道，进一步的测试毫无意外地通过了：什么是行不通的，如何修复它以及在哪里进行。 在成功连接和测试电话之后，星期一，销售经理已经完全使用盒装版本的CRM。 在已经工作了一周的时间内，我们已经调整了门户网站，进行了备份，将门户网站的最终副本复制到了测试主机。
从计划到最终设置，整个转移过程花费了大约一周的时间。
因此，尽管实践证明，偏离计划也不例外，但我想指出，规划此类复杂而有风险的项目，让客户强制参与流程并指出可能的风险的重要性。