Import substitution, open source, and architectural sovereignty
The departure of Western vendors placed companies in front of a real architectural choice. A breakdown of how to think about it systematically rather than reactively.
2022 sharply accelerated the conversation about software import substitution. The exit or suspension of SAP, Oracle, Microsoft, and dozens of other Western vendors from the Russian market left many companies in a situation they were not prepared for.
Business responses split into two extremes. Some rushed to find direct product-for-product replacements. Others entered a waiting mode, hoping the situation would change. Neither is a complete answer.
I want to offer a more systematic way to think about this problem.
Three different questions under one word
"Import substitution" in the current context conflates at least three distinct tasks, and they are worth separating.
Operational continuity is the question of "what do we do right now if a specific product becomes unavailable." This is a short-term task with a limited horizon.
Reducing dependency is the question of "how do we rebuild architecture so that reliance on a single vendor does not create critical risk." This is a medium-term task.
Architectural sovereignty is the question of "how do we structure IT infrastructure so that strategic decisions are made inside the company rather than being dictated by an external supplier's roadmap." This is a long-term task.
The mistake is addressing the long-term task with short-term methods. Replacing SAP with a Russian equivalent without rethinking the architecture is just trading one dependency for another.
Where open source changes the calculation
It is important to understand the real state of open source in enterprise systems.
A significant portion of modern IT infrastructure already runs on open source components - databases (PostgreSQL, MySQL, ClickHouse), operating systems (Linux), orchestration tools (Kubernetes), languages and frameworks. For these components, the question of "replacing a Western product" does not arise, because they never belonged to any single vendor.
The tension appears in a different class of systems: enterprise ERP, BI platforms, specialised industry solutions. Here open source alternatives either fall short on functionality or require substantial investment in adaptation and support.
The honest answer: for certain enterprise systems, there is no good ready-made replacement. That is not a reason for panic - but it requires a strategic choice, not a search for the nearest analogue.
How to think about the transition
First step - dependency inventory. For each critical system: which vendor, what is the risk of unavailability, what are the alternatives, what is the migration cost?
Second step - classification by criticality and horizon. Not everything needs to be replaced immediately. Some systems can be maintained in their current state for several years. Others require action within months.
Third step - choosing a strategy for each category. Direct replacement, migration to open source with customisation, building an in-house solution, or dropping the functionality - these are different strategies with different costs and risks.
Fourth step - assessing internal competencies. An open source solution with nobody to maintain it is not a solution. The question "do we have the team for this?" must be asked before the decision, not after.
A practical conclusion
Architectural sovereignty is not the goal of "installing everything domestic." It is the ability to make strategic decisions about your IT infrastructure without forced dependence on decisions made outside your control.
Open source is one tool for achieving this goal. Not the only tool and not always the best one. But for many foundational infrastructure layers it is already a mature choice with a working ecosystem.
Start with an honest answer to the question: which external systems are you critically dependent on, and what happens if access to them stops? That is a more useful question than searching for a replacement to a specific product.