1C Flies South – Our Experience of Migrating to K2 Cloud
Imagine: you have a large company with offices from Moscow to the Far East, hundreds of facilities, thousands of shift workers and an ancient 1C server that can barely handle the load. It sounds like a nightmare.
In this article, I will tell you how to solve this problem by migrating 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 do it in such a short time. And, perhaps, you will understand that it is high time for you to move to the cloud.
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 to K2 Cloud.
Reasons for migration
That time, our customer was a large company with offices in Moscow and the Far East. It services production assets and shift camps, and organizes household maintenance of buildings at production sites. The company's area of responsibility includes hundreds of facilities and about five thousand shift workers.
The customer'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 flow, vehicle management, and a ton of other processes. Due to the location of the offices, the customer'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 worked extremely slowly. Users constantly complained about the low performance of the system.
Secondly, there were problems with scaling. Upgrading or purchasing new equipment required significant time and money. This issue became especially relevant in connection with plans to increase the number of 1C users from 160 to 300 people.
Thirdly, the company lacked qualified specialists to maintain the infrastructure. A team of three IT specialists could not quickly restore the server in case of failures.
The customer conducted a financial assessment and came to the conclusion that migrating 1C to the cloud was more profitable than replacing the server and expanding the staff to service it. In our person, the company found a provider who provided a strict SLA and was ready to do everything “turnkey” – to take full responsibility for the migration and configuration of 1C.
Obvious difficulties with 1C transfer
So, we were tasked with migrating all five configurations to K2 Cloud. It would seem to be a typical migration case: launch virtual machines, pull data onto them and set up network connectivity – that's it. However, the 1C product was critically important for the business: all the company's work depended on it, so it was necessary to act quickly and without errors. Due to the location of the offices, it turned out that the 1C program is active almost 22 hours a day. This set the most strict time frame for migration. The standard method of exporting and importing the database using 1C tools was immediately eliminated due to these restrictions. Additional problems were created by the large volume of customer data, as well as the specifics of the configurations. Each of them has its own specific load.
Our department, which specializes in such projects, uses the 1C configuration ranking system and a special calculator to calculate the optimal sizing. The difficulty lies in the diversity of client applications: somewhere thin clients are used, and somewhere thick ones based on old configurations. These differences significantly affect migration planning and cloud infrastructure setup.
Preparing for the project launch
In general, we couldn’t rush into things right away. While our 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 the 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. Dividing the roles reduces the number of common processes, which significantly increases the performance of each virtual machine. This approach is more effective than endlessly increasing capacity.
In addition, it is important to check the settings of virtual machines: the number and frequency of processor cores, the amount of RAM and disk capacity. 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, taking into account that they will soon be in the cloud.
Finally, we set up a backup system taking into account the required parameters of RTO (recovery time) and RPO (recovery point). As you know, administrators are divided into two types: those who do not backup, and those who have already been burned well, and therefore backup. So we paid special attention to database backup. We used our own service, operating 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 estimated one, problems with starting a virtual machine in the cloud, and failures up to critical errors. We have 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 breathed a sigh of relief, as it turned out later, prematurely.
Transfer 1C
To keep the time as short as possible, we used an approach tested on other projects: gradually, without rushing, we copied the bulk of historical data, and then, immediately after the customer's servers were turned off, we transferred the delta — changes from the moment of the first replication. For this, we used Highstacks Acura. The server part of this solution is already installed in K2 Cloud, so all we had to do was deploy agents at the customer's and start replication.
Then, on the agreed day off, we launched the migration itself. If we had transferred all the data at once, the move would have taken several days due to the low speed of the channel between the office and the cloud, but four hours were enough to transfer the delta. The entire migration, from the conclusion of the contract to the complete transfer of all 1C functions to the cloud, took 18 days. Thus, the move had virtually no impact on work processes. With one “but”. This is where the real difficulties began, unfortunately, sometimes they cannot be avoided.
Unpredictable difficulties with 1C transfer
Despite the successful test migration, the customer's 1C system initially began to malfunction.
The first reason was the customer's network infrastructure. It was impossible to accurately replicate its topology within the test. The network engineers who initially created the network and configured the connections between the sites no longer worked for the company. Their successors did not know all the intricacies of the system.
We studied the network together, but still missed several important details. These features “shot” after the transfer – problems with routing to several remote objects arose. Shift workers began calling, who suddenly lost access to 1C. We solved these problems by re-routing routes individually.
The second problem was that 1-to-1 migration was impossible. The customer simply had too old equipment. And although in theory we selected optimal sizings, in practice the configurations had to be additionally adjusted to increase disk performance. In addition, in the process it turned out that the customer had an incorrect SQL server configuration. This also had to be quickly fixed.
As a result, the final setup and optimization of 1C took another couple of days.
What is the benefit for the customer?
Were the resulting 20 days of work and the invested funds worth the result? The answer to this question is always individual. In this case, the customer received four significant benefits from moving to K2 Cloud:
Significant acceleration of 1C work. Thanks to modern hardware, the system began to work faster and more responsive. Users stopped complaining about lags, and it became more pleasant to work.
Confidence in high availability of infrastructure and fast problem solving from the provider. Our standard cloud works here SLA with 99.95% availability, which is one of the toughest on the market. Transferring responsibility for the system to Cloud specialists significantly reduces the workload on the customer's staff.
Scalable cloud platformcapable of supporting any planned expansion of the 1C infrastructure. The customer received access to our cloud console and the entire platform. Now the company can easily increase the resources of the virtual machine or deploy new virtual servers as needed. As a bonus, there are: deployment of databases, caching settings, management of message brokers and much more. For example, if there is a need to quickly create a database cluster in a test circuit, this can be done in just a few clicks.
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 the working group created during the migration stage continue to work.
Final recommendations
If you are planning to migrate 1C to the cloud, start with a test migration. Many providers, including us, offer free trial access. This will help dispel doubts and identify possible problems. However, remember: not all difficulties can be foreseen in advance.
A test migration will allow you to evaluate the operation of 1C in a cloud environment, estimate the costs of supporting the system and understand whether the transition is justified. In some cases, for example, if the company has recently updated its servers or does not plan to expand its business, the transfer may not be advisable.
However, for many companies with a strong IT department, a cloud solution with 24/7 support often proves to be beneficial. Our clients include government agencies, large corporations, and systemically important banks.
Please note: the “here are the resources, do what you want” approach 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 that you can trust with both the transfer and support of the system. Look for a partner who can provide confidence that you will receive competent assistance in case of any problems.
