Легаси: переписывать или дотягивать — ROI для CEO и CTO
Кабинет клиентов тормозит. 1С «кормит» сайт CSV по пятницам. Новый продукт не влезает в старую модель данных. На совещании звучит магическая фраза: «давайте перепишем с нуля». Через полгода — два контура, двойной ввод и сорванный релиз.
Легаси: переписывать или дотягивать — не спор программистов. Это решение CEO/CTO про деньги, риск и окно 6–18 месяцев. Ниже — рамка ROI и чеклист, когда нужен rewrite, а когда — рефакторинг по слоям.
Главное. Сначала зафиксируйте, какой срез реально тормозит выручку. Полный rewrite без cutover и пилота почти всегда дороже планового выноса кабинета/API рядом со старым контуром.

Сначала срез, который даёт деньги — потом «переписать всё»
Что считать легаси на языке бизнеса
Легаси — не «старый язык». Это система, которая мешает росту:
- новый канал продаж или роль клиента не влезает без костылей;
- обмен с CRM/1С — руками или ночным файлом;
- пиковая нагрузка или реклама = 503 на кабинете;
- половину спринта команда чинит обходы, а не продукт.
Если боль в Excel и «финальная_версия_3» — сначала процесс и единый кабинет, а не rewrite ради rewrite. Рамка — в «Excel больше не справляется» и MVP ЛК из 7 экранов.
Три стратегии: латать, выносить слой, rewrite
1. Дотягивать (локальные фиксы). Быстро и дёшево на горизонте недель. Работает, пока корень проблемы — баг или один экран. Не работает, если модель данных и интеграции уже потолок.
2. Рефакторинг по слоям (strangler). Рядом со старым контуром поднимаете новый срез: кабинет, API заказов, обмен с 1С. Старое остаётся, пока cutover по роли/филиалу не подтверждён. Бизнес видит ценность каждые 4–8 недель.
3. Rewrite «с нуля». Имеет смысл, когда ядро объективно мёртвое (нет тестов, нет владельца данных, нельзя безопасно менять), а оценка «латания на год» ≥ бюджету нового контура. Иначе — дорогой способ отложить решение ещё на год.
- Дотягивать — один экран/баг, бизнес не стоит
- Слой / strangler — кабинет, API, интеграция; пилот → cutover
- Rewrite — ядро блокирует рост, есть владелец scope и дата cutover
Как посчитать ROI за 12–24 месяца
Ответ сразу: сравните не «стоимость разработки», а полный TCO решения — плюс простой, двойной ввод и упущенные сделки.
- Разработка / подряд — смета rewrite vs смета среза + доработки старого.
- Операционка — часы сотрудников на обходы, CSV, ручные сверки (часто 0,5–2 FTE).
- Простой и ошибки — час недоступности кабинета/учёта; ориентир для МСБ — десятки–сотни тыс. ₽, см. стоимость часа простоя.
- Риск срыва — «большой взрыв» без пилота сдвигает выручку нового канала на квартал–два.
Rewrite выигрывает по ROI, если латание не снимает корневой тормоз (данные, интеграции, производительность) и через год вы снова на том же совещании. Иначе плановый вынос кабинета/API дешевле и быстрее даёт деньги.
Смежная ловушка масштаба на конструкторах — в No-code vs кастом: там тоже «быстрый старт» без плана выхода.
Когда rewrite почти наверняка ошибка
- Нет владельца продукта и критерия «готово» — только «переписать красиво».
- Нет инвентаря интеграций и данных (что откуда пишется).
- Cutover в пик сезона или без отката.
- Команда параллельно чинит прод и пишет «новый мир» без выделенного контура.
- Бюджет посчитан только на код, без обучения пользователей и миграции истории.
Классика провала: два года «нового» кабинета, а заказы всё ещё в старом — потому что обмен с 1С оставили «на потом».
Когда рефакторинг по слоям — правильный ход
Ответ сразу: есть узкий срез, который можно сдать за 4–12 недель и измерить (конверсия в кабинете, время обмена, доля ручных правок).
- Выбрать точку денег: ЛК клиентов/дилеров, статусы заказов, документы.
- Описать API и роли; старый UI может жить.
- Пилот на одной роли или филиале.
- Cutover + откат; потом следующий слой (CRM/1С, отчёты).
Так вы не спорите «rewrite или нет» абстрактно — вы покупаете работающий контур кусками. Оценка объёма за 1–2 недели — нормальный первый шаг: оценка задачи.
Чеклист CEO/CTO: rewrite или дотягивать
- Назван срез, который тормозит выручку (не «весь монолит»).
- Посчитан TCO 12–24 мес.: разработка + обходы + простой + риск срыва.
- Инвентарь интеграций и владельцев данных на одной странице.
- Критерий cutover и план отката записаны до старта кода.
- Пилот на ограниченной аудитории до полного переключения.
- Один ответственный за контур с вашей или подрядной стороны — до сдачи.
- Если «латание на год» ≈ бюджет нового среза — не растягивать боль, выносить слой.
Что делать на этой неделе
Соберите на один час: CTO, владелец продукта, тот кто живёт в 1С/CRM. Запишите три боли в деньгах и один кандидат на первый слой. Если список пустой — вам не rewrite, а приоритизация. Если кандидат ясен — оцените срез, а не «весь легаси».
Нужна внешняя рамка по кабинету и интеграциям — веб-приложения и кабинеты, получить оценку или напишите в Telegram @MozziDev.
Сервисы и материалы по теме
Вопросы руководителя про rewrite и рефакторинг легаси
Когда ядро мешает бизнесу каждый квартал (новые продукты, интеграции, нагрузка), оценка «латания» на 12–18 месяцев близка к бюджету нового контура, а команда уже тратит больше половины времени на обходы. Rewrite без владельца scope и критерия cutover — дороже любой починки.
Не «переписать всё», а вынести узкий срез: кабинет/API, обмен с 1С/CRM, отчётность — с работающим старым контуром рядом. Бизнес получает ценность каждые 4–8 недель, а не через год «большого взрыва».
Сравните за 12–24 месяца: стоимость разработки + простой/двойной ввод + упущенные сделки + риск срыва релиза. Rewrite выигрывает, если латание не снимает корневой тормоз (данные, интеграции, производительность). Иначе дешевле плановый рефакторинг одного контура.
Параллельно живут два контура без чёткого cutover, данные расходятся, сотрудники учат новый UI под пик сезона. Без пилота на одном филиале/ роли и без отката — проект растягивается и съедает бюджет роста.
Зафиксировать «точку денег» (кабинет, заказы, обмен с учётом), оценить срез на 1–2 недели и вынести его в отдельный контур с API. Остальное — по очереди. Полный rewrite «когда-нибудь» без среза — самый дорогой путь.
Хотите применить это на практике?
Расскажите про вашу систему — предложим план работ и метрики, которые имеет смысл зафиксировать в SLA/SLO.
Статьи по теме
Все материалы: Аудит и тестирование
Разработка и внедрение ИИ-агентов для бизнеса: пилот за 2–4 недели, не demo-бот
ИИ-агенты для бизнеса: чем отличаются от чат-бота и RAG-виджета, что входит в пилот 2–4 недели, on-prem, интеграции CRM/1С/API, оркестрация и KPI. Чеклист перед заказом.
Читать статьюСвой веб-кабинет или облачный SaaS: когда on-prem выгоднее
Свой веб-кабинет или облачный SaaS: сравнение on-prem и подписки для бизнеса — данные, TCO на 3 года, риски вендора и чеклист выбора кабинета.
Читать статьюИнтеграция 1С и ERP с веб-приложением: что заложить в ТЗ до подписания
Как связать 1С/ERP с порталом, CRM или системой заявок без двойного ввода: master data, REST/OData, частота обмена, конфликты и ориентиры по бюджету интеграции для CEO и CTO.
Читать статьюIT-проект для руководства: 10 вопросов до подписания контракта
Чеклист для гендиректора, CFO и совета директоров: измеримый результат, владелец со стороны бизнеса, IP, SLA, выход из контракта и красные флаги подрядчика — без жаргона про микросервисы.
Читать статью