The “End of Life” Trap
Running an old version of Rails (pre-6.0) is a liability.
- Security: You are vulnerable to known CVEs.
- Performance: You are missing out on the massive speed improvements in Ruby 3.x and Rails 7.
- Talent: Senior developers do not want to work on Rails 4 apps. They want to use Hotwire, ViewComponents, and modern Ruby.
But upgrading is scary. It feels like “pure cost” with no new features. That’s why you need a partner who can do it efficiently, often using the Dual Boot strategy to keep shipping features while the upgrade happens in the background.
Technical Deep Dive
1. The “Dual Boot” Strategy (The Only Way)
The traditional “create a branch and upgrade” method fails because the branch diverges too far from main over the months it takes to fix dependencies.
The Solution: Use the bootboot gem (created by Shopify) to dual-boot your application.
- Create a
Gemfile.nextalongside yourGemfile. - Use an environment variable (
DEPENDENCIES_NEXT=1) to switch between them. - Run your CI pipeline against BOTH versions on every pull request.
- Fix incompatibilities in small, atomic PRs that merge to
main.
2. Gem Dependency Hell & Autoloading
The hardest part of a Rails upgrade isn’t Rails itself—it’s the ecosystem.
- Zeitwerk: Rails 6 replaced the classic autoloader with Zeitwerk. If your legacy app relies on “magic” require statements or non-standard file structures, it will break.
- Abandoned Gems: Many gems from the Rails 4 era (e.g.,
paperclip) are dead. You must migrate to modern equivalents likeActiveStorageor find maintained forks. - Circular Dependencies: Gem A requires Rails < 5, but Gem B requires Rails > 5. You have to untangle this graph.
3. From Webpacker to Propshaft/Importmaps
Rails 7 moves away from the complexity of Webpack.
- Importmaps: Deliver JavaScript modules directly to the browser (no build step!).
- Propshaft: A modern, simpler asset pipeline replacing Sprockets.
- Turbo: Replace complex React state management with server-rendered HTML updates.
Upgrade Workflow: The Dual Boot Process
graph TD
A[Start: Rails 5.2 App] --> B{Set up Dual Boot}
B -->|Gemfile| C[Rails 5.2 (Current)]
B -->|Gemfile.next| D[Rails 6.0 (Target)]
C --> E[CI Pipeline]
D --> E
E -->|Fail| F[Fix Incompatibility]
F -->|Merge to Main| A
E -->|Pass| G[Switch Default to Rails 6.0]
G --> H[Repeat for Rails 6.1]
How to Choose a Rails Upgrade Partner
If you want to “set it and forget it”: FastRuby.io. They have a machine-like process for upgrades. You hand them the repo, they hand you back a PR for the next version. It’s their entire business model.
If you want to improve your team’s culture: Thoughtbot or Hashrocket. They won’t just upgrade the code; they will pair with your developers, teaching them how to write better tests and avoid future debt.
If you have a massive, high-traffic monolith: Evil Martians. They work with unicorns (like eBay, GitLab) and know how to upgrade without causing downtime for millions of users.
If you are in Australia/APAC: Reinteractive. They are the regional experts and offer excellent fixed-price audit packages to de-risk the project before you commit.
When to Hire Upgrade Services
1. The “Gemfile Lock”
You want to add a new feature (e.g., a modern payment gateway), but the SDK requires a newer version of a gem that conflicts with your ancient Rails version. You are literally blocked from shipping business value.
2. Compliance & Security
Your CTO or Security Officer flags that you are running a Rails version with known RCE (Remote Code Execution) vulnerabilities. You must upgrade to stay compliant.
3. Performance Issues
Your app is slow. You know that Ruby 3.0 + Rails 7 is 3x faster, but you can’t get there. An upgrade is cheaper than rewriting in Go.
Total Cost of Ownership: Upgrade vs. Rewrite
| Strategy | Cost | Risk | Time to Value |
|---|---|---|---|
| Rewrite (in Node/Go) | $500k+ | Extreme (Second System Effect) | 12-18 Months |
| Upgrade (Internal Team) | $150k (Opportunity Cost) | High (Stalled Feature Work) | 6-9 Months |
| Upgrade (Partner) | $75k | Low (Proven Process) | 3-5 Months |
Verdict: Upgrading is almost always 5-10x cheaper than rewriting. Rails 7 is a modern, competitive framework. Do not rewrite just because “Rails is old.” Rewrite only if the domain has changed fundamentally.