Software import substitution: where to start and what to replace first

Why you cannot replace everything at once

Replacing email, the messenger, file storage, and office documents all at once paralyzes the work: employees lose their familiar tools in a single day, and support drowns in identical questions.

Import substitution is more reliable as a series of managed steps. At each step one layer is replaced, the team gets used to it, and only then does the next one begin.

• email and domain
• messenger and calls
• files and documents
• accounting and industry systems

Where to start the inventory

The first document is boring, but it shapes the whole project: a list of programs and services, who uses them, where the data is stored, whether there is a valid license, and what happens if access disappears.

After that, software splits into three groups: critical (the business stalls without it), important (it slows processes down), and optional (it can wait). Replacement begins where "critical" and "at risk" overlap.

• what is used and by whom
• where the data lives
• license and update status
• what happens if access is lost

Russian cloud or your own server

Some tasks are covered by ready-made Russian platforms — email, work hubs, video calls. Others are more convenient to keep on your own server: a messenger, file storage, internal services where full control over access and data matters.

The choice depends not on fashion but on who administers it, what the data requirements are, and how critical autonomy is. A mixed setup is often sensible: cloud where it is faster, self-host where control is needed.

Russian software by category

For every familiar foreign tool there is a domestic or self-hosted counterpart, and it is easier to think in categories than in individual products. Email is covered by domain mail services, team communication by work platforms and messengers, files and documents by cloud drives with online editors, and sign-in and permissions by a single access-management system.

Some categories are simpler to take as a ready cloud service, others to deploy on your own server when control matters. The rule stays the same: compare working scenarios, not brands — what employees actually do today and how to cover it tomorrow without losing the familiar result.

• email on the domain
• messenger and video calls
• file cloud and online office
• single sign-in and access management

Which risks to weigh first

The decision about what to replace first rests on risk, not convenience. For each service, ask: what happens if updates stop tomorrow, the license can no longer be paid, or support goes silent. The more critical the fallout, the higher the replacement priority.

Dependence on a single vendor deserves a separate look: closed data formats, lock-in to one cloud, and the lack of a proper export. These spots are the most dangerous — even a service that works today becomes a trap if you cannot get your data out of it.

• access to updates and security fixes
• the ability to renew the license
• availability of a data export
• support speed and language

How to get through the transition

The most vulnerable moment is running the old and the new in parallel. To avoid losing data, the migration is done through a test export on one set, while the old system is kept in read-only mode as a fallback.

The project is finished not on the day the old software is switched off, but after a short support period: when employees have adjusted, instructions are written, and the administrator understands how it all works.

What plans often miss

The technical move is usually described in detail, while blind spots remain around it. The first is format compatibility: documents, templates, and exports from the old programs do not always open in the new ones without loss, so it is better to check this in advance on real files.

The second area is people and the links between systems. Employees need short instructions and time to adjust, while integrations, API exchange, and automatic feeds into adjacent services have to be reconfigured — otherwise processes quietly break after launch.

• format and template compatibility
• training and instructions for employees
• integrations and API exchange
• backups for the transition period

Common import-substitution mistakes

The most common mistake is replacing software under deadline pressure rather than by plan: the company grabs the first counterpart it finds, migrates data without checking, and then patches the fallout for months. Right next to it is postponing the export question: while the old service still works, it feels like the data is always at hand, and at switch-off you can no longer get it out.

Two more typical traps are forgetting about training — the tool is rolled out but people do not use it — and not assigning an owner for the move. Without a project owner, decisions are made ad hoc, priorities blur, and deadlines slip with no clear reason.

• replacing in a rush with no plan
• migrating data without checks
• no export and no backup
• no owner for the move

How to tell the move succeeded

Import substitution is measured not by the fact that new software is installed, but by calm work afterwards. A good sign is no downtime on switch day, data migrated without loss, and employees who keep working without a rush on support.

To that add the boring but important things: written documentation, access the administrator understands, verified backups, and a rollback plan. Once all of that is in place, you can switch off the old system and move on to the next layer.