Неплохой вариант, но объём изменений очень велик. Послойно не получится катить.

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

Вот и всё.

Если серьезно, то номальная тема - как раз-таки слить последнюю копию инфы с прода на стейджинг или что-там-вместо-него и заняться плотно регрессией. Можно добавить пару тестировщиков, т.к. "нагреть" куа-инженеров легче, чем девелоперов. Если есть месяц, то через недели 2 собраться и посмотреть - можем-ли мы идти в релиз или нет. Если будут четкие факты и результаты договориться с клиентом по поводу +1 или +2 недели можно будет в разы легче. Хорошо бы это как раз-таки заранее и проговорить "давайте начнем готовиться через месяц релизиться, но в середине посмотрим, можем  мы или нет. Весь вопрос в том, что насколько все плохо. Если мы с новой БД и через 3 месяца не стартанем, то тут уже другой подход будет нужен

Лечить эту проблему надо не за 1 месяц с жопой в мыле, а 5 месяцев назад, разработав план миграции.

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

И только после того как готов план миграции - начинать перепиливание базы.

Очень реальный вариант.

Высадить всю команду на полное регрессионное тестирование.

1. Без регресса все равно не получится обеспечить надежность
2. Парни 5 месяцев писали в стол без какого-то value на prod.

Регресс - гуд. Но команда не погружена в бизнес-логику. Ей обладают только аналитики.

это вообще левые люди?

А ситуация, что после ночи в 31-го по 8-е дайтся месяц на миграцию - это просранное управление на всех уровнях как у заказчика, так и у исполнителя. Что тут обдсуждать?

План миграции есть, сама миграция автоматизирована. Основная проблема в основном - в реализованной бизнес-логике и аффекте её на базовый функционал.

привет.
если миграция данных в новую СУБД отработана и поднять master как stage версию тоже можно - остается только все протестировать на регресс. учитывая, что на новых QA нужно время - привлекаем людей заказчика как QA, они уже знают функционал )

Разработчики частично погружены, но врядли они способны выполнять функции тестировщиков. Аналитики инхаус.

Нет. Если план есть и ему следуют, значит проблем нет.

Неплохой вариант. Гуд.

Я бы не стал мучать пользователей старой-новой версией продукта только потому, что мы обновили БД и пару фич добавили. Старый-новый копии нужны когда обновили сильно дизайн и точно будут старообрядцы, которые будут плеваться (как у кинопоиска и реддита). Вещи которые под копотом лучше  на плечи пользователя не склаывать

Дизайн сменён.

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