Миграция SMS-панели: с SaaS на собственный сервер, шаг за шагом

Уход с арендованной SMS-панели представляет собой проект с заранее известной структурой. Сбои всегда случаются в одних и тех же местах: имя отправителя, зарегистрированное на поставщика, хост API, жёстко прописанный в коде ваших клиентов, журнал операций, который не выгружается, переключение, проведённое в пятницу. Это чек-лист миграции SMS-панели, по которому мы переводим реселлера на его собственную платформу; он написан так, чтобы вы могли пройти его с любой платформой на собственном сервере. Он описывает переход с SaaS-панели на собственный сервер в семь этапов: инвентаризация, выгрузки, новая платформа, то, что не переносится, параллельная работа, переключение и отключение старой панели. Вопросу, стоит ли уходить, посвящено сравнение с SaaS-панелями; это руководство о том, как уйти.

Этап 0: стройте график по самому медленному пункту

Прежде чем трогать данные, перечислите всё, что идёт в чужие сроки. Перерегистрация имён отправителей и коротких номеров на ваше собственное юрлицо, регистрации у регуляторов (DLT в Индии, 10DLC в США и их аналоги), одобрение операторами ваших собственных SMPP-подключений (bind), а если вы добавляете WhatsApp, то и верификация компании в Meta. Каждый из этих пунктов занимает недели, а не дни, и ни один нельзя начать слишком рано. Запустите их все в первую же неделю, параллельно со всем, что описано ниже, и тогда остальная часть миграции закончится раньше и будет ждать их, а не наоборот.

Этап 1: инвентаризация перед миграцией SMS-панели

Выпишите из консоли администратора панели по одной строке на каждый пункт:

• Клиенты: каждый аккаунт, его режим биллинга (предоплаченный баланс, кошелёк, постоплата), текущий баланс, тарифный план, контактное лицо и способ интеграции: через консоль, HTTP API или SMPP-подключение (bind).
• Тарифные планы и маршруты: каждый ценовой план, каждая строка направления, каждый маршрут поставщика с его учётными данными и себестоимостью.
• Имена отправителей и номера: буквенно-цифровые имена, длинные номера, короткие номера, а также на чьё юрлицо каждый из них зарегистрирован у каждого оператора.
• Интеграции: каждый хост, к которому обращаются ваши клиенты (API, адрес панели, адреса вебхуков, на которые они получают отчёты о доставке), и находится ли он на вашем домене или на домене поставщика.
• Объёмы данных: контакты, шаблоны, история рассылок, журналы доставки, счета, по месяцам.
• Договоры: срок уведомления о расторжении договора с панелью и каждый договор с клиентом, в котором упоминается название или URL панели.

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

Этап 2: получите настоящие выгрузки, пока вы ещё клиент

Запросите выгрузки сейчас, до того как направите уведомление об уходе: пока вы платите, вам отвечают охотнее. Запросите каждый пункт инвентаризации в машиночитаемом формате (CSV подойдёт) и откройте каждый файл: сверьте число строк с консолью, убедитесь, что записи о согласиях идут вместе с контактами, проверьте, что журналы доставки содержат идентификатор сообщения и окончательный статус, а не только общее количество. Фразы «мы поддерживаем экспорт в CSV» и «в файле есть всё, что понадобится моим клиентам» означают разные вещи.

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

Этап 3: разверните новую платформу на собственном домене

Установите платформу на свой сервер и на свой домен до того, как переедет хотя бы один клиент. С этого дня действуют два правила из сравнительного руководства: панель и API работают на хостах, которыми владеете вы (panel.yourcompany.com, api.yourcompany.com), а имена отправителей и регистрации у регуляторов оформляются на ваше юрлицо везде, где это допускает регулятор. Затем:

1. Подключите собственные договоры с операторами как маршруты поставщиков и проверьте каждый на реальных телефонах в каждом направлении, прежде чем по нему пойдёт хоть какой-то клиентский трафик.
2. Восстановите тарифные планы по выгрузке, по направлениям и по уровням клиентов, и задайте нижний порог маржи для каждой строки (руководство по биллингу объясняет три режима биллинга и то, почему режим выбирается при создании аккаунта и затем фиксируется, поэтому определитесь с ним сейчас).
3. Создайте клиентские аккаунты с нужным режимом биллинга, тарифным планом, именами отправителей и контактами, но с отключённой отправкой и нулевыми балансами до переключения.
4. Импортируйте контакты, записи о согласиях и шаблоны. Совет для бизнеса, который мы даём каждому покупателю: импортируйте записи о согласиях (opt-in) вместе с контактами. Так вы с первого дня соблюдаете требования и не восстанавливаете согласия задним числом.
5. Импортируйте историю, если это возможно. Историю рассылок и журналы доставки стоит перенести, чтобы у клиентов сохранились их отчёты; в Smppcube именно в этом разница между «Стандартным импортом» (контакты, шаблоны, настройки отправителей и маршрутов) и «Полной миграцией» (всё перечисленное плюс история отправок, рассылки и данные биллинга) на странице цен.
6. Настройте SMPP-сервер для клиентов, которые подключаются по bind: учётные данные для каждого аккаунта, лимиты пропускной способности и белые списки IP-адресов должны быть готовы к выдаче; в Smppcube SMPP-сервер и HTTP API входят в платформу, а не продаются как дополнение.

