Миграция с SaaS CDP на on-prem: план и подводные камни

«Миграция с SaaS на on-prem — это просто перенос базы данных». Если вы слышали это утверждение — забудьте. Перенос данных составляет 15-20% работы. Остальные 80% — это перестройка интеграций, пересборка триггерных сценариев, переключение коммуникационных каналов и обучение команды. Компании, которые недооценивают организационную сторону миграции, застревают на полпути — одна нога в SaaS, другая в on-prem.

Этот материал — пошаговый план миграции с SaaS CDP на on-prem контур, основанный на реальных enterprise-проектах. Покажем фазы, сроки, 5 подводных камней и ситуации, когда мигрировать не стоит.

Зачем enterprise уходит с SaaS CDP

Прежде чем разбирать «как», стоит зафиксировать «зачем». Миграция с SaaS на on-prem — дорогой и сложный проект. Компании идут на это не из любви к серверам, а по конкретным причинам:

• Регуляторные требования. 152-ФЗ, требования ЦБ, PCI DSS — облачный провайдер не всегда может подтвердить соответствие. Особенно если серверы мигрируют между дата-центрами
• Vendor lock-in. Зависимость от дорожной карты SaaS-провайдера, проприетарных форматов данных, ценовой политики. Подробнее — в материале Vendor lock-in в CDP
• Санкционные риски. Западный SaaS может отключить аккаунт. Это не теоретический риск — десятки компаний столкнулись с этим в 2022-2023 годах
• TCO при масштабировании. SaaS тарифицирует по MAU — при росте базы стоимость растёт пропорционально. On-prem — фиксированная лицензия. Расчёт TCO — в материале TCO on-prem vs SaaS
• Контроль над данными. Полное владение данными, ключами шифрования, политиками retention без зависимости от внешней стороны

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

План миграции: 5 фаз

Оптимальная стратегия — параллельная миграция: новая on-prem платформа запускается рядом со старой SaaS, данные и процессы переносятся поэтапно, старая система отключается только после полной валидации.

Фаза 1. Аудит текущего состояния (2-3 недели)

Прежде чем мигрировать — нужно понять, что именно вы мигрируете. Аудит включает:

• Карта данных: какие данные хранятся, в каких полях, какой объём (профили, события, согласия)
• Интеграционный ландшафт: список всех систем, подключённых к SaaS CDP (CRM, сайт, приложение, email-сервис, контакт-центр)
• Бизнес-логика: триггерные сценарии, правила сегментации, шаблоны коммуникаций, автоматизации
• Пользователи и роли: кто работает с платформой, какие права, какие процессы

Результат аудита — документ, который станет техническим заданием для миграции. Без него оценка сроков и стоимости — гадание.

Фаза 2. Развёртывание on-prem и перенос данных (3-6 недель)

Параллельно с работающим SaaS разворачивается on-prem контур. Первый шаг — перенос данных:

• Экспорт профилей, событий, согласий из SaaS (API или bulk export)
• Маппинг полей: поля в SaaS и on-prem не всегда совпадают 1:1
• Трансформация данных: нормализация телефонов, адресов, дедупликация
• Загрузка в on-prem CDP с валидацией (счётчики, контрольные суммы)

На этом этапе обе системы работают параллельно. Новые данные поступают в SaaS (она по-прежнему «боевая»), а on-prem получает копию для проверки.

Фаза 3. Пересборка сценариев и интеграций (4-8 недель)

Самая трудоёмкая фаза. Каждый триггерный сценарий, каждое правило сегментации, каждый коннектор нужно воссоздать на on-prem платформе.

Интеграции — главный источник задержек. Каждая внешняя система (сайт, приложение, 1С, контакт-центр) подключена к SaaS через специфический коннектор. Переключение на on-prem API требует доработки на стороне каждой интегрируемой системы.

Фаза 4. Параллельная работа и валидация (2-4 недели)

Обе системы работают одновременно. Новые данные поступают в обе. Задача — убедиться, что on-prem выдаёт те же результаты:

• Сегменты совпадают по составу
• Триггеры срабатывают корректно
• Коммуникации отправляются вовремя
• RBAC и audit trail работают
• Производительность под нагрузкой соответствует ожиданиям

Продолжительность фазы зависит от уровня критичности. Для финсектора — минимум 4 недели. Для retail — 2 недели обычно достаточно.

Фаза 5. Переключение и вывод SaaS (1-2 недели)

Финальное переключение: все интеграции указывают на on-prem, SaaS отключается от приёма новых данных. Важно:

• Сохранить экспорт из SaaS как архив (минимум 6 месяцев)
• Уведомить SaaS-провайдера о завершении подписки после успешного переключения, не до
• Проверить, что все данные из SaaS удалены (требование 152-ФЗ при смене оператора)

5 подводных камней миграции

Вопреки ожиданиям, 70% проблем при миграции с SaaS на on-prem — организационные, не технические. Вот пять самых частых:

1. Неполный экспорт данных

SaaS-провайдер предоставляет экспорт профилей, но «забывает» историю событий, логи согласий или метаданные сегментов. Решение: составить полный перечень данных до начала миграции и проверить возможность экспорта каждого типа. Если API не покрывает — запросить bulk export у поддержки.

2. Потеря бизнес-логики

Триггерные сценарии в SaaS часто используют проприетарные функции, которых нет в on-prem. Пример: специфический scoring-алгоритм или встроенный ML-предиктор. Решение: в фазе аудита классифицировать каждый сценарий как «переносимый 1:1», «требует адаптации» или «нужна замена».

3. Интеграционный паралич

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

4. Команда не готова

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

5. Compliance-пауза

В период миграции возникает «серая зона»: данные частично в SaaS, частично в on-prem. Кто оператор? Где актуальная версия согласий? Решение: юридически зафиксировать, что SaaS остаётся оператором до момента полного переключения, on-prem — тестовая среда. Переход ответственности — одномоментный.

Когда мигрировать не стоит

Честный ответ: миграция с SaaS на on-prem — не для всех. Три ситуации, когда SaaS достаточно:

• Клиентская база менее 30K. Затраты на on-prem не окупаются при малом объёме данных
• Нет ИТ-команды для эксплуатации. On-prem требует минимум 1-2 инженеров для сопровождения — если их нет и нанимать не планируете, SaaS проще
• Регуляторные требования не критичны. Если вы не обрабатываете чувствительные данные и 152-ФЗ не является фокусом — облако может быть оптимальным выбором

Во всех остальных случаях — особенно при базе 50K+, наличии регуляторных требований и растущем TCO — миграция экономически обоснована. Подробнее — на главной странице On-prem CDP для enterprise.

Итого

Миграция с SaaS на on-prem — не «проект на выходные», а стратегическое решение, которое требует 3-9 месяцев и затрагивает данные, интеграции, процессы и людей. Однако при правильном планировании риски минимизируются: параллельная работа исключает потерю данных, поэтапное переключение снижает операционный риск, а результат — полный контроль над клиентским контуром.

Ключевой вывод: vendor lock-in дорожает с каждым годом. Чем дольше вы на SaaS, тем больше процессов привязано к проприетарным функциям и тем сложнее уход. Если миграция в планах — лучше начать аудит сейчас, а не когда SaaS-провайдер повысит цены или отключит аккаунт.

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