Импортозамещение CRM 2026: чем заменить Salesforce

Salesforce, HubSpot и Zoho прекратили обслуживать клиентов из России, и замена им сводится к трём рабочим сценариям. Выбирать между ними стоит по объёму контура, который вы закрывали, а не по похожести интерфейса. Битрикс24 берёт на себя всю компанию: продажи, задачи, документы, внутренний портал, телефонию — это ближе всего к сценарию, когда зарубежная система была не только CRM, но и рабочим пространством отделов.

amoCRM закрывает отдел продаж и сознательно не пытается быть большим. Воронка, сделки, каналы общения с клиентом — если из прежней системы вы использовали в основном это, расширенный корпоративный портал будет лишним весом, за который придётся платить и который придётся администрировать. Здесь работает простое правило: чем уже был реальный сценарий использования, тем проще и дешевле замена.

Третий сценарий — self-hosted EspoCRM на вашем сервере. Ядро open-source, платы за каждое рабочее место нет, база лежит в вашем контуре, структуру можно менять под себя без оглядки на тарифную сетку. Взамен появляется своя ответственность: сервер, обновления, резервные копии, мониторинг. Это подходит не всем, и на бесплатном экспресс-аудите мы честно скажем, нужен ли вам такой переезд или выгоднее остаться в облаке.

Отдельно стоит развести продажи и маркетинг. Если из HubSpot у вас жила в основном воронка и работа менеджеров — задача решается переездом в CRM. Если на нём держались рассылки, лендинги и сценарии прогрева, часть контура придётся собирать из отдельных российских сервисов и связывать их с CRM через API. С Zoho ситуация похожая: это семейство приложений, и переезжает обычно не всё сразу, а те два-три модуля, которыми пользовались по-настоящему.

Компании обычно считают риск переезда как «а вдруг не перенесутся контакты». Контакты как раз переносятся почти всегда — теряется то, что живёт вокруг них и что сложнее выгрузить. Ниже список того, что при миграции требует отдельной работы и о чём стоит договориться с подрядчиком до старта, а не в процессе.

Практический смысл переезда — не «найти такую же систему», а разложить свои реальные функции по новым инструментам. Ниже соответствие типовых блоков зарубежной CRM тому, чем они закрываются в России. Колонки не конкурируют между собой: в одном проекте выбирается одна платформа, а таблица помогает увидеть, где замена прямая, а где потребуется отдельная работа.

Ограниченный экспорт — не исключение, а норма при уходе с чужой платформы. Штатная выгрузка обычно отдаёт плоские таблицы: контакты отдельно, сделки отдельно, а связи между ними, история и вложения либо не попадают в файл вообще, либо приходят в виде, непригодном для загрузки. Поэтому первый шаг миграции — не выгрузка, а аудит того, что вообще доступно через API исходной системы.

Дальше порядок работ выглядит так. Сначала проектируется структура целевой системы: валюта, воронки и их стадии, справочники источников, кастомные поля. Это делается до переноса, потому что грузить данные в неподготовленную структуру — гарантированный второй заход. Затем переносятся справочники и объекты в правильной последовательности: компании, контакты, лиды, сделки — чтобы связи между записями собирались на лету, а не восстанавливались руками потом.

История общения — отдельный блок. Дела, звонки и комментарии из исходной системы сводятся в таймлайн новой CRM, чтобы менеджер открывал карточку и видел хронологию, а не пустое поле. Технически это самая трудоёмкая часть переноса и одновременно та, ради которой миграцию вообще делают: без истории новая система стартует с нуля, и первые месяцы менеджеры продолжают ходить за контекстом в старые файлы.

Там, где штатных возможностей не хватает — нестандартный объект, специфическая связка, вложения, которые не отдаёт API, — работа переходит в область заказной разработки: пишется отдельный скрипт-мост под конкретную пару систем. Это нормальная часть проекта, но её объём должен быть назван до старта, а не всплыть в середине.

Быстрая миграция без сверки выглядит успешной ровно до первой претензии клиента, о которой никто в компании не может вспомнить подробности. Проверять нужно не «примерно похоже», а каждую запись: столько же компаний, столько же контактов, те же значения в тех же полях, та же принадлежность сделки менеджеру. Расхождения всплывают всегда — вопрос лишь в том, находит их подрядчик до переключения или ваш отдел продаж после.

Как это выглядит в цифрах на реальном проекте. В миграции мебельной компании (кухни) с Bitrix24 на self-hosted EspoCRM мы сначала провели аудит REST исходной системы и спроектировали структуру: валюта, десять объединённых стадий двух воронок, 22 источника и 66 кастомных полей. Затем перенесли записи с проверкой 1:1 — 45 компаний, 2217 контактов, 1541 лид и 668 сделок, а дела и комментарии свели в 2584 записи таймлайна Stream EspoCRM. Дополнительно подключили WhatsApp-канал прямо в CRM через технического пользователя-мост.