Этап 4: то, что не переносится

Четырём вещам нужен отдельный план, потому что ни одна выгрузка их не переносит.

Хост API. Если ваши клиенты обращаются к api.vendor.com, либо их код должен измениться, либо на том же интерфейсе должно отвечать что-то другое. Лучший вариант: слой совместимости на вашей платформе, который принимает запросы в старом формате и преобразует их в вызовы нового API. Тогда интеграция клиента продолжает работать в день, когда переезжает его трафик, а на ваш основной API он может перейти в удобном для себя темпе. Если старый хост принадлежит поставщику, забрать его с собой нельзя, поэтому слой совместимости работает на вашем хосте, и каждый клиент меняет одну строку: адрес хоста.

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

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

SMPP-подключения (bind). Каждому клиенту, который подключается по bind, нужны новые хост, порт, system_id, пароль, разрешённые IP-адреса и лимит пропускной способности, а также окно для проверки на вашем тестовом маршруте до переезда его рабочего трафика. Отправьте все учётные данные одним документом и назначьте 30-минутный тест с инженером клиента.

Миграция срывается на том, что никто не выгрузил, а не на том, что выгрузили все. Хосты, вебхуки, имена отправителей и подключения (bind) и составляют план, а CSV-файлы остаются самой простой частью.

Этап 5: параллельная работа

Оставьте старую панель рабочей и оплаченной на 60-90 дней после готовности новой платформы. Первым переведите одного лояльного клиента с небольшим объёмом, в идеале того, кто скажет вам правду. Его трафик идёт через вашу платформу, ваши маршруты и ваш журнал операций; старая панель остаётся резервом. Ежедневно сверяйте отправленные сообщения, сопоставленные отчёты о доставке и движение баланса с тем, что видит клиент. Когда пройдёт неделя, за которую не возникнет ничего, требующего объяснений, переводите следующего клиента, потом ещё одного. Крупнейшего клиента переводите последним, когда все рутинные проблемы уже найдены на небольших.

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

Этап 6: переключение, клиент за клиентом

Для каждого клиента переключение представляет собой чек-лист с датой: баланс согласован письменно, имена отправителей работают на ваше юрлицо, интеграция проверена (слой совместимости API или новые учётные данные, вебхук получает отчёты о доставке, SMPP-подключение проверено на тестовом маршруте), отправка включена, первая рассылка отслежена от начала до конца, аккаунт в старой панели переведён в режим только приёма или отключён. Проводите переключение во вторник утром, когда контактное лицо клиента на связи, и никогда в пятницу.

Большая часть работы приходится на общение с клиентами. Короткое письмо каждому клиенту за месяц («мы переходим на собственную платформу; вот что для вас меняется, а вот что остаётся прежним»), напоминание за неделю с его конкретной датой и подтверждение в день переключения. Клиенты уходят из-за неожиданностей, а не из-за перемен.

Этап 7: правильно отключите старую панель

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

Во что это обходится и что это даёт

Закладывайте бюджет на миграцию честно: от двух до шести недель календарного времени, большая часть которых уходит на ожидание операторов, плюс 60-90 дней двойной оплаты, плюс стоимость импорта на новой платформе. При объёмах, на которых уход оправдан, эта сумма меньше, чем плата за каждое сообщение, которую вы за один-два месяца отдаёте покидаемой платформе, и, в отличие от этой платы, вносится один раз. В Smppcube перенос пользователей, маршрутов, тарифных сеток и балансов входит в стандартный объём работ по внедрению и согласуется заранее, а цены на «Стандартный импорт» и «Полную миграцию» указаны на странице цен, а не появляются неожиданно в коммерческом предложении. Какую бы платформу вы ни выбрали, дешёвым уход делают те же два правила, которые стоило соблюдать с первого дня: ваш домен и ваши регистрации.