Взял на поддержку проект: Rails 5.2, Ruby 2.6, MySQL, деплой Capistrano на VPS у хостера. Заказчик хочет «последнюю версию», потому что Ruby 2.6 уже без поддержки, а хостер грозится обновить систему. Тестами покрыто процентов сорок, в Gemfile 74 гема, у половины версии не зафиксированы. Код писали три разных подрядчика до меня. Сам я последний раз обновлял 5.2 на 6.0 два года назад на другом проекте, и там всё развалилось как раз на гемах. Думаю, как оценивать: прыгать сразу на 7.0 или идти 6.0, 6.1, 7.0 с выкладкой каждой ступеньки? Второе дольше, и заказчику сложнее объяснить, почему он платит за три релиза.
Только ступеньками, и Ruby отдельно от Rails. Я бы шёл так: сначала Ruby 2.6 на 2.7 на том же Rails 5.2 и посмотреть предупреждения про keyword arguments, они как раз в 2.7 начинают сыпаться в лог. Потом 6.0, 6.1, и уже на 6.1 переходить на Ruby 3.0 или 3.1, а после этого 7.0.
На каждой ступеньке одна процедура: поднять версию в Gemfile, bundle update rails, bin/rails app:update, внимательно смёржить конфиги, а new_framework_defaults включать по одной настройке. load_defaults меняешь только тогда, когда все настройки из файла включены и проверены. Тогда если что-то сломалось, ты знаешь, какая строчка виновата. Порядок шагов хорошо расписан тут: https://guides.rubyonrails.org/upgrading_ruby_on_rails.html
Самое долгое обычно не Rails, а гемы. На 5.2 наверняка висит что-нибудь заброшенное для загрузки файлов или пагинации, которое 6.x не поддерживает. С этого и начни, может оказаться, что половина оценки уходит туда.
Заказчику я бы объяснял не «три релиза», а «три маленьких выкладки, после каждой можно остановиться и откатиться». Один большой прыжок при сорока процентах покрытия это неделя поиска, что именно сломалось.
И проверь систему на VPS: Ruby 2.6 и 2.7 с OpenSSL 3 не собираются, нужен старый OpenSSL рядом. Ставь через rbenv, системный не трогай
С гемами как в воду глядели: стоит paperclip, который давно не поддерживается, и пагинация, которую не обновляли с 2018-го. Значит, первая ступенька вообще не Rails, а переезд на Active Storage. Посчитал так: Ruby 2.7 два дня, 6.0 и 6.1 по три, Active Storage неделя, 7.0 вместе с Ruby 3.1 ещё неделя. Отправил заказчику с разбивкой по выкладкам, вроде принял.
Когда будешь переносить paperclip на Active Storage, не двигай файлы в той же выкладке, что и код. Сначала новый код пишет вложения в оба места, потом фоном скриптом через find_each переносишь старые, и только потом отключаешь paperclip. Так переносили тысяч двести картинок, ни одна не потерялась, а откатиться можно было на любом шаге.