Как безопасно провести выкладку проекта с миграциями?
Для интенсивного изменения структуры большой базы используйте реплики. 
Имеем пару мастер-слейв. При необходимости обновления схемы: отключить слейв провести миграции на нем сделать его мастером и подключить к нему новый слейв  обновить код проекта при необходимости  переключить его на новый мастер отключить бывший мастер
Полагаю универсального решения здесь нет. Все зависит от того, сколько "сервисов" пользуются вашей базой, насколько допустим простой каждого из них и насколько гибок Ваш код.
Можно представить себе, что миграция это изменение представления данных. Таким образом, у нас открывается потенциальная возможность использовать view, и работа из кода не напрямую с данными, а с этими самыми view. Т.о. Вы можете создавать новые временные столбцы, нацеливать на них view, а заполнять их при помощи триггера к примеру. 
В mysql 5.6 (не прошло и 10 лет !, или прошло ?), в случае если Вы просто меняете имя столбца, копирование во временную таблицу, с соответствующим локом, не происходит. 
Т.о. если вы обернете в единую транзакцию (с локом) переименование столбца, и нацеливание view обратно на "изначальное" имя, столбца, вероятно Вам удастся добиться минимального даунтайма.
Миграция, т.о. становится многоходовочкой, но Вы избавляете себя от страха за потерю данных после кривой миграции и упрощаете себе переключение между старыми \ новыми данными, т.к. вы управляете этим из кода миграций.
view имеет множество ограничений в случае "сложных" запросов, джойнов, у Вас должны быть соответсвующие индексы, чтобы view отрабатывало по ним и т д.
Думаю Вам стоит прикинуть всю сложность операционных работ по реализации данного решения, и решения описанного Fortop чуть выше. И понять, чем Вы можете поступится, и что в Вашей системе проще реализуется сейчас, и через 1 год.