Импортозамещение digital-стека: как перейти на российские сервисы без остановки бизнеса

Практическое руководство по импортозамещению цифрового стека: что замещать, а что нет, карта замен для облаков, аналитики, платежей, CRM, офиса и AI-моделей, миграция без остановки бизнеса, риски и оценка стоимости.

К 2026 году импортозамещение цифрового стека перестало быть темой презентаций и стало операционной задачей. Часть зарубежных сервисов недоступна, часть работает без гарантий и может отключиться в любой момент, часть не принимает оплату из России, а требования к хранению персональных данных и к программному обеспечению в ряде отраслей ужесточились. При этом полная остановка бизнеса ради переезда недопустима: сайт должен принимать заявки, платежи — проходить, аналитика — считать. Ниже — практическое руководство: что действительно нужно замещать, а что нет, карта замен по категориям сервисов, порядок миграции без остановки процессов, как не потерять исторические данные и сквозную аналитику, как оценить стоимость переезда и где чаще всего совершают дорогие ошибки. Зачем этим заниматься, если всё пока работает Риск внезапного отключения. Зарубежный сервис может прекратить работу для российских пользователей без предупреждения. Переезд в режиме пожара всегда дороже и опаснее планового. Оплата. Продление подписок на зарубежные сервисы требует обходных схем, которые сами по себе становятся источником риска. Требования к персональным данным. Сбор и хранение персональных данных граждан России должны вестись с использованием баз данных на территории страны, а передача за рубеж требует отдельных оснований и уведомлений. Сервисы форм, CRM и аналитики с серверами за рубежом создают прямой риск нарушения. Подробно — в статье о 152-ФЗ на сайте . Отраслевые требования. Для государственных организаций, субъектов критической информационной инфраструктуры и ряда регулируемых отраслей действуют отдельные требования к использованию российского программного обеспечения. Применимость к конкретной компании стоит проверить с юристом. Поддержка и безопасность. Сервис, который формально работает, но не обновляется для российских клиентов и не отвечает на обращения, накапливает уязвимости. Что нужно замещать, а что нет Первый шаг — инвентаризация, а не паника. Разложите используемые сервисы по трём корзинам. Критичные и рисковые. Без них останавливаются процессы, а доступ не гарантирован: платежи, облачная инфраструктура, CRM, почтовые рассылки, аналитика, сервисы, хранящие персональные данные. Замещать в первую очередь. Важные, но заменимые без спешки. Таск-трекеры, дизайн-инструменты, корпоративные мессенджеры, офисные пакеты. Работают, но нужен план Б. Открытые технологии. Языки программирования, фреймворки, библиотеки и базы данных с открытым кодом заменять не нужно: React, Node.js, PostgreSQL, Nginx не являются сервисами, которые можно отключить. Их подмена — самая частая и самая дорогая ошибка в проектах импортозамещения. Отдельно отметьте скрытые зависимости: шрифты и скрипты с зарубежных CDN, виджеты карт, капчи, пиксели рекламных систем, библиотеки, которые при работе обращаются к внешним API. Они не видны в списке «подписок», но ломаются вместе с сервисами. Карта замен по категориям Инфраструктура и облака Зарубежные облака замещаются российскими провайдерами — например, Яндекс Облако, VK Cloud, Selectel, Timeweb Cloud. Ключевой критерий выбора — не витрина услуг, а совместимость: объектное хранилище с S3-совместимым API, управляемые базы данных и управляемый Kubernetes позволяют перенести приложение без переписывания. Проверьте также наличие нужных регионов и зон доступности, условия SLA и возможность выгрузить данные при смене провайдера — чтобы не заменить одну зависимость другой. Аналитика Яндекс Метрика закрывает большинство задач веб-аналитики, включая запись сессий, карты кликов и цели. Для продуктовой аналитики с воронками и когортами существуют российские и self-hosted решения. Важное следствие: при переходе теряется историческая база, поэтому данные нужно выгружать до отключения, а не после. Если на аналитике построена сквозная связка «реклама — заявка — сделка», её переносят как отдельную задачу — как устроена такая связка, мы разбирали в статье о сквозной аналитике . Платежи ЮKassa, Т-Касса, Робокасса, CloudPayments, прямое подключение к Системе быстрых платежей. Техническая интеграция обычно несложная, но заложите время на юридическую часть, фискализацию и проверку сценариев возвратов и повторных платежей — именно там обнаруживаются расхождения. Для подписочных сервисов перенос привязанных карт между провайдерами — отдельная задача: токены одного провайдера у другого, как правило, не работают. Подробно — в статье о подписочном биллинге . Коммуникации с клиентами Российские сервисы email- и SMS-рассылок, мессенджеры, чат-боты. Разумный принцип — не зависеть от одного канала: доступность отдельных мессенджеров и их функций в России менялась, поэтому важные уведомления стоит дублировать по email или SMS, а базу контактов хранить у себя, а не только внутри платформы мессенджера. CRM и внутренние системы Битрикс24, amoCRM, российские BPM-платформы и учётные системы. Здесь миграция сложнее всего: переносятся не только данные, но и процессы, воронки, автоматизации, права доступа и интеграции с телефонией, сайтом и учётом, а процессы обычно нигде не описаны. Перед переездом стоит описать, как система используется на самом деле, а не как её когда-то внедряли. О связке CRM с учётом — в статье об интеграции CRM и 1С . Офис и совместная работа Российские офисные пакеты и платформы совместной работы — например, МойОфис и Р7-Офис, — корпоративные мессенджеры и сервисы видеосвязи. Главные вопросы при переходе — совместимость форматов документов, совместное редактирование, интеграция с почтой и хранилищем и привычки сотрудников. Здесь особенно важен пилот на одном подразделении. Разработка и дизайн Репозитории кода и CI/CD можно разместить в self-hosted решениях в собственной инфраструктуре или у российских сервисов. Дизайн-инструменты — зона, где замена чаще всего упирается в привычки команды и совместимость файлов; стоит заранее выгрузить библиотеки компонентов и макеты в форматах, которые можно открыть без исходного сервиса. AI-модели и сервисы Если продукт или внутренние процессы используют зарубежные языковые модели, есть два риска: доступность API и передача данных за рубеж. Альтернативы — российские модели, такие как GigaChat и YandexGPT, и открытые модели, развёрнутые в собственной инфраструктуре. Архитектуру AI-функций стоит строить так, чтобы модель можно было заменить без переделки продукта. Как это устроено на примере RAG-систем, — в статье о RAG для бизнеса . Порядок миграции без остановки бизнеса Инвентаризация. Полный список сервисов и скрытых зависимостей: кто пользуется, какие данные хранятся, что сломается при отключении, кто владелец аккаунта и кто платит. Приоритизация по риску. Сначала то, где отключение останавливает выручку или нарушает требования к персональным данным. Выбор замены с пилотом. Проверка на реальных сценариях и данных, а не по сравнительной таблице функций. Выгрузка исторических данных. До отключения. Это единственный необратимый шаг во всей миграции. Параллельная работа. Новый сервис запускается рядом со старым, а не вместо него. Период параллельной работы нужен, чтобы сверить результаты: заявки, платежи, события аналитики. Переключение и наблюдение. Первое время после переключения сохраняйте возможность откатиться. Отключение старого сервиса после подтверждения, что данные перенесены, интеграции работают и сотрудники перешли на новый инструмент. Риски и как их снять Потеря исторических данных. Снимается выгрузкой заранее. Восстановить данные после отключения сервиса обычно невозможно. Разрыв сквозной аналитики. При смене системы ломается связка «источник — заявка — сделка». Заранее сверьте, какие метки, события и поля переносятся. Скрытые зависимости в коде. Внешние шрифты, карты, капчи, SDK. Проверяются заранее — например, запуском сайта с заблокированными внешними доменами. Потеря SEO-позиций при переезде сайта на другую платформу или хостинг. Снимается планом переезда с сохранением адресов и перенаправлениями — подробно в статье о переезде сайта без потери трафика . Сопротивление сотрудников. Новый инструмент без обучения и объяснения причин тихо саботируется. Нужны пилот, обучение и понятный срок отключения старого инструмента. Новая зависимость. Российский сервис тоже может изменить условия или прекратить работу. Выбирайте решения с возможностью выгрузки данных и стандартными интерфейсами. Переписывание того, что переписывать не нужно. Открытый стек замены не требует. Время, потраченное на замену фреймворка, — время, не потраченное на перенос платежей. Как оценить стоимость переезда Прямые лицензионные платежи — меньшая часть стоимости. Полная оценка включает: стоимость новых сервисов и инфраструктуры на горизонте нескольких лет; работы по миграции данных и перенастройке интеграций; доработку продукта под новые API; период параллельной работы двух систем; обучение сотрудников и временное снижение продуктивности; риски и стоимость простоя, если переезд откладывается до вынужденного. Последний пункт часто решает вопрос: плановый переезд обходится дешевле экстренного, даже если сейчас зарубежный сервис ещё работает. Чек-лист перед стартом Составлен полный список сервисов, включая скрытые зависимости в коде сайта. Для каждого сервиса известен владелец аккаунта, хранимые данные и последствия отключения. Определены сервисы, хранящие персональные данные за рубежом. Расставлены приоритеты по риску для выручки и требований закона. Выгружены исторические данные из сервисов, подлежащих замене. Для каждой замены запланирован пилот и период параллельной работы. Проверено, как переезд затронет сквозную аналитику и SEO. Назначен ответственный за миграцию и определены сроки отключения старых сервисов. Переезд инфраструктуры, платежей и интеграций мы ведём в рамках автоматизации бизнес-процессов и разработки веб-проектов . Частые вопросы Нужно ли переписывать сайт на российский фреймворк? Нет. React, Vue, Node.js и другие открытые технологии не являются сервисами и не могут быть «отключены». Замещать нужно внешние сервисы, от которых зависит работа продукта, а не язык и фреймворк. Сколько занимает миграция? Зависит от числа сервисов, объёма данных и сложности процессов. Перенос инфраструктуры и аналитики обычно проще и быстрее, CRM с процессами и интеграциями — дольше всего. Основное время уходит не на технику, а на описание процессов, которые до этого нигде не были записаны, и на период параллельной работы. Что делать с зарубежными шрифтами и картами? Шрифты — размещать на своём сервере, это заодно ускоряет загрузку страниц и убирает передачу данных посетителей третьей стороне. Карты — переходить на российские картографические сервисы, API которых покрывает типовые сценарии. Можно ли мигрировать поэтапно? Не только можно, но и нужно. Одномоментный переезд всего стека — самый рискованный сценарий. Правильный порядок: сначала критичное и рисковое, затем остальное. Как быть с зарубежными AI-сервисами в продукте? Оценить, какие данные в них передаются, и спроектировать возможность замены модели. Для данных клиентов и коммерческой тайны безопаснее российские модели или открытые модели в собственной инфраструктуре. Нужно ли входить в реестр российского ПО? Это важно для компаний, которые продают программное обеспечение государственным заказчикам и организациям с требованиями к российскому ПО. Для компаний, которые просто используют сервисы, вопрос в другом — соответствуют ли используемые решения требованиям, применимым к их отрасли.