Чем заменить Zapier и Make в России: 4 варианта и цены

Замена начинается не с выбора платформы, а с инвентаризации, и она же приносит первую экономию. В модельной компании с 34 сценариями на Zapier и Make двенадцать штук — 35 % парка — выключаются без последствий: дубли, автоматизация отменённых процессов, отчёты, которые никто не открывал полгода. Переносить надо 22 сценария, и это меняет смету переезда почти вдвое ещё до того, как выбрана новая площадка.

Рабочих вариантов замены четыре: российская облачная платформа (Albato, ApiX-Drive, Nodul), n8n на собственном сервере, собственный сервис интеграций и штатная функция уже купленной системы. Zapier и Make (ранее Integromat) в этот список не входят: по состоянию на сентябрь 2026 года оплата и поддержка для российских компаний недоступны, и держать на них процессы — значит ждать дня, когда сценарии остановятся без предупреждения.

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

День первый: инвентаризация

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

1. 1
   Что сценарий делает и кто его владелец

   Одна строка по существу: «письмо на общий ящик превращается в сделку». Если ни один сотрудник не может объяснить назначение сценария, он идёт не в перенос, а в карантин.

2. 2
   Чем запускается

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

3. 3
   Какие системы трогает и с какими правами

   Список подключений с указанием учётной записи. Здесь обычно и находятся ключи API уволенных сотрудников и подключения к сервисам, которыми компания больше не пользуется.

4. 4
   Сколько прогонов и операций в месяц

   Число из статистики платформы, а не из памяти. По этому столбцу считается будущий счёт и выбирается между облаком и своим сервером.

5. 5
   Когда последний раз срабатывал и приносил пользу

   Сценарий, у которого за 90 дней ноль полезных прогонов или чьи отчёты никто не открывал, — кандидат на отключение. Именно этот столбец даёт треть экономии.

6. 6
   Что сломается, если его выключить

   Одна строка последствий. Если ответить не может никто, это не значит, что последствий нет: это значит, что нужен карантин на 30 дней с наблюдением, а не мгновенное удаление.

Почему треть сценариев можно просто выключить

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

Четыре варианта замены

Дальше считаем на модельных вводных: 22 сценария к переносу, 64 000 операций в месяц, внутренний час сотрудника 1 100 ₽, час инженера подрядчика 3 500 ₽, модельная цена операции в облаке 0,15 ₽ (по массовым тарифам российских площадок вилка укладывается в 0,10–0,25 ₽ и зависит от объёма).

Годовые цифры в таблице раскладываются так. У облачной платформы это 115 200 ₽ операций (64 000 × 0,15 ₽ × 12) плюс 132 000 ₽ часов внутреннего владельца сценариев (10 часов в месяц × 1 100 ₽ × 12). У своей установки n8n — те же 132 000 ₽ часов владельца плюс 216 200 ₽ на инфраструктуру и администрирование: сервер 54 000 ₽, база 36 000 ₽, бэкапы 7 200 ₽, мониторинг 12 000 ₽, домен и сертификат 2 000 ₽ и 30 часов администрирования по 3 500 ₽. У собственного сервиса — 18 000 ₽ хостинга, 180 000 ₽ сопровождения и 52 800 ₽ часов владельца, которых нужно меньше, потому что править нечего без разработчика.

Четвёртый вариант — самый недооценённый и почти никогда не встречается в статьях, потому что на нём нечего продать. Цифры в его строке относятся к этим четырём-шести сценариям, а не ко всему парку: закрыть штатной функцией системы весь парк из 22 сценариев не выйдет ни у кого. Часть сценариев на Zapier и Make появилась в те годы, когда в CRM или учётной системе нужной функции не было, а сейчас она есть: рассылка по сегменту, постановка задачи по событию сделки, обмен с сайтом штатным механизмом. Такие сценарии не надо переносить никуда — их надо выключить и включить штатную настройку. В модельном парке это 4–6 сценариев из 22, то есть до четверти работы, которую можно не делать.

