Fera.ai
Fera.ai is a long-running SaaS platform serving thousands of active merchants since 2017. Its stack was stuck on end-of-life Ruby 2.7 and Rails 5.2 after several internal upgrade attempts stalled. JetRockets upgraded the live production platform to Ruby 3.4 and Rails 7.2 in four months — two major Ruby and two major Rails versions — with zero downtime and no disruption to the product roadmap.
in 4 months
A SaaS platform that outlived its stack
Fera.ai has been running since 2017 and serves thousands of active merchants. By the time they reached out to JetRockets, the platform was on Ruby 2.7.6 and Rails 5.2. Both versions were officially end-of-life: no security patches, no modern performance improvements, and a growing gap between their stack and where Rails was heading.
Challenge
Fera.ai's team knew the upgrade had to happen. They had tried it internally several times, and every attempt stalled.
The blocker wasn't Rails itself. It was the gem ecosystem. A production app built over several years collects dozens of dependencies, each with its own maintenance status and its own assumptions about Ruby and Rails. In a major version upgrade, they 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 replacing the gem entirely
Without a systematic way to audit and triage each dependency, every attempt hits the same walls. After two or three, the upgrade starts to feel impossible.
Solution
We started with a full gem audit: every dependency catalogued, its maintenance status checked, and each one triaged into one of four categories:
- Dead gems. No recent commits, no active maintainer. Replaced with a maintained alternative
- Deprecated but functional. Deferred where it was safe, with compatibility shims where it wasn't
- Broken by language changes. Bumped or patched with minimal code changes
- Broken version checks. Fixed the constraint and kept the gem
With that map in hand, the team worked through the upgrade step by step on the live production system. Fera.ai's product roadmap kept moving, and their engineers never had to context-switch into migration work. Detailed daily written updates kept the client informed the whole way.
For a closer look at the gems that break most upgrades, see 5 gems that broke our Rails 5 to 6 upgrade, and how we fixed them.
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.
Groundwork for 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."
Stuck on an old Rails version?
If your app runs on an end-of-life Rails or Ruby version, or your team has tried an upgrade and gotten stuck, the problem is almost certainly in the gem ecosystem, not your codebase.
Our free code audit shows exactly where you're exposed: gem compatibility, security vulnerabilities, performance bottlenecks, and architecture findings, delivered in 2–3 business days. Learn more about our Ruby on Rails upgrade services.
Have a similar
project in mind?
Tell us about it. We'll tell you how we can help — honestly.