The situation
Fera.ai has been running since 2017. By the time they reached out to JetRockets, their platform was on Ruby 2.7.6 and Rails 5.2 — both officially end-of-life. That meant no security patches, no access to modern performance improvements, and an increasing gap between their stack and where Rails was heading.
Their operator knew the upgrade needed to happen. The engineering team had tried multiple times internally. Each attempt stalled.
"We tried multiple times internally to upgrade the stack but each time we got stuck and gave up." — Ryan Kulp, Operator, Fera.ai
The problem wasn't the Rails framework itself. It was the gem ecosystem.
Why internal Rails upgrades fail
Rails upgrades get framed as a Rails problem. The real bottleneck is almost always the gems.
A production Rails app built over several years accumulates dozens of dependencies, each with its own maintenance status, compatibility matrix, and assumptions about how Ruby and Rails should behave. When you attempt a major version upgrade, these dependencies don't all break the same way:
- Some break loudly — clear errors, obvious fixes
- Some break silently — the app runs, but something is subtly wrong
- Some were already abandoned before the upgrade started
- Some have incompatible version checks that require the gem to be replaced entirely
Without a systematic approach to auditing and triaging each dependency, teams hit the same walls Fera.ai hit. One failed attempt is discouraging. Two or three feels like the upgrade is impossible.
We wrote a detailed breakdown of the five gem categories that break most Rails upgrades — worth reading if your team is facing the same situation.
How JetRockets approached it
We started with a full gem audit, cataloguing every dependency, checking maintenance status, and triaging each into one of four categories:
- Dead gems — no recent commits, no active maintainer. Replace with a maintained alternative.
- Deprecated but functional — defer where safe, write compatibility shims where needed.
- Broken by language changes — bump or patch with minimal code changes.
- Broken version checks — fix the constraint, keep the gem.
From there, the team worked through the upgrade systematically on the live production system — without disrupting Fera.ai's product roadmap or requiring their engineering team to context-switch into the migration work.
Detailed daily written updates kept the client informed throughout.
Detailed daily written updates kept the client informed throughout.
The result
Ruby 2.7.6 → Ruby 3.4. Rails 5.2 → Rails 7.2. Four months. Live system. Zero downtime.
That's two major Ruby versions and two major Rails versions upgraded on a production platform serving thousands of active merchants without taking the product offline or slowing down the internal team's work.
Foundational work toward Rails 8 was already underway by the time the engagement wrapped.
"I operate a long running SaaS app (founded 2017) that was stuck on old versions of Ruby and Rails. We tried multiple times internally to upgrade the stack but each time we got stuck and gave up. I then began scouting agencies to assist with this specialized task, and after evaluating several options, JetRockets was the clear winner. They provided a time and cost estimate, then followed through exactly to spec with daily updates and speed beyond what was promised. Best of all, the JetRockets engineers were self-guided and required ~zero oversight to stay on task. I highly recommend their work."— Ryan Kulp, Operator, Fera.ai
Is your Rails app in a similar situation?
If your platform is running on an end-of-life Rails or Ruby version — or if your team has attempted an upgrade and gotten stuck — the problem is almost certainly in your gem ecosystem, not your codebase.
JetRockets offers a free Rails audit that surfaces exactly where you're exposed: gem compatibility issues, security vulnerabilities, performance bottlenecks, and architecture findings. Delivered in 2-3 business days. No commitment required.
Share: