Software import substitution

The legal frame comes in layers. The unified registry of Russian software is maintained by the Ministry of Digital Development, and inclusion requires that rights to the product belong to Russian entities, that support is delivered inside Russia, and that dependence on foreign components is limited. Government Decree 1236 restricts foreign software in public procurement wherever a domestic equivalent exists in the registry. Significant critical infrastructure facilities fall under separate presidential decrees mandating a move to predominantly Russian solutions. This is not a recommendation or a trend, it is a condition of access to an entire class of contracts.

The market behind this is large and active, and it is not limited to the public sector. The mass departure of foreign vendors made the question practical for commercial companies too: expired licences, closed access to security updates, dead cloud consoles, broken SDKs and payment integrations. At that point substitution stops being a regulatory topic and becomes an operational risk question. The domestic stack now covers most standard needs: operating systems and office suites, PostgreSQL-based database systems, Russian clouds, corporate communications, CRM and accounting systems, and CMS platforms for websites.

Migration practice yields a consistent set of lessons. Start with an inventory: which systems are in use, what data sits in them, which integrations connect them, and what happens if a given product stops working tomorrow. Then prioritise by risk rather than by ease, tackling first the places where losing support would hurt most. A migration is almost never a one-for-one replacement, since formats, roles and familiar workflows all change, so the budget has to include data migration, integration rework and staff training rather than licence costs alone.

A trap that rarely gets flagged: presence in the registry does not by itself mean a product will cover your requirement. The registry confirms origin and legal status, not functional equivalence. Verification has to happen on your own scenarios, through a pilot on a real piece of work with real data volumes and real users, before any large contract is signed. The second common miscalculation is leaving the most connected systems for later, because the longer a core migration is postponed, the more integrations accumulate around it and the more expensive each additional month of waiting becomes.

Related terms

• Legacy codeLegacy code is working code that is expensive to change: it runs on an outdated stack, has no test coverage or has lost its authors, so every edit means reconstructing the logic from the source and risks breaking something unrelated.
• Russian personal data law (152-FZ)152-FZ is the Russian personal data law: it requires that data on Russian citizens be collected in databases located in Russia, that the regulator be notified of processing, that consent be obtained separately, and that any breach be reported within 24 hours.
• Technical specificationA technical specification is the document that fixes what exactly will be built and on what grounds the work counts as accepted: goals, roles, scenarios, screen-level requirements, integrations, non-functional requirements and an explicit out-of-scope section.
• Outsourcing vs in-houseOutsourcing and in-house are two ways to cover a development need: contract an external team at an agreed hourly rate, or build a staff team where salaries come with payroll taxes, recruitment, equipment and management on top.
• SLAAn SLA is a service level agreement: it fixes system availability as a percentage, response and resolution times by incident severity, the hours support operates, and the compensation owed when the provider fails to meet those numbers.

Related services

• IT consulting and product auditThe most expensive mistakes in software happen before the first line of code: a misread problem, a stack chosen out of a contractor’s habit, and a specification that does not exist. Consulting exists to settle all of that before the development meter starts running: what to build, out of what, at what cost and in which order. The result is a document, not an opinion on a call.
• CRM implementation and sales automationEnquiries from messengers, email and calls get lost when the only place tracking them is a sales manager’s memory. A CRM fixes this, but only when it is configured around your actual sales process rather than left as the out-of-the-box default. We implement amoCRM and Bitrix24, set up automation, and connect everything to the website, telephony and analytics.
• AI strategy consultingMost companies have already run at least one AI pilot. A minority have taken even one pilot to stable, ongoing use. The gap usually is not the model, it is whether the process had a measurable payoff and whether the real running cost was worked out before starting. We help pick the right entry point so budget does not disappear into a demo that stays a demo.

Read more

• How to Choose a Tech Stack: Criteria That Outlive the HypeA stack is a five-year commitment usually made in a single call. Here is the order the decisions should be taken in, the criteria that carry real weight, working stacks for six project archetypes and what a wrong choice costs.
• Redesigning a Site Without Losing Traffic: Stages, Risks and the SEO Migration ChecklistHalf of all redesign requests are really content, speed or offer problems. How to tell them apart, why a phased rollout beats a big bang launch, and what belongs in the migration checklist so the organic traffic survives.
• How to Choose a Development Contractor: The Question List and the Red FlagsA practical guide to choosing a development vendor: who needs a freelancer and who needs an integrator, the 25 questions for the first call, how to verify portfolio cases and what belongs in the contract.