Ruby on Rails upgrades.
Rails moves fast, and projects that cannot upgrade immediately fall further behind with every release. BigBinary upgrades Rails and Ruby applications across major versions, for clients and for every product in our own Neeto suite, and we write up what we learn.
2011
Building only in Rails since
Rails 7
Every Neeto product upgraded from Rails 6
Ruby 3.3
Every Neeto product, moved with dual boot
Projects that cannot upgrade immediately fall further behind each release, until catching up feels daunting. Gems stop supporting your version, new team members reach for methods your Rails does not have, and the Rails core team only patches security issues on certain versions.
BigBinary upgrades Rails and Ruby applications across major versions. We have done this for client applications and for every product in our own Neeto suite, and we publish what we learn.
The cost of not having the latest Ruby on Rails version is hidden. You pay this cost very slowly, in lost productivity.
- How we upgraded from Rails 6 to Rails 7 (every Neeto product)
- Upgrade Ruby using dual boot (Ruby 3.2.2 to 3.3.0)
- How we migrated from Sidekiq to Solid Queue
- Safely dropping tables and renaming columns in Rails
- Not sure how far behind you are? Start with a code audit.
- Want upgrades to stop being a project? See maintenance.
Every release you skip widens the gap.
- Rails 5.2
- Rails 6.0
- Rails 6.1You are here
- Rails 7.0
- Rails 7.1
- Rails 7.2
- Rails 8.0Latest
- 01
Features you never get
Every new version of Ruby on Rails introduces features and improvements that make development easier. When you’re running an older version, your team misses out on these improvements and often ends up writing extra code to solve problems that newer versions of Rails already handle.
- 02
Hunting for compatible gems
New gems make themselves compatible with the latest Rails. On an older version you spend more time finding one that still works.
- 03
Documentation that doesn’t match
Most tutorials, examples, and discussions online focus on newer versions of Ruby on Rails. When your application runs on an older version, developers have to constantly check whether the documentation applies to their version. What should be a quick lookup turns into additional research.
- 04
Slower onboarding
A new team member reaches for a method introduced in a newer release and has to find another way.
Ruby on Rails has an official maintenance policy that defines how long each version receives bug fixes and security updates.
Under this policy, each minor version of Rails receives bug fixes for one year and security fixes for two years after its initial release.
Once a version reaches its end-of-life, the Rails core team stops releasing security updates for that version. If a new security vulnerability is discovered, applications running on unsupported versions will not receive an official security patch.
Security is something we should all take seriously. Keeping your application on a supported version of Ruby on Rails is important, and ideally, you should aim to stay on the latest version.
Dual boot, tests first, small controlled steps.
Production cannot afford surprises, so the method is built around running both versions until the new one is proven.
- 01
Understand the application
Which Rails and Ruby you are on, which gems hold you back, how much test coverage exists and where the risky code is. If coverage is thin we say so, because an upgrade without tests is a guess.
- 02
Dual boot the next version
Two Gemfile.lock files, one for the current version and one for the next. The app runs and is tested on both while we work, and we check every place the version is defined, from .ruby-version and the Gemfile to the Dockerfile and CI.
- 03
Fix what the upgrade guide does not mention
Deprecations, gems that have not caught up and framework behaviour that changed quietly, fixed in small commits with a note on why each change was needed.
- 04
Ship through staging with a rollback plan
Automated test suites, a staging environment and a rollback plan for every change, with the application deployable at each step.
- 05
Keep it upgraded
Instead of a large, painful upgrade every few years, a predictable schedule of small upgrades through a maintenance engagement.
What the upgrade guide did not mention.
Every Neeto product went from Rails 6 to Rails 7. These are the problems that took the time, each written up with the fix.
attr_encrypted to Active Record Encryption
An encryption gem incompatible with Rails 7, and encrypted columns that had to move to the built-in encryption.
FixedBroken Active Storage links
Links in rich text stopped resolving after a new key generation algorithm.
FixedMailer jobs in the wrong queue
Mailer jobs landed in the default queue instead of mailers.
FixedAutoloading during initialization
Code autoloaded while the app booted started to fail.
FixedA PDF template that stopped rendering
A template that had always rendered needed changes to work again.
FixedOpen redirect protection
The new protection flagged redirects the app relied on.
FixedA renamed Mailgun variable
An environment variable changed name and quietly broke email delivery.
Fixed
Questions about Rails upgrades.
Which Rails and Ruby versions do you upgrade?
We have upgraded applications across multiple major Rails and Ruby versions, for clients and for every product in our own Neeto suite. Two upgrades are written up in detail, Rails 6 to Rails 7 and Ruby 3.2.2 to 3.3.0. If your application is several versions behind, we break the upgrade into reviewable steps rather than one giant leap.
What is dual booting and why do you use it?
Dual booting means keeping two Gemfile.lock files, one for the current version and one for the next, so the application can run and be tested on both. It lets us find breakage before committing to the new version. The full setup, including the BUNDLE_GEMFILE=Gemfile.next commands, is in our dual boot post.
Our test coverage is poor. Can you still upgrade?
Yes, but we will say so up front and usually add tests around the risky areas first. An upgrade without tests is a guess, and production cannot afford surprises. Our code audit can tell you where the gaps are before the upgrade starts.
What kind of problems come up in a major Rails upgrade?
From our own Rails 6 to 7 upgrade, an encryption gem that was incompatible with Rails 7, Active Storage links that broke because of a new key generation algorithm, mailer jobs enqueued in the wrong queue, autoloading failures during initialization, a PDF template that stopped rendering, the new open redirect protection, and a renamed Mailgun environment variable. Each one is documented with the fix.
Do you upgrade Ruby as well as Rails?
Yes. Ruby and Rails versions are usually upgraded together or in sequence. We moved every Neeto product from Ruby 3.2.2 to 3.3.0 and wrote up the method.
Can you keep us upgraded afterwards?
Yes. That is what our maintenance service is for, with regular Rails and Ruby upgrades, dependency updates and security patches on a predictable schedule, instead of a large painful upgrade every few years.
Often paired with this.
Ruby on Rails Maintenance
Running a Rails application requires continuous attention long after the initial launch. We provide ongoing maintenance covering bug fixes, security updates, dependency upgrades, performance improvements, monitoring, and production issues so your team can focus on building the business.
Ruby on Rails Code Audit
Get an experienced second set of eyes on your Ruby on Rails application. We review your architecture, code quality, security, database usage, performance, dependencies, and test coverage, then provide practical recommendations your engineering team can act on.
Ruby on Rails Performance Enhancements
Slow Rails applications can hurt both user experience and developer productivity. We investigate database queries, background jobs, caching, memory usage, application code, and infrastructure to find bottlenecks and make your application faster, more efficient, and easier to scale.