Шесть часов на сценарий — средняя величина, и разброс за ней большой: простая связка «форма на сайте → задача в CRM» пересобирается за 2–3 часа, а сценарий с ветвлениями, хранением состояния и обработкой вложений занимает 12–16. Поэтому при планировании имеет смысл разделить парк на три группы по сложности и посчитать каждую отдельно — иначе смета окажется точной в среднем и неверной в частностях. И требуйте от подрядчика смету именно в таком виде: единая цифра «перенос интеграций под ключ» скрывает всё, что потом станет предметом спора. Как проверять исполнителя на такой работе, мы разбирали в отдельном материале о выборе подрядчика.

Платформы по инженерным критериям

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

Ограничения, которых нет в вендорских обзорах, стоит знать до подписания. У n8n на своём сервере их три: нужен администратор и дежурство, обновления и их совместимость со сценариями — ваша ответственность, коннекторов к российским системам почти нет. У облачных платформ ограничение общее и главное: через них проходят персональные данные клиентов, поэтому нужны договор, поручение обработки и понимание, что и на какой срок остаётся в логах прогонов. Второе общее — переносимого формата сценария между платформами не существует, и следующий переезд снова будет стоить пересборки. Третье — глубина логики: там, где на своём сервере пишут двадцать строк кода, в облачном конструкторе придётся собрать десяток узлов или отказаться от задачи. Частности тоже важны: Albato сильна коннекторами, но её тарификация по операциям означает, что рост потока автоматически увеличивает счёт; ApiX-Drive удобна для простых связок и присутствует в реестре Минцифры, но сложные ветвления на ней делать неудобно; Nodul моложе аналогов, поэтому набор коннекторов и объём публичных материалов меньше.

Что не переносится автоматически

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

• Вебхуки. Адрес приёмника меняется, а значит у каждого источника — сайта, формы, платёжного сервиса, чужой системы — новый адрес надо прописать отдельно. Это не работа программиста, но это доступы и согласования, и именно здесь переезд обычно застревает на неделю.
• Авторизации. Токены и подключения выпускаются заново, часть требует участия владельца аккаунта или доступа к почте, на которую они оформлены. Заранее составьте список: какая система, чья учётная запись, кто может подтвердить.
• Хранилища состояния. Таблицы обработанного, счётчики, списки «кому уже отправляли» живут внутри платформы и при переезде исчезают. Если их не перенести, первый же прогон на новой площадке разошлёт повторные письма по всей базе.
• Отложенные задачи. Всё, что запланировано внутри старой платформы на будущее — напоминания, отложенные отправки, задержки в середине сценария, — при отключении просто не наступит. Их надо выявить и переназначить.
• Расписания и часовые пояса. Формат времени, признак рабочего дня, поведение в выходные у платформ различаются. Классический результат невнимательности — письма клиентам в субботу в 03:40.
• Форматы дат и чисел. Разделитель дробной части, порядок дня и месяца, представление пустого значения. Сценарий отработает без ошибки и запишет неверные данные — самый дорогой тип сбоя, потому что обнаруживается он на отчётности.

Порядок миграции без остановки процессов

Ключевое правило одно: старый контур не выключается, пока новый не сверен. Отсюда весь порядок — сначала параллельная работа в безопасном режиме, потом переключение источников по одному, и только затем отключение.

1. 1Неделя 1. Инвентаризация, отключение явно мёртвых сценариев, карантин для тех, чьё назначение неизвестно. Одновременно составляется список авторизаций с указанием, чья учётная запись и кто подтверждает.
2. 2Неделя 1–2. Выбор площадки и подготовка контура: подключение либо установка на сервер, учётные записи, права, мониторинг, канал алертов и дежурный, который на них реагирует.
3. 3Неделя 2–5. Пересборка по одному, начиная с самых простых сценариев. Простые дают быстрый результат и вскрывают все различия платформ на дешёвом материале, а не на критичном процессе.
4. 4Неделя 3–6. Параллельный прогон в режиме сухого: новый сценарий проходит весь путь, но вместо записи в системы складывает результат в журнал. Результаты сверяются построчно со старым контуром.
5. 5Неделя 5–7. Переключение источников по одному: вебхук переводится на новый адрес, старый сценарий останавливается, сутки наблюдения. Групповое переключение всех источников за один вечер — самая частая причина затяжного инцидента.
6. 6Неделя 7–8. Отключение старой платформы. Аккаунт при этом не удаляется сразу: сначала выгружаются экспорты всех сценариев и история прогонов за последний месяц — они пригодятся при разборе первых расхождений.

