1C flies south — our experience of migration to K2 Cloud

In this article, I will tell you how to solve this problem by transferring five 1C configurations and launching them in the cloud in 4 hours. You will learn about the pitfalls of migration, unexpected difficulties, and how we managed to fit into such a short time. And you may realize that it's time for you to move to the cloud as well.

But first, let's get acquainted. My name is Anzhelika Zakharova, I am a cloud project manager at K2 Cloud, and also a product owner for 1C system migration projects in K2 Cloud.

Reasons for Migration

This time, our client was a large company with offices in Moscow and the Far East. It maintains production assets and shift camps, organizes the maintenance of buildings on production sites. The company's area of responsibility includes hundreds of facilities and about five thousand shift workers.

The client's main business system, 1C, was deployed on an old server in the Moscow office. This large-scale installation of five configurations automated accounting, document management, vehicle management, and many other processes. Due to the location of the offices, the client's employees worked with it almost around the clock.

The local infrastructure no longer met the company's needs for three reasons:

• Firstly, 1C applications were extremely slow. Users constantly complained about the low performance of the system.

• Secondly, there were scalability issues. Upgrading or purchasing new equipment required significant time and money. This issue became especially relevant due to plans to increase the number of 1C users from 160 to 300 people.

• Thirdly, the company lacked qualified specialists to maintain the infrastructure. The team of three IT specialists could not promptly restore the server's operation in case of failures.

The customer conducted a financial assessment and concluded that moving 1C to the cloud was more cost-effective than replacing the server and expanding the staff to maintain it. In us, the company found a provider that offered a strict SLA and was ready to do everything "turnkey" — fully take responsibility for the migration and setup of 1C.

Obvious difficulties with moving 1C

So, we were tasked with moving all five configurations to K2 Cloud. It would seem like a typical migration case: set up virtual machines, pull data onto them, and configure network connectivity — that's it. However, the 1C product was critically important for the business: the entire company's work depended on it, so we had to act quickly and without errors. Due to the location of the offices, it turned out that the 1C program was active almost 22 hours a day. This set the most stringent time frames for migration. The standard method of exporting-importing the database using 1C tools was immediately ruled out due to these limitations. Additional problems were created by the large volume of customer data, as well as the features of the configurations. Each of them has its own load specifics.

Our department, specializing in such projects, uses a 1C configuration ranking system and a special calculator to calculate the optimal sizing. The complexity lies in the variety of client applications: some use thin clients, while others use thick ones based on old configurations. These differences significantly affect migration planning and cloud infrastructure setup.

Preparation for the start of the project

In general, it was impossible to rush headlong. While colleagues were analyzing the configurations, we decided to make sure that the infrastructure was ready for migration from an architectural point of view.

The first thing to do in such cases is to divide roles between different virtual machines: 1C server, web server, MSQL server, terminal server, and so on. This reduces the load on the 1C application server, which is often overloaded. Role separation reduces the number of common processes, which significantly increases the performance of each virtual machine. This approach is more effective than endlessly increasing power.

In addition, it is important to check the settings of the virtual machines: the number and frequency of processor cores, the amount of RAM, and the capacity of the disks. In an infrastructure with a large legacy, they are often configured suboptimally. At the same time, we advised the admins on how to organize a secure connection to 1C via the web, clients, and terminal server, considering that they will soon be in the cloud.

Finally, we set up a backup system taking into account the required RTO (recovery time) and RPO (recovery point) parameters. As you know, administrators are divided into two types: those who do not back up, and those who have already been burned and therefore back up. So we paid special attention to database backup. We used our own service, working at the platform and hypervisor level.

Test Migration

The migration process is always associated with serious risks. Among them are data loss, increased downtime beyond the calculated time, problems with starting the virtual machine in the cloud, and failures up to critical errors. We insured against data loss, but other risks can only be mitigated by testing the system in practice.

