Переезд сервиса с конструктора

Задача

Подписочный онлайн-сервис работал на связке «конструктор ботов + чужая панель доступа». Владелец не контролировал ничего: даты окончания подписок жили в переменных конструктора и вычитывались только через его API, доступы клиентов лежали в чужой панели, тарифы и сценарии поддержки ограничивались тем, что конструктор умеет.

Задача — переехать на собственную платформу так, чтобы клиенты не заметили переезда: ни переустановок, ни писем «всё сломалось, настройте заново».

Решение

• Сведение двух источников в одну базу. Даты подписок выгружены из конструктора по API, доступы и квоты — из чужой панели; сведены в таблицу переезда с проверкой каждой строки до включения.
• Бесшовность важнее скорости: доступы клиентов переносятся в исходном виде, поэтому конфигурации на устройствах продолжают работать без единого действия от человека. Перелив идёт по сегментам с канареечной группой и реестром — каждый шаг обратим.
• Поддержка как часть платформы, а не чат «куда писать»: отдельный бот поддержки с передачей обращений в тему с полным контекстом — включая пересланные сообщения, медиа и реакции — чтобы отвечать по сути, а не по пересказу.
• Мониторинг с первого дня, до того как что-то сломается: метрики и логи всех узлов в одной системе с оповещениями, состояние сервиса видно владельцу без запросов к разработчику.
• Задел под рост: новые узлы добавляются конфигурацией, а не переделкой; платформа поднята по образцу другой инфраструктуры того же владельца — проверенные решения, не эксперименты на клиентах.

Результат

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

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