Как перейти на другой сервис рассылок и сохранить базу, отписки и цепочки

Составьте карту действующих отправок

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

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

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

Выгрузите данные вместе со статусами

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

Для рабочего профиля могут понадобиться внешний ID из CRM, поля персонализации, источник и время подписки, подтверждение согласия, теги, списки и события. Выгружайте только нужные данные и передавайте файлы через согласованный защищённый канал. Не размещайте клиентскую базу в общедоступной таблице ради удобства обмена.

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

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

Проверьте пробный импорт

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

1. Сопоставьте поля и типы: дату, число, строку, несколько значений. Проверьте кодировку и разделители файла.
2. Настройте исключения так, чтобы импорт не активировал отказавшихся. Порядок загрузки согласуйте с новой платформой.
3. Сравните количество профилей и распределение по статусам. Проверьте несколько конкретных адресов вручную.
4. Повторно импортируйте тот же образец. Убедитесь, что он обновляет ожидаемые поля и не создаёт лишних профилей или повторных входов в цепочки.

Не копируйте названия статусов механически. «Активный» в одной системе может означать возможность отправки, а в другой — последнее действие человека. Например, официальный порядок перехода в Sendsay отдельно рассматривает импорт, подтверждение подписки, домен и шаблоны. Это полезная проверка состава работ; точные действия должны соответствовать выбранной платформе.

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

Подготовьте домен и ссылки

Новая платформа должна подтвердить право отправки от вашего домена. Получите у неё актуальные записи DNS и проверьте, кто управляет зоной. Пароль от почтового ящика и доступ к настройкам DNS — разные вещи.

Согласуйте SPF с учётом всех действующих отправителей. Не добавляйте вторую конкурирующую SPF-запись вместо изменения существующей. Для DKIM следуйте инструкции по селектору новой платформы; старые записи не удаляйте, пока они нужны оставшимся отправителям и сообщениям в пути. Проверка DMARC требует согласованности домена отправителя с механизмом аутентификации, а не просто наличия трёх записей.

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

Отдельно обсудите, сколько будут работать прежние страницы отписки, веб-версии и ссылки отслеживания. До прекращения доступа выясните, как отказ по старому письму попадёт в актуальный список исключений.

Пересоберите письма и автоматизацию

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

Цепочки удобно принимать по таблице «событие → получатель → письмо → задержка → выход». Для каждого условия найдите соответствующее событие или поле в новой системе. Если точного аналога нет, согласуйте новое поведение до запуска, а не пытайтесь угадать его по похожему названию.

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

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

1. Зафиксируйте момент переключения и выгрузите изменения, появившиеся после основного переноса: новые подписки, отписки и обновления профилей.
2. Переведите источники данных на новую сторону и проверьте каждый из них реальным тестовым действием.
3. Остановите старые запланированные кампании и правила, которые не должны работать параллельно. Исключения для завершаемых цепочек запишите отдельно.
4. Проведите тестовую отправку с рабочими настройками домена. Проверьте доставку, ссылки, персонализацию, ответ и отписку.
5. Запустите согласованную ограниченную отправку и посмотрите причины отказов, жалобы и действия получателей до масштабирования.

Выделенный IP, общий пул и новая инфраструктура могут потребовать разного порядка наращивания отправок. Не обещайте себе прежнюю доставляемость только потому, что домен остался тем же. Попросите новую платформу согласовать старт с учётом истории базы и объёма; универсального числа писем «для прогрева» на любой случай нет.

Когда остановить переход и как вернуться

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

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

До перехода сохраните доступ к старой платформе и её настройки, но не оставляйте бесконтрольные параллельные отправки. План возврата должен называть ответственного, нужные файлы и действия для каждого источника данных.

Что сохранить после переезда

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

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

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