У каждого конкретного сайта могут быть какие-то свои особенности, про которые никто ни в одном руководстве не напишет, и здесь заранее никто не угадает. Поэтому
гарантированной 100%-победной последовательности действий
не существует. Поэтому админа с головой пока не могут заменить скрипты. Вам нужно переносить так, чтобы вы могли
протестировать сайт на новом месте до того, как отрубите на старом. В этом плане совершенно верно вы ставите работу с DNS последним пунктом. Но между 4 и 5 должно быть тестирование.
Если у вас домен zxcvbnm.tld, то можете сперва назначить новому серверу test.zxcvbnm.tld, добавить это имя в конфиг nginx и тестировать, заходя по этому имени. Если что-то не работает, то обнаруживаете те самые нюансы, про которые не пишут в руководствах, но которые есть именно у вас. Будем считать, что тестирование прошло удачно.
5.1. добавляете в DNS новый адрес для zxcvbnm.tld. Старый пока не убираете. Т.е. zxcvbnm.tld будет резолвиться в два адреса.
5.2. Идёте пить чай,
пока записи в DNS не обновятся.
5.3. Смотрите логи на новом сервере, убеждаетесь, что пара юзеров (или пара тысяч...) уже попали на новый сервер, и явных ошибок не заметно (если посыпались ошибки, то откатываете изменения DNS и разбираетесь с ошибками).
5.4. Всё нормально - убираете из DNS адрес старого сервера.
5.5. Если срочности нет, то лучше оставить в этом состоянии хотя бы на несколько часов а то и до следующего дня. Обязательно найдутся юзеры, у которых DNS крепко закэшировался, и обновится позже положенного срока.
5.5. Смотрите логи на старом сервере, убеждаетесь, что поток юзеров прекратился, выключаете там сайт.
P.S. Это всё годится в случае, если БД не содержит чего-то, что всегда должно быть в актуальном состоянии (я про всякие интернет-магазины, соц.сети и т.п.), там перенос БД был бы самым замороченным пунктом.
стоит ли перед этим закрывать сайт на техническое обслуживание?
Суть в том, чтобы пользователи даже не заметили перенос. Тогда и закрывать не нужно. Возможно, такие закрытия на тех.обслуживание во многом связаны как раз со сложным переносом БД, когда компании не хватает технических средств, чтобы сделать такой перенос БД незаметным.
Простой