Yuri Druchinin, NOTA (Holding T1): How to seamlessly transfer Jira and Confluence systems to Russian counterparts

Yuri Druchinin: In early August of this year, Atlassian announced that in September, 30 days after the announcement, it would disconnect Russian accounts from its services. Soon this happened: companies from various industries began to report a shutdown, while simultaneously selecting alternative options.

Despite the decision of the Australian developer to leave the Russian market, the complete closure of the business in the country was actually announced only after a year and a half. All this time, the import substitution process, according to our observations, was systematic, not counting a short surge in the spring and summer of 2022 - when there was ambiguity on the market.

Many large companies searched for contractors, made product shortlists, but after unsuccessful pilot projects, the cycle was repeated again. And it was the news about the imminent shutdown of Russian Atlassian accounts that became the main stimulating factor in the development of the market for analogues Jira and Confluence. First of all, this applies to medium and small companies, many of which used the developer's cloud products.

At the same time, customers cannot switch to domestic products overnight, data migration is a long and technically complex process. Someone uses free Open source systems, large businesses isolate solutions based on Atlassian products, denying themselves updates and vendor technical support. It must be understood that both options are only a "painkiller," the effect of which will soon cease.

Yuri Druchinin: Russian analogues Jira and Confluence are mainly represented in the segment of medium and small businesses, the corporate sector has less choice. This is understandable: it is easier to meet the needs of the SMB than to solve problems for enterprise. If the customer used Jira as part of ITSM - an approach to managing and organizing IT services - and is looking for an analogue exclusively for this task, the choice of domestic systems will be greater. If Jira served as an important tool for managing development processes, you will have to organize full-fledged import substitution.

Among Russian software there are many solutions with functionality comparable to that offered by Atlassian. However, they are not tailored for a wide range of customers and are suitable only for a narrow group of users. We see that most Russian developments do not have a multi-level matrix process control methodology - customers are faced with lightweight solutions in terms of process configuration and compliance with the modern technology stack.

For example, not all Russian products support cloud solutions, except for the SaaS environment. Those who support SaaS cannot always provide a high-quality on-premium solution. Also, they are not always able to provide the required level of security - some products contain vulnerabilities due to non-compliance with secure development standards.

Yuri Druchinin: Based on our own experience of successful migration, we advise you to take into account the following:

• Strengths of the solution. When choosing analogues, pay attention to products with specialized expertise in areas of priority for you.
• Adaptive to deployment. Choose a product that matches the technology stack and can be painlessly integrated into the infrastructure where Jira or another Atlassian-based system was located.
• Compliance with the landscape. Products should quickly implement the integration capabilities laid down in them and fit into the landscape of implemented information systems. If your code is stored in Open Source solutions that the developers have customized for themselves, you need to look for a contractor who can integrate with popular Git systems and, if necessary, orchestrators.

Yuri Druchinin: Audit. At the start, it is necessary to audit processes, draw up a map of their connections and understand what data and integrations are used at various stages. You can digitize them in special editors, adding individual plugins if necessary.

Migration depth. Before you begin migrating data, it is important to assess the depth of the data. The deeper the historical layer of data you want to transfer, the harder it will be to do because of its complex connectedness. Thus, data for a short period can be unloaded relatively easily, because it is not necessary to further synchronize the information transferred at various stages.

Reducing possible risks. If possible, it is better to leave Jira in the archive, transferring only the current backlogs. New tasks and sprints are already planned in the new tool - in this case, the risks will be minimal.

Select the transfer time. If the processes in the company go only from Monday to Friday, it is better to carry out migration work on weekends. So on Monday, some of the teams will be able to start working in the new system, having a set of fresh tickets and related data. At the same time, risks for production processes will be minimal.

Using migration tools. Additional difficulties may arise for companies that use Jira for ITSM or work that requires 24/7 information addition and regular ticketing. In addition to the migration itself, it will be necessary to ensure the complete synchronization of incoming data from related systems using crosslinkers - synchronization and data transfer services in running systems.

Yuri Druchinin: Having a number of pilot projects and commercial implementations, including projects for tens of thousands of users, we have fully worked out all the nuances of migration from Jira to the Russian system of the Sphere. Our specialists own various tools at the level of scripts and code.

If we talk about migration from Confluence to the Sphere solution. Knowledge, we have modern UI tools with which you can connect to existing systems and carry out migration in a convenient format. The Sphere platform team has experience in transferring information from the system with millions of tasks and applications, as well as with hundreds of thousands of articles from the knowledge base.

The main advantage of Sphere. Tasks and Sphere. Knowledge is that they were developed on a modern technology stack close to what Atlassian uses.

Yuri Druchinin: We noticed that many companies significantly refined the Jira and Confluence systems in order to actively use them within ITSM. Service processes typically have complex logic and involve many more systems than software development solutions. Accordingly, more integrations are required. As a result, the requirements for automation of ITSM products are much higher than in cases where the customer simply needs development management solutions. Our experience in conducting pilot projects confirms this.

Yuri Druchinin: The timing depends on the number of users and the amount of data that needs to be transferred.

For a company with tens of thousands of users, we managed to transfer tasks from Jira in two months, migrating data only on weekends. Knowledge base migration is always a more complex process, so under the same conditions it took about four months. In the process of such a migration, we increased the number of users by several thousand weekly for each of the systems.

You can find out more and familiarize yourself with the demo of the tool by clicking on the link.