Crafting user experiences
Building scalable products
Excellent customer service
The True Cost of Staying on Rails 6 A Business Case for Upgrading
If your application is still running Rails 6, you're not just behind on features. You're exposed. Rails 6.0 reached end of life in **mid-2023**. Rails 6.1 reached **end of maintenance in late 2024**. As of January 2026, both versions are **unsupported by the Rails core team and no longer receive official security patches or bug fixes**. And yet, thousands of production applications continue to run on these versions. This isn't a technical problem you can defer indefinitely. It's a business risk that compounds daily. Let's break down what staying on Rails 6 actually costs, and why the ROI on upgrading is clearer than ever. ## The Security Reality Since Rails 6.1 went end of life, the framework has received multiple security patches, none of which apply to your application. Recent CVEs affecting Rails include: **CVE-2025-24293** - A critical vulnerability in Active Storage that, in certain configurations, allows remote code execution through image transformation methods. Security researchers documented exploit paths and attack surfaces. **CVE-2025-55193** - ANSI escape injection in Active Record logging, enabling potential log manipulation attacks. **CVE-2024-27282** - An arbitrary memory address read vulnerability affecting Active Storage sessions. These patches were released for **supported Rails branches at the time** (including 7.1.x, 7.2.x, and 8.0.x). If you're on Rails 6, you received nothing. This isn't theoretical. The exploit code exists. The attack surfaces are documented. Security researchers have published proof-of-concept demonstrations. Every day your application remains unpatched is another day of exposure. ## The Ruby Compounding Problem Rails 6 doesn't just have a Rails problem. It has a Ruby problem. Rails 6.x **allows** older Ruby versions that are themselves unsupported: | Rails Version | Minimum Ruby | Ruby Status | | ------------- | ------------ | ------------------------------ | | Rails 6.0 | Ruby 2.5 | EOL since April 2021 | | Rails 6.1 | Ruby 2.5 | EOL since April 2021 | | Rails 7.2 | Ruby 3.1 | EOL since March 2025 | | Rails 8.0 | Ruby 3.2 | Security-only until March 2026 | | Rails 8.1 | Ruby 3.2 | Security-only until March 2026 | Ruby 4.0 was released in December 2025, introducing performance improvements and ongoing advances in Ruby’s execution and JIT infrastructure. Running Rails 6 on Ruby 2.7 or 3.0? You're operating on a double-EOL stack: an unsupported framework running on an unsupported runtime. This isn't just about patches. It's about the security perimeter of your entire application. ## Hiring Friction Is Real Technical debt has a recruiting cost. Rails developers evaluate potential employers partly on their stack. A Rails 6 codebase signals several things to experienced candidates: **Deferred maintenance.** If upgrades have been postponed for years, what else has been neglected? **Modernisation debt.** They'll be spending months upgrading before shipping features. **Tool limitations.** Modern gems, deployment tools, and developer experience improvements aren't available. Senior Rails developers want to work with current tooling. They want Hotwire, Turbo, Stimulus, Solid Queue, Kamal 2, and the productivity improvements that Rails 7 and 8 deliver. Advertising a Rails 6 role in 2026 narrows your candidate pool significantly, and often attracts engineers looking for any job rather than the best engineers looking for the right opportunity. The cost isn't just in recruitment fees. It's in the quality and motivation of the team you're able to build. ## Ecosystem Drift Rails doesn't exist in isolation. Your application depends on dozens of gems, each with their own maintenance cycles. As the ecosystem moves forward, compatibility with Rails 6 drops. Here's what's happening now: **Gem abandonment.** Many gems no longer test against Rails 6. Some explicitly drop support. **Dependency conflicts.** Security updates in gems may require Rails 7+ features. **CI/CD friction.** Build matrices that once included Rails 6 are being trimmed. **Documentation gaps.** Guides, tutorials, and Stack Overflow answers increasingly assume Rails 7+. This creates a slow erosion. Features that would take a day to implement on Rails 8 take a week on Rails 6, if they're possible at all. Gem authors aren't obligated to maintain backward compatibility forever. The community moves forward, and stragglers are left behind. ## What You're Missing Rails 8.1, released in October 2025, represents the current state of the framework. Here's what it offers that Rails 6 doesn't: **Improved job resiliency** - Rails 8 introduces better primitives and patterns for handling long-running and restart-safe background jobs. **Local CI Ergonomics**** - Rails 8 improves conventions and tooling around test execution and environment consistency. **Native Markdown Rendering** - First-class support for rendering `.md` files as pages, critical for AI-integrated applications. **Solid Queue, Solid Cache, Solid Cable** - Database-backed alternatives to Redis for queues, caching, and WebSockets—reducing infrastructure complexity. **Kamal 2** - Production deployment with a single `kamal setup` command, including the new Kamal Proxy. **Deprecation Warnings for Associations** - Mark associations as deprecated to surface legacy code usage systematically. Rails 8 simplifies deployment, reduces dependencies, and improves developer productivity across the board. Rails 6 offers none of this. ## The ROI of Upgrading Upgrade projects have a clear return on investment: ### Security Posture Eliminate known vulnerabilities. Reduce incident response risk. Satisfy compliance requirements (SOC2, PCI DSS, HIPAA). ### Developer Productivity Modern tooling, better error messages, faster feedback loops. Features that took days take hours. ### Hiring Advantage Attract and retain senior talent. Signal that you take technical excellence seriously. ### Reduced Maintenance Fewer workarounds. Better gem compatibility. Simpler deployments. ### Future Proofing Position for Ruby 4.0 adoption. Stay on supported Rails versions without emergency migrations. The cost of not upgrading isn't static. It compounds. Every quarter you wait, the gap widens, and the eventual migration becomes more expensive. ## The Path Forward Upgrading from Rails 6 to Rails 8 is not a single leap. The recommended path: ``` Rails 6.1 → 7.0 → 7.1 → 7.2 → 8.0 → 8.1 ``` Each step should be: 1. **Tested thoroughly**: Comprehensive test coverage before you start 2. **Incremental**: One minor version at a time 3. **Monitored**: Deployment observability at each stage 4. **Documented**: Capture learnings for future upgrades A typical Rails 6 → Rails 8 migration for a mid-sized application takes 4 - 8 weeks with dedicated effort. Larger applications with significant legacy code may take longer. The key is starting. ## How We Approach Upgrades At Infinity Loop, we've modernised Rails applications from versions as old as 4.2 to the latest stable releases. Our approach: **Audit First**: We assess your codebase, gem dependencies, and test coverage before proposing a plan. **Incremental Migration**: Step by step upgrades with production deployment at each stage. **Zero Downtime**: Your application stays live throughout the process. **Knowledge Transfer**: Your team learns the upgrade patterns for future maintenance. We've completed Rails 5 → 7 migrations in as little as 6 weeks, with 40% faster deploy times as a side benefit. ## Final Thoughts Staying on Rails 6 isn't neutral. It's a decision with real costs: - Security exposure that increases daily - Hiring friction that limits your team - Ecosystem drift that slows every feature - Technical debt that compounds quarter over quarter The upgrade path is well-documented. The tooling exists. The community has done it thousands of times. The only question is when, and whether you'll do it on your timeline or in response to an incident. If your application is running Rails 6, the business case for upgrading has never been clearer. ### Ready to modernise your Rails application? We help teams upgrade, stabilise, and accelerate delivery across Ruby, Python, and Node stacks, without risking production.
