Пора обновлять нашу 12-летнюю легаси-систему: пилить по частям или переписывать с нуля?

Три года назад на схожих объемах в логистике мы решили писать с нуля. Нам тоже пели про 6 месяцев, в итоге вышло 16, а бюджет улетел почти втрое. В первую же неделю после релиза слетел расчет персональных скидок и мы выставили сотням клиентов кривые счета. Пилить с нуля работающую систему такого возраста — безумная рулетка.

План поэтапной миграции должен выглядеть так: 1) Составить полную карту связей в старой БД и вычленить независимые домены, 2) Поставить перед системой роутер для разделения трафика, 3) Первыми мигрировать некритичные сервисы с преобладанием чтения, 4) Ядро — заказы и биллинг — трогать в самую последнюю очередь.

По моему опыту в консалтинге, из 5 корпоративных систем, переписываемых с нуля, 4 срывали дедлайн минимум на полгода. При поэтапной переработке отклонения от бюджета оставались в разумных пределах, и ни один клиент не словил критического простоя заказов. Предложение вашего сеньора опирается на реальность, а не фантазии.

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

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

Агентство, которое заявляет, что полностью перепишет сложную ERP-систему 12-летней давности за 8 месяцев, просто ещё не видело недокументированные персональные скидки клиентам и бухгалтерские правила внутри системы; в день запуска в прод вы своими глазами увидите, как эти 8 месяцев превращаются в 20.

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

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

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

Главное не цифра, а то, на основе чего она получена. Пишите, если есть вопросы, отвечу по мере возможности.

Пишу это, чтобы вы не совершили ту же ошибку. Когда пытаешься изменить всё сразу, ничего не приживается.

Если делаете впервые, начните с малого, масштабирование потом. Если напишете результат здесь, это поможет и другим.

Прочитал этот ответ и выдохнул: значит проблема не только у меня. Если на один вопрос вы получаете три разных ответа, вопрос задан неправильно.

Прежде чем принимать решение, посмотрите, какие данные у вас есть. Пишите, если есть вопросы, отвечу по мере возможности.

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

Пытаться сделать это в одиночку — самый дорогой путь. Интересно, есть ли те, кто делает иначе.

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

Об этом много говорят, но у нас так никогда не было. Доступы должны открываться на компанию, а не на личные аккаунты.

Это мое мнение не утверждаю что оно единственно верное.

Я думаю иначе. Две недели ведения заметок дают лучший результат, чем шестимесячные прогнозы.

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

А как вы решили этот вопрос? Когда пытаешься изменить всё сразу, ничего не приживается.

На этом всё, извините, если затянул.

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

Оставлю как заметку, пригодится.

Сохранил.