Still on Rails 5 or 6? Start with a two-week upgrade audit

A lot of product companies are still running the Rails application that makes their money on Rails 4, 5, or 6, often on a Ruby that is out of support as well. The app works. Customers are paying. The upgrade keeps losing to the next feature.

That is a security problem and a hiring problem. Rails 5.2 stopped receiving security fixes in June 2022. Rails 6.0 followed in June 2023. Rails 6.1 followed in October 2024. Rails 7.0 followed in April 2025. When Ruby is also past end of life, nobody is patching either layer. Senior Rails developers see the version in the job ad and walk away, or they charge extra to work in it.

The way in is not a rewrite. It is a short, fixed piece of work that tells the founder exactly what the upgrade costs.

What a two-week audit produces

Rubycode does this as a fixed two-week audit, then a separate upgrade, then ongoing maintenance if you want us to stay.

In the two weeks we read the application. We do not start the upgrade yet. You get a written plan:

• The Ruby version, the Rails version, the database, the job runner, and how assets are built.
• Every gem, marked as maintained, abandoned, or blocking the next Rails version.
• The state of the test suite: green, red, or missing. An upgrade without a safety net is a guess.
• The ladder, one minor version at a time. Rails tells you what is about to break only if you do not skip versions.
• The decisions that need a yes from you before anyone edits code: autoloading, cookie format, and the front-end pipeline are the usual ones. Each of those is a project of its own, not a line in the Gemfile.
• A price and a duration for the upgrade, and a clear list of what is out of scope.

At the end of the two weeks you can stop. You own the plan. Most teams continue, because the scary part was not knowing.

The upgrade, then the maintenance

The upgrade follows the plan. Ruby moves separately from Rails. Each minor version is deployed on its own, with the test suite green, while production stays up. The target is a Rails release that still receives security fixes, not a new product.

Once it is there, the useful contract is a retainer. The same person who did the upgrade keeps the gems current, watches deprecations, and ships small product work. That is how a two-week audit turns into a long relationship, and how the app does not fall five versions behind again.

If your application is still on Rails 4, 5, or 6, the two-week audit is the first step. Book a call at https://calendly.com/ivan-blazevic-rubycode/30min and we will tell you whether it is a fit before anyone invoices a rewrite.