Арифметика здесь важнее вывода, потому что вывод зависит от вашего объёма. Расходы своей установки почти не меняются с потоком: сервер и администратор стоят одинаково при 64 000 и при 200 000 операций — 216 200 ₽ в год плюс часы владельца сценариев. Расходы облака растут линейно. Точка равенства при цене 0,15 ₽ за операцию лежит около 120 000 операций в месяц: ниже дешевле облако, выше — свой сервер. При 64 000 операций облако дешевле на 101 000 ₽ в год, и выбирать своё железо в этой точке стоит по юридическим причинам, а не по финансовым. Это честнее, чем формулировка «свой сервер всегда выгоднее», которую обычно приводят там, где продают внедрение.

Чек-лист приёмки перенесённого сценария

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

1. 1Сверка на реальных данных: за период параллельного прогона старый и новый контуры дали одинаковый результат построчно, а не «в целом похоже».
2. 2Идемпотентный ключ назван конкретным полем, и повторный запуск на той же записи не создаёт вторую сделку, вторую задачу и второе письмо.
3. 3Проверено поведение при недоступности каждой внешней системы: сценарий копит в очередь, пропускает или останавливается — и это поведение выбрано осознанно.
4. 4Настроены ретраи с задержкой, и число попыток такое, что при длительном сбое чужого сервиса вы не получите лавину дублей.
5. 5Есть очередь необработанного и ежедневная сводка: сколько записей не прошло и по какой причине.
6. 6Алерт о сбое приходит конкретному человеку в канал, который он читает, и назначен тот, кто обязан отреагировать в тот же день.
7. 7Форматы проверены на краевых значениях: пустое поле, длинный текст, дробное число, дата на границе месяца, телефон в непривычной записи.
8. 8Расписание проверено с учётом часового пояса и выходных: ни одно клиентское сообщение не уходит ночью или в субботу.
9. 9Доступы оформлены на учётные записи компании, а не сотрудника, и записаны в реестр вместе со сроком ротации.
10. 10Есть паспорт сценария на полстраницы: что делает, какие системы трогает, кто владелец, что сломается при отключении. Без этого пункта сценарий через год снова станет призраком.

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

Когда переносить не надо: low-code не подходит категорически

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

• Сценарий отправляет платёжные поручения, списывает остатки или совершает иные необратимые действия без участия человека. Конструктор выполняет шаги по очереди и не откатывает уже сделанное: сбой в середине оставляет систему в состоянии, которого нет ни в одном регламенте. Такие шаги переносят в учётную систему или в сервис, а на конструкторе оставляют только уведомление.
• От сценария требуется доказуемый след для проверяющего. История прогонов на платформе хранится ограниченный срок и не проектировалась как доказательство. Нужен собственный журнал с регламентом хранения — и его лучше завести в момент переезда, а не после первого запроса.
• Через сценарий идут персональные данные особых категорий: сведения о здоровье, биометрия, паспортные данные в теле запроса. Через облачный конструктор такие поля не пропускают; передают ссылку на защищённое хранилище, а сопоставление делают в своём контуре.
• Сценарий обрабатывает больше 500 записей за прогон или файлы тяжелее 15 МБ. На старой платформе это, скорее всего, уже работало плохо и требовало ручных перезапусков. Переносить такой сценарий один в один — значит переносить и проблему; правильный ход — вынести обработку в отдельный сервис, а маршрут оставить в конструкторе.
• Сценарию некому быть владельцем. Если после переезда парком снова никто не занимается, через год вы получите тот же клубок из 34 штук, только на другой площадке. Тридцать сценариев требуют около 14 часов в месяц — либо эти часы у кого-то есть, либо поддержку берёт подрядчик, либо часть автоматизации честнее не делать.

И последнее, что стоит сделать один раз и не повторять этот проект через два года. Zapier и Make стали недоступны не из-за технической аварии, и следующая смена площадки тоже не будет технической. Значит, привязку к платформе надо снижать заранее: выгружать сценарии в свой репозиторий раз в сутки, держать журнал обработанного на своей стороне, а бизнес-логику, которая дороже всего в пересборке, выносить в собственный небольшой сервис. Три этих приёма добавляют к проекту примерно 10 % бюджета и превращают следующий переезд из восьминедельного проекта в работу на несколько дней.

Дешевле всего переносится тот сценарий, который вы решили не переносить.