Software import substitution in Russia: what it actually means for IT leaders
A clear-eyed look at the Russian domestic software registry and what it really changes in procurement and enterprise architecture.
Talk of IT import substitution has been running since 2014, but it is only now starting to drive real decisions. The domestic software registry keeps growing, regulatory requirements on state structures are tightening, and more and more executives in the private sector are asking: will this reach us too?
I work with companies that frame this question differently. Some treat it as a purely regulatory task. Others see it as a reason to rethink their architecture. Both framings make sense, but it is important not to mix them up.
What has actually changed
The domestic software registry is a procurement tool for the public sector. If your company is not a state entity and does not work on government contracts, there is no direct requirement for you to move to registered software. Understanding this clearly matters - it prevents you from making architectural decisions under pressure that does not actually exist.
What has genuinely changed is market dynamics. A number of Russian vendors have received funding and a reason to develop their products. Some of them have made real progress over the last two or three years and are now competitive in specific categories. Dismissing them purely because they are "domestic" is no longer always rational.
Where alternatives work, and where the gap remains
There are categories where Russian solutions are reasonably usable today: accounting and tax, electronic document management, some HR systems, a few collaboration tools. These are areas where Russian vendors have been building for years.
There are categories where the gap remains significant: complex industrial ERP, analytics platforms, specialised engineering software, most DevOps tooling. Switching here is not a question of willingness - it is a question of product maturity and available market expertise.
The most dangerous position is when a decision is made on political rather than technical grounds, and the project budget quietly absorbs integration work and workarounds that end up costing more than the Western licence ever did.
The architectural question worth asking
If you are seriously looking at the topic, the right question is not "which Russian product replaces our current stack". The right question is "how tightly is our architecture coupled to specific vendors at all".
Systems built on open standards and open-source components are less vulnerable to changes in any licensing policy - whether regulatory or vendor-driven. PostgreSQL instead of Oracle, Linux instead of Windows Server, containerisation instead of deep middleware lock-in: all of these reduce dependency for architectural reasons, not political ones.
How to make decisions in this environment
Questions I recommend going through for each IT component you are reviewing:
- Do we have a direct regulatory requirement for this component, or are we reacting to a sense of pressure that may not be real?
- If we replace this component, what is the actual cost of data migration and retraining people?
- Is there market expertise for the alternative product, or will we be the first movers?
- What does the vendor roadmap look like - is this an actively developed product or one running on maintenance mode?
- What happens to this component in three years under different regulatory scenarios?
Import substitution as a topic is not going away. But decisions in this space are best made with a cool head - analysing each component on its merits, not rewriting the entire stack under external pressure.