The return of an enterprise-software supplier may look like a brand choice. In reality, a customer chooses an architecture of dependence for years: data formats, integrations, staff skills, update rules, licenses and the ability to continue operating if a relationship breaks. RBC Industries examined on July 8, 2025 how prepared the Russian market is for a hypothetical return of foreign technology vendors.
An April 2025 UserGate study put the probability of a partial return by Western cybersecurity suppliers at 3070%. Such a wide range is not a precise forecast. It describes uncertainty over geopolitics, sanctions, commercial incentives, regulation and whether customers will again accept the risk of an externally imposed service cutoff.
The market changed while former leaders were absent. Astra Group chief commercial officer Nikolai Pryanishnikov estimated that Russian software exceeded 50% of the infrastructure segment and could reach 90%, while domestic alternatives covered 7080% of market needs. Maturity remained uneven: databases and certain enterprise classes were strong, whereas engineering and hardware-dependent environments were harder to replace.
For Russia, competition can no longer be reduced to the origin of a license. What matters is whether a system delivers continuity, interoperability and measurable ownership economics. Sound policy does not lock customers into a new monopoly; it enables several suppliers to compete on quality while keeping data portable.
Market share does not equal ecosystem maturity
A larger domestic share shows a change in procurement but not the depth of adoption. A product may be purchased to satisfy a requirement, installed on a limited perimeter or used to support a core process. Each state can produce the same license sale while delivering a fundamentally different business result.
Maturity begins with operation under a real workload. The system must handle transaction volume, integrate with equipment, recover from failure and accept updates without a long shutdown. Code is only one component; documentation, training, support, implementation partners and a clear version lifecycle are equally necessary.
SberTech chief executive Maxim Tyatyshev said that ten or more suppliers can be found in every class of Russia's unified software registry. Numbers create choice but can also fragment resources. Ten incompatible products do not make an ecosystem if every customer must build a unique transition.
Useful measures therefore extend beyond registry entries and sales share. They include active deployments, years in operation, serious incident frequency, upgrade performance and the supply of independent specialists. These distinguish a catalogue of solutions from a market of operating platforms.
Switching cost has become the main competitive barrier
A large company does not replace an enterprise system like a consumer application. Master data, extensions, interfaces, reports and skills accumulate around it. Migration affects finance, procurement, manufacturing, warehouses, staff and customers. License price represents only a fraction of the project.
Polylog technology executive Lyudmila Bogatyreva noted that full alternatives to AutoCAD and SAP were unavailable in many environments when foreign brands left. Industrial equipment from Siemens could be configured around Oracle or SAP compatibility. Replacing one layer required reconsidering the others.
A transition takes years for reasons beyond software development. Data must be cleaned, reference tables mapped, integrations rewritten, access rights verified, users trained and systems operated in parallel. An error in engineering design, a production recipe or financial close can cost more than delaying the technology project.
This helps explain why 67% of large customers in a MyOffice study cited by Alexey Dmitriev opposed returning to Western products. The result is not necessarily a judgment about absolute quality. After an expensive migration, another switch must generate a benefit greater than its new cost and risk.
The complete migration cost map
- licenses, subscriptions and infrastructure capacity;
- data inventory and master-data cleaning;
- rewriting integrations and industry extensions;
- performance, security and recovery testing;
- user training and temporary productivity loss;
- parallel operation and a tested rollback route;
- support, upgrades and specialist scarcity after launch.
Without this map, a cheap license can create an expensive project. Buyers should compare total ownership cost over several years and the cost of exit. A supplier that simplifies data export and documents interfaces reduces customer risk even if the customer never leaves.
Trust has become a technical requirement
Softline chief executive Vladimir Lavrov said that some foreign suppliers failed to meet commercial obligations and left customers without support they had already purchased. Planoplan strategy director Anton Yakovlev added the risk that accounts or databases could be blocked without an effective legal route to recovery.
After that experience, brand promises are insufficient. Trust must be engineered through data location, backups, autonomous operation, source formats and contractual repair times. A customer should know what happens when a cloud is unavailable, a subscription ends, ownership changes or updates are prohibited.
Continuity requires separated control. Critical keys, backups and documentation should not reside at one point under supplier control. Periodic restoration on an independent environment tests whether the plan is real. A backup never restored is only an assumption.
A contract should also describe data export and transition support. A service commitment without portability protects daily availability but not strategic freedom. The more important the system, the clearer its controlled-exit scenario must be.
Regulation changes the form of competition
Foreign solutions face restrictions in state-controlled companies and critical information infrastructure. Cybersecurity products may require certification by the Federal Service for Technical and Export Control, including source-code review, licensing by the Federal Security Service and sector standards such as Bank of Russia requirements.
These barriers protect critical environments but can weaken the market test. If customer access depends only on status, a supplier has less incentive to improve usability, speed and support. Regulatory eligibility should be the minimum threshold after which competition on results begins.
Certification also needs a workable calendar. Product versions develop faster than a lengthy review, leaving customers at risk of using an obsolete release. Processes should assess updates according to their level of change and preserve security without freezing vulnerability repairs for months.
Experts proposed individual review of returning suppliers, compensation for customers harmed by earlier cutoffs, local infrastructure and compatibility with Russian operating systems and databases. These conditions turn a return from a marketing event into a testable commitment.
Interoperability matters more than copying every feature
Domestic developers often sought to reproduce familiar feature sets. A resilient market, however, is built not on identical screens but on products that exchange data and can be replaced layer by layer. Open application interfaces, documented schemas and standard formats reduce the cost of change.
A customer does not have to replace an entire stack at once. It can retain a stable database, change an application module or separate analytics into another environment. Modular architecture permits a product to be tested in one bounded process and expanded only after it proves its result.
Suppliers may regard openness as a threat to retention. In practice it reduces purchasing fear and enlarges the market. A company adopts more readily when it knows its data will not become hostage. The competitive advantage becomes the speed of improvement rather than a technical lock.
Public procurement can promote interoperability by requiring interfaces, export rights and portable configurations. The standard should not dictate internal technology or halt innovation. It defines the boundary where systems meet.
Strong categories show how maturity develops
Experts identified strong Russian database-management systems, enterprise applications, cloud infrastructure, cybersecurity and financial technology. Participants mentioned 1C, MyOffice, R7-Office, Selectel, Yandex Cloud, Cloud.ru, Positive Technologies, Kaspersky and Rostelecom Solar.
Their strength came from more than newly available market share. These categories already had skills, demanding anchor customers and regular feedback. Banks and digital businesses impose high requirements for load and security, giving suppliers an environment in which products improve quickly.
The model can be repeated elsewhere: an anchor customer defines a problem, permits a real trial, measures the outcome and purchases at scale. The developer receives revenue and a reference rather than an endless pilot. A later customer sees evidence under a comparable workload.
Close customer cooperation can also produce unique custom development. A product company must separate a reusable capability from an extension for one buyer. Otherwise every new project starts from zero and scale does not reduce cost.
Residual dependence has moved into the hardware layer
Solar Group commercial director Nikolai Sivak observed that microelectronics and chips remained imported despite promising Russian development. Software independence is limited when the computing platform, network controller or production machine requires a component that may become unavailable.
Hardware dependence cannot be removed by declaration. Design, fabrication, testing and tooling cycles take years and require a large market. Strategy therefore combines local development of critical nodes, multiple supply channels and software portability across processor architectures.
Industrial edge equipment deserves special attention. A server system may be updated centrally, while a factory controller is connected to a specific machine and certified process. Replacement requires a shutdown and repeated safety validation. These dependencies must be inventoried before procurement policy is set.
A software vendor should publish supported platforms and support periods. Customers must examine the roadmap as well as today's compatibility. Otherwise an update to one layer unexpectedly makes another unsupported.
Returning competitors can improve the product
Korus Consulting deputy chief executive Sergey Karpunichev identified healthy competition, better quality and connection with global technology trends as possible benefits of foreign vendors returning. Isolation protects share but can preserve weak features and high costs.
A Russian supplier should prepare not for a particular return date but for continuous comparison. Performance, usability, automation, support quality and repair speed can already be benchmarked against international open practices. Exporting also forces a product to operate in more varied environments.
Predatory pricing presents a separate risk: a large foreign company can reduce price temporarily to rebuild share. The response should not be permanent protection. Contracts can account for migration expense, local commitments and long support, while competition authorities examine whether an offer is sustainable.
Competition works when customers can compare outcomes and move. If the market is divided into incompatible closed environments, every vendor remains a monopoly inside its installed base. Portability is therefore infrastructure for competition.
Chinese and Indian suppliers change the geography of risk
Experts also noted the growing capability of Asian vendors. Their arrival expands choice and access to technology, but simply exchanging Western dependence for Eastern dependence does not create resilience. Data control, export restrictions, service networks and compatibility remain the same questions.
Partnership offers more than conventional imports when it includes joint development, local support, documentation and several production locations. Customers gain the ability to maintain the system domestically while suppliers gain market access and adaptation.
Localization must be measured by substance. Registering a legal entity and installing a server do not equal knowledge transfer. Decision makers should ask who owns the source, can repair a vulnerability, produces the critical component and controls an update.
A multivendor architecture reduces dependence on one country but increases integration complexity. Common standards and automated compatibility testing turn supplier diversity into redundancy rather than a collection of isolated islands.
Customers need to manage a portfolio, not a license list
A large organization operates hundreds of systems. Some are critical to production and cash, while others support auxiliary processes. One replacement policy for all is inefficient. Systems should be classified by business impact, supplier exposure, alternative maturity and switching cost.
A critical environment receives independent backups, recovery tests and reduced reliance on closed formats. Immediate migration from a stable low-risk system may not pay. A modular pilot can create an option for a fast-changing process without requiring a large irreversible decision.
An architecture committee should include the business owner, security, operations, finance and procurement. Technology staff understand the system but may not fully see shutdown cost or process change. A joint decision connects technical exposure with the commercial outcome.
The portfolio is reviewed regularly. A supplier may improve a product, change price, end a version or open an interface. A decision that made sense two years ago is not permanent. Review does not mean constant migration; it confirms that the existing platform still offers the best balance.
A practical test of technology independence
- Identify the processes that stop when the system stops.
- Verify data ownership, export formats and independent backups.
- Map integrations, equipment and scarce skills.
- Measure performance, recovery and update quality.
- Calculate ownership and exit costs over several years.
- Test an alternative in a bounded real environment.
- Define contractual duties when service ends.
The test does not require replacing everything with domestic or foreign software. It requires proof that the organization understands its dependence and can act. Independence is not the absence of outside components; it is the managed ability to continue a core process when a supplier or its conditions change.
The central lesson: competition has moved from licenses to architecture
Russian developers captured a substantial share of infrastructure software and now cover much of customer demand. This is a real change supported by deployments and product development. Yet the average estimate of 7080% does not eliminate difficult gaps in engineering applications, complex management systems and hardware.
A returning foreign vendor would not meet the market of 2021. Customers have already paid transition costs, developed new skills and become more alert to cutoff risk. Regulation has closed some critical segments. Brand recognition and a discount alone will not restore the former position.
A domestic supplier does not receive a permanent guarantee either. Customers will demand maturity, support, usability and compatibility. Competition with Western or Asian companies can accelerate quality when rules protect data and prevent temporary pricing power from destroying a functioning market.
The strongest position belongs not to a closed platform but to an ecosystem that is expensive to leave because it creates value, not because exit is blocked. Open interfaces, documented data and a capable partner network turn trust into a verifiable property.
The decisive question in 2025 is not who returns. It is whether an enterprise can survive any change in its supplier landscape without losing control, data or production. When that ability is built into architecture, competitors stimulate development instead of turning a technology choice into a new systemic risk.
ADI News
Leave a comment