Updating gems is the fulcrum of the upgrade process of a legacy Rails codebase. Other than rails itself, a few gems stand out for their stubbornness in limiting the normal functionality of the application.

Establishing the difficulty of maintaining the gem features it’s an heuristic process that involves looking up the gem on https://rubygems.org/ and following the breadcrumbs of releases, homemapages, documentation and of course, online forums.

We have ranked the top 10 common gems and their dependencies by the complexity the pose to the upgrade process.

5. paperclip

paperclip is dead. What do you do? This one has a two options. One is quite simple. All the development has moved to kt-paperclip, and you need to update your gemfile. Otherwise, the best option is probably to move to ActiveStorage, but it’s a complete reengineering of the functionalities.

4. Simple form

Yes Simple Form often has “Simple” fixes, but in a 100k lines of code codebase, there are many many forms, so even if you engineer a very good regex, it can be impossible to cover all the cases, and you might have to do a bit of work by yourself.

3. Devise

Devise itself does change his ways multiple times, but also warden breaks quite a bit. There are some manual implementations needed, and some old unsafe options are removed. Working around an old authentication system, particularly customized, is always complex.

2. Rails

You guessed it, rails poses quite a challenge. The routes declarations change, Active record queries (like merge) break, it is generally not a good time. Also, can you imaging having to declare all permitted parameters in a project with 80+ models? We didn’t have to imagine that.

1. Capistrano

I can’t even start talking about what kind of implementation worked for Capistrano and what is now completely unusable with Capistrano3. Also the class names are the same, so on a development environment with a dirty gemset, you will have Capistrano act instead of Capistrano3, since they are different gem and Capistrano3 it’s not a direct update… I honestly think that it is better to drop the gemset, remove all implementations and reimplement Capistrano3 deployments from scratch. Some custom features might need a new development, but maybe you are already planning on changing the server OS version, and you might need to change most of the Capistrano feature and connected software anyway, it might be better to start fresh.

In conclusion, not all gems are the same, and upgrading is a slow process that require a lot of trial and error. But with time and patience, (and maybe a couple of forks), almost any application can be upgraded.