How to migrate 1C to the cloud: overview
![](https://habrastorage.org/getpro/habr/upload_files/8eb/50f/24d/8eb50f24de4219050d17b1e787c19219.png)
Many companies are replacing applications from vendors leaving the market with 1C solutions. And this is often accompanied by migration to the cloud. I, Anzhelika Zakharova, cloud project manager at K2 Cloud, will tell you how and why companies are migrating 1C applications to the cloud in 2024, and what should be taken into account during migration.
Market Review
In 2023, we saw a 1.5x annual increase in the number of 1C-related requests, including a 5x increase in requests for 1C deployment in K2 Cloud.
More and more industries are ready to migrate to cloud infrastructure. At the same time, there is a shortage of personnel capable of servicing 1C solutions, especially cloud ones. Therefore, many companies want to get 1C in the cloud as a managed service, without going into details about how it works. They expect that the cloud provider will provide a full cycle of 1C servicing, from migration to operational support.
In the context of cloud 1C, we are approached with the following questions:
Migration of 1C from on-premises to the cloud.
Sizing: providing 1C with the required amount of computing resources.
Tuning 1C performance.
Replacing foreign ERP with domestic solutions. In 2022, the share of 1C was 67% of ERP solutions in Russia and continues to grow.
Typical reasons why companies migrate 1C to the cloud:
Speed of deployment. Given the speed with which import substitution sometimes has to be carried out, companies are turning to clouds to quickly obtain the required infrastructure. Pilot projects are also launched in clouds to test import-substituting domestic systems.
Optimization of expenses. Costs for 1C on-premises are growing. The cost of 1C licenses and support services increased by 17%, and the cost of 1C implementation specialists increased by 15% in 2023. The transition to the cloud allows optimizing these costs.
Trust in terms of information security. Clouds are a fully mature solution in terms of information security, and more and more security professionals trust them. We see this in the number of clients who transfer their information security services to our cloud.
Cloud native capabilities. Some tasks are easier to solve in the cloud than on-premises: backup without loading the production, disaster-resistant solutions in several data centers.
Performance optimization. The standard cloud theme of easy scaling of resources during peak loads (for example, generating reports for long periods) or as the project volume changes, and the provider's support for high performance through hardware upgrades are still the reasons for migration.
On tasks that are more difficult to solve on-premises An exaggerated example. The fastest configuration for 1C is a PC with top modern processors, high-speed memory, and an internal disk on VME. A cloud server, even on the latest server processors, will work slower than such a PC: server processors are five years behind desktop ones. But in the pursuit of performance, you need to consider other tasks. There are tasks that the “powerful PC” configuration does not cope well with: Backup clogs up the network. Fast disks and processors will lead to an increase in the amount of data to backup. One day, this amount will not “fit” into the network, and users will not be able to work. Reliability. A single PC has one network interface, one power supply, and possibly one disk. The disk can be mirrored, but what about the network? Tasks that create a high workload. No matter how productive your computer is, there will still be a report that will “hang” the 1C application. Such reports need to be output to other resources. Of course, on-premises infrastructures can implement their own virtualization tools and cloud mechanisms. But most often, the capabilities of public provider clouds are broader and more flexible, and the cost of solving problems is lower due to the scale effect. |
Stages of 1C migration to the cloud and pitfalls
The following stages of 1C migration can be distinguished:
Testing cloud infrastructure.
Infrastructure audit, identification of sizing and network connectivity requirements.
Development and approval of network architecture.
Agreeing downtime windows for migration.
Migration testing.
Productive migration.
Let's look at what should be taken into account at each stage.
Testing cloud infrastructure. Most often, when moving to the cloud, they count on increased productivity. This stage helps the customer make a final decision on moving to the cloud, to make sure that it will be possible to achieve the target productivity of 1C applications in the required configuration. Sometimes testing is carried out with several providers in order to make a choice based on the results.
Infrastructure audit, identification of sizing and network connectivity requirements. Each client creates a unique 1C application configuration, and each migration is a unique project.
During the audit, the following is examined and taken into account:
Initial infrastructure, from which migration is planned: hardware servers, own virtualization system, another cloud provider.
Appendix 1C: 1C:Accounting, 1C:Trade Management, 1C:Salary, etc. The application configuration, its code, and modifications are examined.
DBMS, its configuration, the presence of a cluster. Some DBMS are available in our cloud as PaaS, and data migration can be performed using the built-in tools of the database itself. Other DBMS can be deployed and supported as applications on a VM. Sometimes, to simplify administration, in parallel with the migration of the 1C infrastructure to the cloud, the 1C application is migrated to another DBMS available as PaaS.
1C integrations with business applications. From experience, the client's IT department is not even aware of some integrations.
Network architecture: topology, protection of communication channels, network configuration features, presence of DMZ, and so on.
User access, implemented at the client: terminal farm, VPN, VDI, access via thin client.
Licensing. Licenses used in on-premises infrastructure cannot be simply taken and transferred to the cloud.
Regulatory requirementsrequirements for handling personal data.
Reliability and uptime tools: Replication, Application-Level Fault Tolerance, Disaster Recovery, Backup.
Monitoring. In K2 Cloud for 1C, MaaS (monitoring as a service) is available, native 1C monitoring tools based on APDEX. We also offer templates for Zabbix, tested on many projects.
Separation of accesses between the provider and the client. In the customer's sphere – policies, application management on user terminals, their configuration. In the provider's sphere – VM and hypervisor administration, network, infrastructure applications. This can be implemented in different ways, for example, at the Active Directory configuration level.
Sizingideally taking into account historical data on the size of the DBMS and data growth, resource utilization from year to year.
Sizing. To provide 1C with a sufficient amount of computing resources, it is necessary to take into account: Number of 1C application configurations: some clients have only production, others have test, pre-production and production. The OS of the server on which the 1C application and DBMS are running (Windows or Linux). DBMS requirements for server configuration and database size. Number of users. Requirements arising from integrations with other business applications. A load profile that creates tasks for 1C: reports, scheduled tasks, non-standard operations. Availability of a web server. RTO and RPO if fault tolerance and availability requirements need to be met. |
Taking historical data into account to determine sizing during migration is complicated by the fact that resources in the “before” and “after” infrastructures are difficult to compare. For example, if on-premises and the cloud use different types and generations of processors, their frequencies do not correspond to each other 1:1, and different network connectivity affects network speed requirements.
The solution is monitoring basic performance metrics. Metrics are taken during the pre-migration audit and allow for correct cloud sizing. Further monitoring is performed during the operation of the cloud solution and allows for resource allocation to be adjusted.
Development and coordination of network architecture must ensure:
Connectivity in hybrid infrastructure. In the cloud, you can quickly allocate resources, create a network, and connect all parts of the infrastructure to each other. But building the right network connectivity with existing sites is not always a trivial task.
Seamless user access to cloud services.
Security, regulatory requirements, handling of personal data. Sometimes a simple request for 1C migration to the cloud turns into a large project, since all the requirements were not correctly met in the initial infrastructure. But better late than never.
Agreeing downtime windows for migration. The migration itself can be quick—a few hours or even minutes. But finding a window for it with minimal downtime losses can be difficult. Decisions about agreeing on downtime windows occur at many levels, far beyond the IT department.
Some customers work 24×7, others have branches from Kaliningrad to Vladivostok. There are many migration tools, including built-in tools for each application, hypervisor tools. Sometimes a company is ready to bear additional costs for a more complex migration simply because it reduces or completely eliminates downtime costs.
Migration testing. At this stage, everything that interferes with the move is identified. This may include issues with access, network connections, user connectivity and authentication, address resolution, licensing, and so on. Identified issues are fixed to avoid any surprises during the migration itself.
Productive migration. If all the previous steps are completed carefully, the migration itself will proceed without incident.
Tuning 1C performance during operation
In the course of further operation, the task of tuning the performance of the 1C application may arise. Half of the customer requests to the 1C cloud are on this topic.
Increasing the CPU, physical host size, or VM size will not necessarily improve performance. The bottleneck causing the performance drop could be anywhere.
Performance tuning includes:
Finding a bottleneck. Checking the application server, DBMS, terminal farm, configurations, integrations, access bandwidth to the licensing server, communication channels and performance of user devices.
Monitoring computing resources: 1C server, DBMS server, terminals, network, communication channels from the user to the server. You can even install monitoring agents on users' computers.
Checking the code applications and integrations.
To solve this problem, companies often turn to integrators, as it requires specific experience.
Case: What 1C Looks Like as a Managed Service in the Cloud
Let me give you an example of what the 1C:ERP. Holding Management application looks like in the cloud as a turnkey managed service: the client does not delve into how everything works in the cloud, while we, for our part, provide full support for the service.
Requirements:
Customer access to monitoring dashboards to control the system, component availability. Transferring service management to the provider means that the system status should be as transparent as possible for the customer at any time.
Network connectivity of the cloud with the customer's on-premises infrastructure via a secure channel.
Disaster recovery: configuration for two partner data centers (available through standard K2 Cloud tools).
Authenticate users using Active Directory accounts in the customer's domain: moving to the cloud should not create any changes to the usual behavior of employees.
We have developed an architecture with the following features:
Our own directory service with a trusted relationship with the customer's domain allows us to completely separate areas of responsibility: the customer manages applications and policies, and we manage the infrastructure. The customer does not have access to Active Directory, on the basis of which the service operates in our cloud, and our support service does not have access to the customer's Active Directory.
A terminal farm that provides a working environment for users. Each user has a shortcut on their PC that transparently links them to the farm.
Servers — VM based on Linux, DBMS — PostgreSQL from 1C. Implemented as clusters in two partner data centers.
Automation of infrastructure management based on Ansible + GitLab. This is convenient not only for clients, but also for us for support.
Monitoring with MaaS (monitoring aaS) K2 Cloud. Our administrators and the customer's IT department receive notifications about the system status and failures.
Single solution support service, no ping-pong between vendors and contractors. Regardless of what problem arises, the client contacts us through a “single window”.
Cloud computing resources for 1C tasks
Computing resource | Task type | |
Processors | 3 GHz | for basic 1C tasks |
3.6 GHz with 4.4 GHz boost frequency | for particularly high-load 1C configurations | |
Disks | on magnetic storage devices | large amounts of data inexpensively, archiving |
fast SSD with standard limit up to 10k IOPS | to solve everyday problems | |
super-fast SSDs with increased limit up to 50,000 IOPS | when very large IOPS are needed on small volumes | |
VM on dedicated servers | large fast configuration, no other users on the hypervisor |