Move an application stuck on Rails 3.2, 4.2 or 5.2 to a supported release, one version at a time, without pausing feature work or the business that depends on it.
Every Rails release gets bug fixes for a year and security fixes for two. After that the Rails team publishes no new versions for it, not even for vulnerabilities, while the vulnerabilities themselves are public knowledge.
I upgrade Rails applications the way I would change a payment gateway in production: in small, reversible steps, with tests around the paths that make money, and with the business running the whole time.
From Rails 3.2, 4.2 or 5.2 to the current release, one minor version at a time, each step deployed and verified before the next.
Ruby upgraded alongside Rails, plus the servers, containers and CI images that an old Ruby kept pinned in the past.
Abandoned gems swapped for maintained ones, and new libraries written where no replacement exists.
Request and system tests around sign-up, checkout, billing and integrations before anything is upgraded.
Once a release series reaches end of life, a newly disclosed vulnerability in Rails stays open in your application. Attackers read the same advisories you do.
PCI DSS requires security patches on every system component, and SOC 2 audits and customer security questionnaires ask about them. An unsupported framework is a finding.
Old Rails pins old Ruby, which is past its own end of life and struggles to build on current operating systems and OpenSSL, so servers stay on unpatched images.
Gem authors drop support for old Rails versions. When a gem you depend on ships a security fix, you may not be able to install it.
Current Rails and Ruby bring YJIT, Hotwire, built-in encryption, Solid Queue and simpler deployment. An old version keeps all of that out of reach.
Each skipped release adds to the jump, and developers who know old Rails get harder to hire. Upgrading regularly is far cheaper than catching up.
Security fixes for each Rails release series ended, or end, on these dates. After them, the Rails team publishes no new versions of that series.
| Version | Released | Security fixes until | Status |
|---|---|---|---|
| Rails 8.1 | 22 Oct 2025 | 10 Oct 2027 | check Supported |
| Rails 8.0 | 7 Nov 2024 | 7 Nov 2026 | check Supported |
| Rails 7.2 | 9 Aug 2024 | 9 Aug 2026 | warning End of life |
| Rails 7.1 | 5 Oct 2023 | 1 Oct 2025 | warning End of life |
| Rails 7.0 | 15 Dec 2021 | 1 Apr 2025 | warning End of life |
| Rails 6.1 | 9 Dec 2020 | 1 Oct 2024 | warning End of life |
| Rails 6.0 | 16 Aug 2019 | 1 Jun 2023 | warning End of life |
| Rails 5.2 | 9 Apr 2018 | 1 Jun 2022 | warning End of life |
| Rails 5.1 | 27 Apr 2017 | 25 Aug 2019 | warning End of life |
| Rails 5.0 | 30 Jun 2016 | 9 Apr 2018 | warning End of life |
| Rails 4.2 | 19 Dec 2014 | 27 Apr 2017 | warning End of life |
| Rails 4.1 | 8 Apr 2014 | 12 Jul 2016* | warning End of life |
| Rails 4.0 | 25 Jun 2013 | 6 Jan 2015* | warning End of life |
| Rails 3.2 | 20 Jan 2012 | 14 Sep 2016* | warning End of life |
* Rails had no fixed end dates before 4.2, so these rows show the date of the series' final release.
Sources: Rails maintenance policy · endoflife.date · RubyGems release history
I review the Rails and Ruby versions, every gem against the target release, the test suite and the infrastructure, then give you a written plan with the order of work and an estimate.
Before anything changes, I add request and system tests around the paths that make money: sign-up, checkout, billing, reports and integrations.
The app runs against both the current and the next Rails version in CI, so upgrade work lands on main in small pull requests instead of a long-lived branch.
4.2 to 5.0, 5.0 to 5.1, and so on: deprecation warnings fixed first, then each release's new framework defaults switched on one by one.
Ruby moves up where Rails requires it, abandoned gems are replaced, and missing libraries are built, so no single dependency blocks the next step.
Each step ships to production on its own, with error tracking and performance monitoring watched closely and a rollback ready.
Upgrades usually stall on dependencies, not on Rails itself: a gem abandoned years ago, pinned to an old Rails, with no newer release. I find the maintained replacement and migrate your code and data to it.
arrow_forward Active Storage or Shrine
Deprecated by its maintainers in 2018.
arrow_forward jsbundling-rails, importmap-rails or Vite Ruby
Retired after Rails 7 changed how JavaScript is bundled.
arrow_forward Active Record Encryption
Encrypted attributes are built into Rails since 7.0.
arrow_forward Strong Parameters
Strong Parameters replaced attr_accessible in Rails 4.
arrow_forward Turbo
Turbolinks is no longer maintained; Turbo succeeded it.
arrow_forward Propshaft
Propshaft is the default asset pipeline from Rails 8.
Sometimes there is no replacement: a payment processor, a partner API or an industry format whose only Ruby client stopped at Rails 4. Then I write the library myself, so the upgrade isn't held hostage by someone else's abandoned code.
Since 2017 my work has been payment infrastructure: first as the sole engineer on GivingFire's gateway, then building and leading engineering at Edge Payments Technologies. Systems that move money leave no room for shortcuts, and I bring that standard to every project.
Lead Software Engineer and Head of Compliance · 2022 – present
Senior Software Engineer · 2017 – 2022
Project Pricing
Scope-based pricing tailored to your project complexity and timeline.
Hourly Rates
Short-term contracts
$50/hr
Advisory, code review, fixes, and short projects.
Long-term, full-time
$30/hr
Ongoing full-time contracts, working as part of your team.
It depends on how far behind the app is, how well it is tested and how many gems it uses. One minor version on a well-tested app can take days; Rails 4 to the current release on a large app is months of work alongside features. The audit gives you an estimate before you commit.
Yes. With dual booting, upgrade changes land on main in small pull requests that work on both Rails versions, so there is no long-lived branch to merge at the end.
Rarely. A rewrite throws away years of fixed edge cases and stops the business from changing while it happens. An upgrade keeps everything that works and delivers value at every step.
Yes. Tests come first: I cover the critical paths before changing anything, and that coverage stays with you after the upgrade.
Tell me which Rails and Ruby versions you run, roughly how big the app is and what depends on it, and I'll get back to you with next steps.
We can't find the internet
Attempting to reconnect
Something went wrong!
Attempting to reconnect