February 23, 2026
11 min read
When a client comes to us with a Rails 4.2 app that's been running in production for years, the question is never "should we upgrade?" — it's "how do we upgrade without torching the business?"
It's a scenario we know well. A mid-sized SaaS platform, serving paying customers for years, processing thousands of requests per hour, with a codebase that has passed through multiple teams. Nobody wants to be the one to flip a switch and watch it all come down.
Here's how we approach taking an app from Rails 4.2 to Rails 7.1 — one version at a time — without a single minute of unplanned downtime.
The Rails upgrade guides are excellent. If you're running a greenfield app with a handful of gems, you can probably follow them step-by-step over a weekend. That's not what we're talking about here.
An aging production app has archaeology in it. You'll find gems that haven't been maintained in years. Monkey patches that exist because someone needed a hotfix at 2 AM on a Friday. Database queries that rely on implicit behavior that changed three major versions ago. A test suite that technically passes but covers maybe 40% of the actual business logic.
Then there's the Ruby version itself. Rails 4.2 runs on Ruby 2.2 through 2.4. Rails 7.1 requires Ruby 3.0 at minimum. That's not just a framework upgrade — it's a language upgrade, with its own set of breaking changes around keyword arguments, frozen string literals, and removed standard library gems. The Ruby upgrade often needs to happen in lockstep with the Rails upgrade, which adds another axis of complexity to every step.
The real challenge isn't the upgrade itself — it's doing it while real customers are using the product, real money is flowing through it, and the business can't afford a "maintenance window" that stretches from hours into days.
We don't do big-bang upgrades. Ever.
The path from Rails 4.2 to 7.1 goes through every major version in between: 5.0, 5.1, 5.2, 6.0, 6.1, 7.0, 7.1. But we don't just bump the Rails version and hope for the best. Each cycle follows a disciplined sequence that keeps production stable at every step:
1. Make sure all tests pass. This is the baseline. If tests are failing before you touch anything, you're building on quicksand. Fix them first, even if it means delaying the actual upgrade work by a few days.
2. Remove all deprecation warnings. Rails is generous with its deprecation notices — they tell you exactly what's going to break in the next version. Running your test suite and grep-ing your logs for deprecation warnings gives you a checklist of things to fix before you bump any version numbers. This is unglamorous work, but it's what separates a smooth upgrade from a weekend spent firefighting.
3. Upgrade current gems to the latest versions compatible with your current Ruby and Rails version. This is a crucial step that a lot of teams skip. If you try to upgrade Rails and 15 gems simultaneously, you won't know which change broke what. By upgrading gems first — while still on the current Rails version — you isolate gem-related breakage from framework-related breakage.
4. Deploy and monitor stability. Not to staging. To production. Let it run. Watch error rates, response times, background job queues. Give it a few days. If something's off, you catch it now when the diff is small and the cause is obvious.
5. Upgrade Ruby to the latest version possible — or at minimum, to the lowest version required by the next Rails release. Ruby version requirements are often the gate that controls when you can move to the next Rails version, so this step has to come before the Rails bump.
6. Deploy and monitor stability. Same discipline. Ruby upgrades can surface subtle issues: keyword argument changes, frozen string behavior, removed standard library gems. Let production validate it before you add more variables.
7. Upgrade Rails to the next version. Not the target version — the next version. One step at a time.
8. Deploy and monitor stability. By now, the pattern should be clear. Every change gets production validation before the next change goes in.
9. Go back to step 2. The new Rails version will have its own deprecation warnings pointing toward the next version. Remove them. Upgrade gems again. And start the whole cycle over.
10. Repeat until you're on the target Ruby and Rails versions.
This sounds slow. It's actually the fastest approach that doesn't end in disaster. Each cycle is small enough to reason about. When something breaks — and something always breaks — you know exactly which change caused it because you only changed one thing at a time. Compare that to jumping three major versions at once, where you're debugging a tangle of incompatibilities that could be coming from anywhere.
There's a project management benefit too. Each cycle is a deliverable with a clear definition of done: deprecations cleared, gems updated, version bumped, production stable. You can show progress to stakeholders week over week instead of disappearing into a tunnel for three months and emerging with a branch that may or may not work. For engineering leaders reporting upward, this visibility matters.
Here's something that surprises a lot of engineering leaders: the Rails framework upgrade itself is maybe 30% of the work. The other 70% is gems.
A mature Rails app might have 80-120 gems in its Gemfile. On a typical upgrade like this, it's not unusual for 20-25 of those gems to have no compatible version for the target Rails release. Of those:
We build a spreadsheet for every upgrade. Every gem gets a row: current version, target version, compatibility notes, level of effort, risk assessment. This becomes the actual project plan.
The gems that cause the most pain, consistently:
Authentication and authorization. If you're on an older version of Devise, the upgrade path touches sessions, encryption, and password hashing — all things you really don't want to get wrong in production.
Asset pipeline dependencies. The journey from Sprockets to Webpacker to jsbundling-rails/cssbundling-rails is its own saga. We've seen apps where the asset pipeline migration took longer than the Rails upgrade itself. The key decision here is whether to modernize the JavaScript tooling at the same time or to keep Sprockets running through the upgrade and tackle the frontend build separately. Trying to do both at once is a common source of scope creep — our advice is to get the Rails version current first, then modernize the asset pipeline as a follow-up project with its own timeline and budget.
Database adapters and query interfaces. Anything that relies on Arel internals or ActiveRecord's private API is going to break. Usually loudly. Sometimes silently, which is worse.
Let's be honest about something: most long-running Rails apps don't have great test coverage. The original developers wrote thorough tests. Then the team turned over. Then someone added a critical feature under deadline pressure with no tests. Then someone else refactored a module and half the existing tests started failing, so they got marked as skip and never came back.
We don't try to achieve 100% coverage before starting the upgrade. That would double the timeline and the budget. Instead, we focus on critical path coverage: authentication and authorization flows, payment processing, core CRUD operations the business depends on, data migration logic, and background job processing — especially anything touching money or notifications.
If these paths have solid integration tests, we can upgrade with confidence. Everything else gets tested manually against staging during the upgrade process, and we backfill test coverage as we encounter issues.
One thing worth noting: the upgrade process itself is one of the best opportunities you'll ever have to improve your test suite. Every bug you find during the upgrade is a bug you write a regression test for. By the end of a multi-version upgrade, the app's test coverage is almost always significantly better than when we started — not because we set out to improve it, but because the upgrade forced us to understand and verify behavior that was previously just assumed to work.
By the time we're deploying a version bump, most of the risk has already been eliminated. The incremental version-by-version approach caught compatibility issues early. The gem audit resolved dependency conflicts. The test suite covers the critical paths.
Still, we don't just deploy and pray. For each version bump:
Before the deploy:
During the deploy:
After the deploy:
The edge cases deserve emphasis. We've seen upgrades where everything looked perfect for three days — until the monthly invoice generation job ran and hit a changed ActiveRecord serialization behavior. Jobs and processes that run on longer cycles are where silent failures hide. We keep a checklist of every scheduled and periodic process in the app and manually verify each one fires correctly in the days following the deploy.
The technical work is predictable. What's harder is helping engineering leaders justify the investment to the rest of the business.
A Rails 4.2 application still running in production has real, measurable costs that compound over time. Security patches stop. Ruby version support ends. Hiring becomes harder — the excellent engineers you want to hire don't want to work on a Rails 4 app, and you shouldn't want them to. Every new feature takes longer to build because you're working around framework limitations that were solved three versions ago.
We've found that framing the upgrade in terms of compounding risk resonates better than talking about "technical debt." Technical debt is abstract. "We can't patch the next critical CVE because our framework version is end-of-life" is not.
It also helps to quantify the drag on velocity. Teams on severely outdated Rails versions are typically losing 15-25% of their productive capacity to friction that wouldn't exist on a current version. Over a year, that adds up to far more than the cost of the upgrade itself.
If you're sitting on a Rails app that's multiple major versions behind, here's the honest truth: the upgrade is going to take longer and cost more than your initial estimate. Budget 20-30% contingency on top of whatever number you come up with, and you'll be in the right neighborhood.
Don't let that stop you from starting. The longer you wait, the harder it gets. Every month you delay is another month of gem versions drifting, Ruby versions going EOL, and the gap widening.
And most importantly: this is a solved problem. It's not easy, but it's well-understood. The apps that failed at this usually tried to do it all at once, or treated it as a side project squeezed in between feature work.
Treat it like the infrastructure investment it is, resource it properly, and you'll come out the other side with an application that's faster, more secure, and easier to hire for.
One final thought: be realistic about whether your team should take this on alone. A Rails upgrade of this magnitude is specialized work. Your developers know the business logic, the edge cases, the reasons behind the weird decisions in the codebase — but they may not have upgraded across four major Rails versions before. The most successful upgrades pair an external team that knows the Rails upgrade path with an internal team that knows the application. Neither group has the full picture alone.
At Typefast, we specialize in Rails upgrades and modernization for production applications. If you're staring down a major version gap and need a team that's done this before, let's talk.
We begin every project with a $2,000 flat-fee assessment to evaluate your codebase and deliver a fixed proposal. If you proceed, the assessment fee is deducted from the project cost.
Request an Assessment →