Если же контора решает устроить переезд своими силами, то обычно организуется своеобразный taskforce - группа людей из разных команд с разными навыками.
Хорошо, когда новая команда сначала проходит обучение. Тогда каждый, набрав определенные компетенции, может предложить идею, которая будет соответствовать best practices. Хуже - когда команда ничему не учится и лезет напролом, гугля разные порции документации.

Вот вам пример - нам нужно перетащить старый MySQL от хостинга в Амазон с минимальным downtime (речь идет о mission critical системе).
Что сделал один из разработчиков-stakeholder’ов? Нагуглил прикольную доку: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html

Правильный ли это подход? Может быть, не могу подтвердить или опровергнуть сразу. Но поскольку Амазон не меньше вашего заинтересован посадить клиента на свою инфраструктурную иглу, тот он наверняка предусмотрел этот сценарий и предложил решение в виде Database Migration Service, где весь этот процесс сделан автоматически, да и к тому же поддерживается репликационная миграция (читай продолжительная).
Чем поднимать руками ЕС2 и настраивать там MySQL мне гораздо проще развернуть репликационный таск и выключить его, когда приложение будет готово работать с промышленной базой в Амазоне. Весь downtime - один рестарт приложения.

Что в миграционных, что в любых других проектах или задачах стоит применять золотое правило: “Предложи вариант B” - если вы уже нашли способ решить проблему, пусть и самый удобный, найдите еще один. На всякий случай.