For prompt communication, we created a group in the messenger, where we gathered technical specialists from both sides and conducted a test migration. The process went even better than we expected. Everyone sighed with relief, as it turned out later, prematurely.

1C Transfer

To fit into the minimum time, we used an approach tested on other projects: gradually, without haste, we copied the main volume of historical data, and then, immediately after turning off the customer's servers, transferred the delta — changes from the moment of the first replication. For this, we used Heistex Acura. The server part of this solution is already installed in the K2 Cloud, so it was only necessary to deploy agents at the customer and start replication.

Then, on the agreed weekend, we launched the migration itself. If we had transferred all the data at once, due to the low speed of the channel between the office and the cloud, the move would have taken several days, but it took four hours to transfer the delta. The entire migration, from signing the contract to the full transfer of all 1C functions to the cloud, took 18 days. Thus, the move practically did not affect the work processes. With one "but". Here the real difficulties began, unfortunately, sometimes it is impossible to avoid them.

Unpredictable difficulties with 1C transfer

Despite the successful test migration, the customer's 1C system initially began to fail.

The first reason was the customer's network infrastructure. It is impossible to exactly replicate its topology within the test. The network engineers who originally created the network and set up the connections between the sites were no longer working at the company. Their successors did not know all the intricacies of the system.

We studied the network together, but still missed a few important details. These features "fired" after the transfer - there were problems with routing to several remote sites. Shift workers started calling, who suddenly lost access to 1C. We solved these problems by re-routing individually.

The second problem was that a 1-to-1 migration was impossible. The customer simply had too old equipment. And although in theory we selected the optimal sizings, in practice the configurations had to be additionally adjusted to increase disk performance. In addition, it turned out that the customer had an incorrect SQL server configuration. This also had to be quickly fixed.

As a result, it took another couple of days to complete the setup and optimization of 1C.

What is the profit for the customer?

Were the final 20 days of work and the funds invested worth the result? The answer to this question is always individual. In this case, the customer received four significant advantages from moving to K2 Cloud:

1. Significant acceleration of 1C performance. Thanks to modern hardware, the system has become faster and more responsive. Users have stopped complaining about lags, making work more pleasant.

2. Confidence in high availability of infrastructure and quick problem resolution from the provider. Here, our standard cloud SLA with 99.95% availability, which is one of the strictest on the market, is in effect. Transferring system responsibility to Cloud specialists significantly reduces the load on the customer's personnel.

3. Scalable cloud platform capable of supporting any planned expansion of the 1C infrastructure. The customer gained access to our cloud console and the entire platform. Now the company can easily increase virtual machine resources or deploy new virtual servers as needed. Bonuses include: database deployment, caching setup, message broker management, and much more. For example, if there is a need to quickly create a database cluster in a test environment, this can be done in just a few clicks.

4. Technical support. We trained the customer's admins to work with the cloud infrastructure, provided detailed technical documentation for each service in the Cloud console. Although the number of requests has decreased, the customer can still consult with us at any time. Three lines of specialists and a working group created during the migration phase continue to operate.

Final recommendations

If you plan to move 1C to the cloud, start with a test migration. Many providers, including us, offer free trial access. This will help dispel doubts and identify potential problems. However, remember: not all difficulties can be foreseen in advance.

A test migration will allow you to evaluate the performance of 1C in a cloud environment, assess the costs of system support, and understand whether the transition is justified. In some cases, for example, if the company has recently upgraded its servers or does not plan to expand its business, the move may be impractical.

Nevertheless, for many companies with a strong IT department, a cloud solution with round-the-clock support often proves beneficial. Among our clients are government organizations, large corporations, and systemically important banks.

Note: the approach "here are the resources, do what you want" is outdated. It forces the customer to allocate a large staff of IT specialists to work with cloud services, which is not always justified. Choose a provider you can trust with both the transfer and support of the system. Look for a partner who can ensure that you will receive competent assistance in case of any problems.