Честно про статус этого проекта: он в фазе внедрения, а не финального релиза. Прод-домен поднят, интерфейс проверен в браузере, но перенос файлов и настройка автоматизации ещё в работе — они упираются в технические ограничения выгрузки из исходной системы. Мы рассказываем об этом прямо, потому что именно эти два блока чаще всего недооценивают при планировании переезда, и лучше узнать о них из статьи, чем на своём проекте.

Отсюда практическое правило для выбора подрядчика: спрашивайте не «за сколько дней перенесёте», а «как будете сверять и что делаете, если API не отдаёт часть данных». Ответ на второй вопрос показывает опыт гораздо надёжнее, чем обещанный срок.

Закон 152-ФЗ требует, чтобы персональные данные российских граждан собирались и хранились в базах, размещённых на территории России. CRM — это в чистом виде база персональных данных: ФИО, телефоны, почта, адреса, история обращений, иногда данные документов. Пока клиентская база лежала в зарубежном облаке, вопрос был открытым; уход вендоров просто перевёл его из плоскости соответствия в плоскость операционного риска.

Практический смысл в том, что при выборе новой системы этот критерий работает наравне с функциональными. Облачные российские платформы держат данные в отечественных дата-центрах, коробочная версия и self-hosted CRM — на вашем собственном сервере. Второй вариант даёт максимум контроля: вы точно знаете, где физически лежит база, кто имеет к ней доступ и что происходит при смене подрядчика.

Есть и вторая сторона, о которой в контексте импортозамещения говорят реже. Данные на своём сервере — это ваша зона ответственности: резервные копии, обновления, разграничение прав, защита периметра. Соответствие закону не появляется само от факта переноса на свой сервер, оно появляется вместе с настроенными процессами вокруг него. Мы это проговариваем на аудите, потому что для части компаний облако российского провайдера окажется более разумным и более безопасным решением, чем собственный сервер без администратора.

Отдельно стоит помнить про смежные контуры: формы на сайте, чат-боты, телефонию, коллтрекинг. Если CRM переехала в РФ, а заявки по-прежнему проходят через зарубежный сервис форм, задача решена наполовину. Полный список точек, где у вас собираются персональные данные, лучше составить до переезда — это дешевле, чем достраивать контур по частям.

После переезда почти всегда остаётся хвост: несколько интеграций и кусков логики, которых в новой системе нет. Обычно это связка с 1С или складом, личный кабинет клиента, обмен с производственным учётом, специфический расчёт цены, выгрузка на маркетплейсы. В зарубежной системе часть этого закрывалась готовыми приложениями из маркетплейса, и рассчитывать на такой же ассортимент готовых решений не стоит.

Порядок действий здесь простой. Сначала честно разделите список на три части: что закрывается штатными возможностями новой платформы, что решается готовой интеграцией российского вендора и что придётся писать. Третья часть — это заказная разработка, и её стоит оценивать отдельной сметой, а не растворять в цене миграции. Так вы видите реальную стоимость каждой функции и можете отказаться от той, которая внезапно оказалась дороже пользы.

Важный момент про порядок: сначала переезд и стабильная работа базового контура, потом доработки. Попытка одновременно перенести данные, пересобрать автоматизацию и написать три интеграции обычно заканчивается тем, что отдел продаж месяц работает в двух системах сразу. Управляемое переключение с возможностью отката существует именно для того, чтобы этого не произошло.

Начните с бесплатного экспресс-аудита на 30 минут. На нём разбираем, какие функции прежней системы вы реально использовали, что доступно через её API, какой объём данных и истории предстоит перенести и какой из трёх сценариев — Битрикс24, amoCRM или self-hosted EspoCRM — соответствует вашему контуру. По итогам понятно, идёт речь о прямой миграции или о переезде с пересборкой процессов.

Стоимость мы называем после аудита, а не по телефону: она зависит от числа объектов и кастомных полей, состояния данных, количества интеграций и того, насколько ограничен экспорт из исходной системы. Подписка на платформу считается отдельно и по официальным тарифам вендора — например, у Битрикс24 при оплате за год это 1 743 ₽/мес за «Базовый» на 5 пользователей, 4 893 ₽/мес за «Стандартный» на 50 и 9 793 ₽/мес за «Профессиональный» на 100; работы по внедрению в эти цифры не входят. У self-hosted EspoCRM платы за места нет вовсе — платите за сервер и за работы.

На аудите мы говорим и обратное, если так и есть: что переезд вам сейчас не нужен, что часть задач вы закроете своими силами, что выбранная система избыточна для вашего отдела продаж. Импортозамещение CRM — это проект про сохранность вашей клиентской базы и управляемость процессов, а не про смену логотипа в интерфейсе.