Переезд без остановки работы: 12 OTA-обновлений на 5 млн пользователей и цена старой платформы

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

Ночь переключения TeamReach

В блоге Expo 14 октября вышел рассказ Джина Корнфилда, президента TeamReach. Это приложение для расписаний и чатов спортивных команд, около 5 миллионов пользователей в год. В марте 2026 года его купили новые владельцы и получили два отдельных нативных приложения, а под ними PHP на MariaDB без миграций и одна таблица на 100 миллиардов строк. Любое исправление шло через проверку в магазинах приложений, и это, по словам автора, заставило искать другой путь.

Команда из четырёх человек переписала приложение на Expo примерно за три месяца и заодно перевела базу на Postgres. Переключили всех ночью 28 июня, и сообщения об ошибках пошли через минуты. За первые четыре часа вышло три OTA-обновления, дальше три дня в ритме «полдень и полночь». Всего двенадцать обновлений, и всё, что ломало работу, по словам автора, исправили в течение суток. Обошлись эти три дня примерно в 4000 долларов.

OTA-обновление меняет только верхний слой, JavaScript и стили; всё, что трогает нативный код, по-прежнему идёт через проверку магазина. И публикация не равна доставке: приложение забирает обновление при запуске, поэтому у TeamReach исправление доходило до всех примерно за сутки, по мере того как люди открывали приложение.

Цена жизни на старой платформе

Camunda 22 октября написала про стоимость жизни на Pega. Это текст вендора, который зовёт переезжать к себе, но аргумент там честный: лицензия редко бывает самой дорогой частью. Дороже обходятся специалисты, которые знают платформу, и услуги под каждое простое изменение. К третьему-четвёртому году каждая интеграция добавляет причину не уезжать. Переезд блокируют два страха: платить за две платформы одновременно и отсутствие владельца миграции с понятным сроком.

CustomerThink 13 октября опубликовал пресс-релиз Smart Communications о миграции клиентских коммуникаций: система разбирает старые документы и превращает их в новые шаблоны, а каждую конверсию проверяют люди. В релизе приводят данные IDC: 57 % организаций держат клиентские коммуникации на устаревших системах.

В блоге Twilio 16 октября собрали пять примеров руководителей, которые обновили клиентский сервис, не меняя стек. Sweetwater оставила свою CRM и встроила в неё голос и SMS: 50 000 сообщений и 40 000 звонков в день, а новые конфигурации контакт-центра разворачиваются меньше чем за два дня. Мысль автора: если новый слой не работает, системы под ним продолжают работать, а проект замены упирается в стену на девятом месяце, когда бюджет уже потрачен.

Зачем это бизнесу

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

Как я переводил компании на новые системы

В компании в сфере PDR в США, где я технический партнёр с 2021 года, переезд шёл несколько лет, шаг за шагом, и каждый следующий шаг опирался на то, что уже работало. В 2021 году данные жили в Google Таблицах и приложениях на AppSheet. В 2023 году я предложил перейти на SQL-базу ради скорости и единого формата данных. Идею поддержали, и после перехода на MariaDB мы подключали новые сервисы один за другим, а интеграцию с GoHighLevel я дорабатывал весь год. Сейчас GoHighLevel из основной CRM стал вспомогательной, а на смену AppSheet приходит суперапп на React Native, который мы делаем вместе с разработчиками компании: он в TestFlight, им уже пользуются офис и продавцы. Каждую новую часть мы включали рядом с работающей, а старую отключали после.

В «Кофе вместе» в октябре 2026 года переезд был меньше, а правило то же. Часть сотрудников ещё заказывала через Google Таблицу, поэтому я сделал импорт с предварительным просмотром: каждая строка проверяется, ошибка блокирует перенос, похожий товар не подставляется. Журнал импорта связывает заказ с номером исходной строки, поэтому повторная загрузка не создаёт дубликатов, а изменённую строку сервис показывает как конфликт.

Что я бы сделал

Назовите владельца переезда и дату. У TeamReach это было 28 июня; без даты миграция лежит в планах годами, как пишет Camunda.

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

Готовьте людей к первым суткам. В TeamReach сотрудник поддержки сидел в тикетах 36 часов и группировал жалобы для инженеров. Назначьте такого человека заранее.

Если менять платформу целиком страшно, начните со слоя сверху. В прокате в ЮАР у меня всё выросло из связки AmoCRM с таблицей.

О признаках, по которым пора уходить из таблиц: когда бизнесу нужна система вместо таблиц. По направлениям: бизнес как единая система и автоматизация процесса от заявки до следующего действия. Кейсы: технический партнёр PDR-компании в США и «Кофе вместе». По той же теме: ежегодный цикл обновлений приложения и версии API и даты отключения; раньше я писал, что сохранять при смене платформы и как проверить данные при миграции CRM. Если вам предстоит переезд, расскажите, что работает сейчас и что нельзя останавливать: Обсудить задачу.