Как распознать замкнутость
Замкнутость не видна при покупке — она проявляется только тогда, когда вы решаете уйти. Четыре объективных признака, не зависящих от заявленной цены:
- Полный экспорт данных невозможен, или экспорт охватывает лишь часть информации (нет вложений, нет истории изменений, нет пользовательских полей).
- Цена растёт пропорционально реальному использованию (за пользователя, за объём данных, за модуль), а не воспринимаемой ценности — инструмент наказывает рост, который должен был поддерживать.
- Функции, которые вы уже использовали, внезапно перемещаются в платные тарифы при пересмотре ценовой политики — хотя ваш способ работы не изменился.
- На вопрос «а что будет, если вы закроетесь или завтра измените политику?» нет чёткого и обнадёживающего ответа — потому что договор ничего не гарантирует в этом плане.
Что действительно мешает уйти — и что не должно
Две вещи делают миграцию дорогостоящей, но только одна из них оправдана. Оправданный расход — это воссоздание рабочего процесса, отточенного годами практической эксплуатации: статусов, согласований, исключений, выработанных на практике. Такая работа имеет реальную ценность и требует времени — вне зависимости от выбранной новой платформы.
Неоправданный расход — проприетарный формат данных, намеренно урезанный экспорт, служба поддержки, которая тормозит запрос на расторжение договора. Это не техническая сложность, а коммерческое сопротивление, маскирующееся под техническое ограничение. Умение отличить одно от другого помогает не отказаться от ухода по поводу, который на самом деле не является препятствием.
Метод ухода без «большого взрыва»
Миграция начинается со структуры — никогда с «сырых» данных. Шаг 1: опишите свой бизнес ТАКИМ, КАК ОН ЕСТЬ СЕГОДНЯ, а не так, как старая система приучила вас его вводить. Эти два описания часто расходятся: жёсткий инструмент заставляет обходить собственные ограничения — например, через универсальные текстовые поля или статусы, используемые не по назначению. Сейчас важно описать бизнес-процесс, а не интерфейс старой системы.
Шаг 2: сгенерируйте приложение (для этой проверки достаточно уровня Sketch — он бесплатен в тарифе Découverte) и протестируйте его на трёх–четырёх реальных кейсах из вашей текущей недели: сложном деле, исключительной ситуации, пограничном случае, который старая система обрабатывала с трудом. Именно здесь всплывают неозвученные правила прежней системы.
Шаг 3: скорректируйте описание и перегенерируйте приложение, пока структура не станет устойчивой. Только после этого — шаг 4: переведите ТЕКУЩИЙ поток операций на новое приложение; старую систему оставьте доступной в режиме «только для чтения» на время перехода — ни одну новую запись в неё вносить не нужно.
Что не происходит автоматически: исторические данные
Будем честны: Blueprint Maker не поддерживает автоматический импорт из сторонних систем — ни один генератор принципиально не может гарантировать поддержку всех возможных проприетарных форматов. Что реально достижимо: экспортировать то, что старая система готова отдать (чаще всего — частичный CSV), использовать этот файл как эталон для проверки соответствия сгенерированной структуры реальности и заново ввести (или поручить ввод) только те данные, которые актуальны сегодня. Поскольку код — стандартный Next.js и Prisma, полностью экспортабельный, разработчик может также написать скрипт однократного импорта из этого CSV — ограниченная по времени задача, а не постоянная зависимость.
Хорошая новость: в большинстве случаев не нужна вся история. Достаточно активных записей и последних нескольких месяцев — архив остаётся доступным в старой системе в режиме «только для чтения» столько, сколько необходимо.
Ловушки выхода из замкнутости
Первая ловушка: дословное копирование экранов старой системы. Её поля и меню чаще отражают ограничения ЕЁ технологий, а не потребности вашего бизнеса — повторяя их, вы переносите замкнутость в новую среду.
Вторая ловушка: стремление импортировать 100 % исторических данных до начала перехода. Это верный путь к бесконечному откладыванию. Сначала — текущий поток, потом — архив, если он действительно нужен.
Третья ловушка: замена одной замкнутой системы на другую. Эту проблему решает полный контроль над исходным кодом: сгенерированное приложение можно экспортировать (ZIP, push в GitHub) и развернуть где угодно. Уход из Blueprint Maker в будущем будет происходить по той же логике, что и уход из старой системы сегодня — но гораздо проще.