No-code сделал свою работу. Он вывел вас на рынок за недели, подтвердил спрос без бюджета на разработку и позволял менять направление во вторник после обеда. Считать это ошибкой задним числом — ревизионизм: с той информацией, что была, решение было верным.

Ошибка — задержаться дольше того момента, когда платформа перестаёт ускорять и начинает ограничивать. Вот как распознать этот момент и как уйти, ничего не сломав.

Пять признаков

1. У производительности есть потолок, который вам не поднять. Список грузится восемь секунд, и никакая перестройка не помогает, потому что слой запросов оптимизируете не вы.
2. Клиент задаёт вопрос, на который вы не можете ответить. Где хранятся наши данные, у кого есть доступ, дадите ли журнал аудита. Если честный ответ — «мне нужно спросить платформу», у корпоративных продаж появляется жёсткий предел.
3. Кривая расходов перевернулась. Оплата за запись или за сценарий, незаметная на 500 пользователях, становится абсурдной на 50 000. Посчитайте это заранее — обычно наступает быстрее, чем кажется.
4. Нужно то, чего платформа не может выразить. Сложные права, фоновая обработка, полноценный API для партнёров или интеграция, к которой никто не сделал коннектор.
5. Менять стало рискованно. Приложение выросло в переплетение взаимозависимой логики, которую никто не понимает целиком, без тестов и контроля версий. Это тот же технический долг, что и везде, просто накопился быстрее.

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

Что реально переезжает, а что нет

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

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

Последовательность миграции

1. Полностью задокументируйте текущее поведение: каждый сценарий, каждую автоматизацию, каждое условное правило, каждую запланированную задачу. Это самая большая задача, и она не опциональна. Незадокументированная логика — единственное, что стабильно приводит к сбоям, видимым клиенту.
2. Выгрузите данные и честно их изучите. Опишите правила преобразования для всего несогласованного. Сделайте это до проектирования новой схемы: данные сами подскажут, какой она должна быть.
3. Стройте новую систему под текущее поведение, а не под его улучшенную версию. Сопротивляйтесь желанию переделать дизайн во время миграции — рисков у вас и так достаточно.
4. Запустите обе системы параллельно с односторонней синхронизацией данных и две недели пользуйтесь новой внутри команды.
5. Переводите клиентов когортами, начиная с самых маленьких и терпимых. Держите старую систему живой и доступной, пока последняя когорта не отработает стабильно месяц.
6. Только после этого выключайте — и перед выключением сделайте финальный архив.

Сколько это стоит и сколько длится

Для типичного no-code приложения с реальными клиентами закладывайте три-пять месяцев и стоимость, сопоставимую с MVP для рынка. Сильнее всего на цифру влияет не количество функций, а объём незадокументированной логики, накопленной в платформе, и чистота данных.

Лучшее, что можно сделать до старта, — задокументировать свои сценарии самостоятельно. Это стоит времени, а не денег, и убирает главный источник разброса в оценке.

Вы мигрируете не потому, что no-code был неверным выбором. Вы мигрируете потому, что он был верным выбором для этапа, который вы закончили.

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