From MS SharePoint to Bitrix24: one-way ticket

Why Zetta Insurance decided to switch from MS SharePoint to Bitrix24 and how we managed to fulfill the migration

In 2017 Zetta Insurance decided to switch from Microsoft SharePoint to Bitrix24. The main reason was the fact that Bitrix24 turned out to be more budget-friendly and at the same time a more multifunctional product than MS Sharepoint.

The timing was really tight, and the main obstacle was that by that point SharePoint (SP) had been already highly customized. It had a lot of personalized features and contained gigabytes of data that the company couldn't afford to lose, such as:

  • news portal with likes and comments to the news;

  • stand-alone sites specially made for company departments (containing instructions, regulations, etc.);

  • dozens of file libraries;

  • training materials for the employees;

  • a few automated business processes (which we decided to exclude from the migration process as we would have to reconfigure everything from scratch anyway).

Our mutual goal was to make a branded and user-friendly Bitrix24 portal that would be integrated with AD with set up SSO. One of our main goals was to make the transition process as smooth and unnoticeable to users as possible.

So, we made a deal and then the hard work began. Here we would like to share some insights with you to show how we learned from the experience so that others can have a smoother migration. The thing is that MS Sharepoint and Bitrix24 are not only competing products but also they are antagonistic ecosystems hostile to each other.

Bitrix24 and SharePoint

First of all we needed to extract the data from SharePoint in a comprehensible format. We took some information like news, users data, files metadata from SP database in XML format. As for the files the process turned out to be a bit more difficult - they were extracted in a separate archive. Besides the metadata we wrote the path to the file from the archive root in XML, mentioned above. However we failed to get the pages content: not only was the information spread over dozens of sites, but also it was stored in the tables in an unusable form - with snippents in the SP format.

To transfer the pages content we dared to parse the active portal by collecting HTML - this way seemed to be optimal. We took a crawler and immediately ran into a problem: it did not accept the @ symbol in NTLM authorization (we had to ask the customer to change the account password). From that point there was little left to do: determine entry points, exceptions (in order to leave out all needless info, for example, users' profiles) and content area (there was no need to parse the whole page as Bitrix24 had its own template with header and footer). The content was stored in PHP file with the same name and address related to the site root, which facilitated the process of restoring the links between the pages and allowed us to use a regular visual editor in Bitrix24. In the content that we got there were some requests sent to the SP file manager (we replaced it with the request to the component for output of the corresponding Bitrix24 folder), requests to the Flash player (replaced with HTML5 instruments) and various links to other pages (which we brought into compliance with the site root by removing the domain name from the link).

AD: magic from the box or integrator Limbus?

The pullout was ready and submitted to the customer's approval while we turned our attention to the migration itself. We started with the users that had been initially created from the Active Directory and after that were completed with the data from SP through prepared XML.

Active directory and Bitrix24

Among the customers and some newcomers to the profession (who, at that time, had never experienced an integration of Bitrix24 and AD in the real world) it's commonly believed that it can be done correctly from the self-hosted version of Bitrix24, but there are several problems: it's a bindle of technologies running on different platforms - Linux and Windows; you should understand how samba works as a step away from it means a step into a marshy swamp (during the last integration our sysadmins had had quite a hard time with it); it takes more than two weeks to make the networks to cooperate.

We adjusted the fields correspondences and extracted all the users when the problem with company's structure revealed itself. The customer had several departments with identical names that were located in different branches of the company. Bitrix24 recognized that this was the same department and united them. From all the possible solutions (to modify the core of Bitrix24; to modify the data right in the process of transportation; to modify the structure in AD according to Bitrix24 requirements) we chose the best one and took the issue off the table.

The structure tree

The next step was to transfer the data from the departments pages and files. By using a parser we created a structure tree with all sections and pages that corresponded to the paths in SharePoint. Because of the conflicts with some integral Bitrix24 site sections we placed it in the /content/ section and set up a redirect for apache in order to enable all internal links:

RewriteRule ^(.*)\.aspx$ /content$1\.php [R=301,L]

We also placed the files in a tree-like structure and stored them in a multi-gigabyte archive which we unpacked into /upload/sp/. They would be revived by the script with the addition to the Disk (for necessary sections) and the nginx rule for existing links:

location ~* \.(doc|docx|jpeg|jpg|pdf|png|ppt|pptx|rar|txt|xls|xlsx|zip)$ {
try_files $uri /upload/files$uri = 404;
}

Bravado, branding and budget

We still had to work on the news and the layout - the branding itself. Usually it takes hundreds of hours and gives the integrator a big headache while the customer pays only slightly less than if he decided to launch a Falcon. As a result of all our titanic efforts, we usually see a revised Bitrix24 template which is as expensive to support as it is to create: any update in Bitrix24 requires instant template modification.

Bitrix24 modification

We were eager to leave this madness and save the customer some budget, so we decided to narrow it down to the revised color scheme and some new elements like a slider or a customized menu. Thus we got a reasonably priced product with room for updates. For news we created a separate template and adapted the original layout.

In lieu of epilogue

To accomplish the task in full we still had to add a few strokes: we set up the menu and settled some other cosmetical issues and configured the cluster architecture to ensure fault tolerance.

We hope that in this short article we managed to show you that the devil is not so black as it's usually painted.

So go ahead and have a nice integration!

Back