Since March 31, 2026, Ruby 3.2 is officially at end of life. The Ruby team has stopped maintaining it: no more fixes, no more security patches, nothing. If your web application is still running on this version, it keeps working, of course, but it is now driving down a road that no one is repaving anymore. This isn't an emergency to handle in a panic, it's a deadline to plan for calmly. Here is why, and how we go about it.
Ruby is the engine under your framework
We often talk about Rails, Sinatra or Hanami, and forget the layer underneath: Ruby, the language itself. It's what actually runs your code, manages memory, and everything else rests on it. Your framework may be up to date, but if it runs on an abandoned version of Ruby, it's like a recent car fitted with an old engine that the manufacturer no longer repairs. Each version of Ruby follows a life cycle of roughly three and a half years. After that it reaches end of life (EOL) and the team stops all support.
In practical terms, the versions still supported today are Ruby 3.3 and Ruby 3.4 (the most recent one). Ruby 3.2 has joined 3.1 and the earlier releases in the category of unmaintained versions. It's this list, kept up to date by the Ruby team, that defines what a "supported version" is, and it's the one that should guide your decisions.
Two concrete risks that grow over time
The first risk is security. As long as a version is maintained, any flaw discovered in the Ruby interpreter leads to a fix published quickly. After EOL, that safety net disappears. If a serious vulnerability is found in Ruby 3.2 in 2026 or 2027, there will be no official patch. Your application stays exposed, with no clean remedy. For a platform that handles customer data, payments or user accounts, that's not a minor detail.
The second risk is more insidious: the ecosystem drifts away. Ruby thrives thanks to thousands of gems, the libraries your application assembles. Their authors gradually stop testing their new releases on unsupported Ruby versions. Little by little, updating a gem to fix a bug or a flaw becomes impossible without breaking the rest. You end up stuck: frozen on old gems because Ruby is too old, and unable to modernize anything. The longer you wait, the wider the gap to bridge, and the more expensive the migration eventually becomes.
The upside: recent Ruby is noticeably faster
Migrating isn't only about staying compliant, it's also about gaining performance. Since Ruby 3.1, the interpreter ships with YJIT, a just-in-time compiler that translates the most heavily used Ruby code into optimized machine instructions. Version after version, YJIT has become more mature and more efficient: on Ruby 3.3 and 3.4, it noticeably speeds up real-world web applications, with gains commonly seen between 15 and 30% depending on the load, for better-controlled memory usage than in the earliest versions.
In plain terms: pages that load faster, servers that handle more traffic without moving up a tier, and sometimes a lighter hosting bill. A simple version update can thus pay part of its own cost, without you touching a single line of your business code.
How we migrate cleanly: step by step, tested at each stage
A successful Ruby migration is never a big leap into the void. It's a step-by-step progression, one version at a time. We go from 3.2 to 3.3, stabilize, then consider 3.4. At each stage, we rely on the application's test suite: that's what confirms, in black and white, that the behavior hasn't changed. If the tests are insufficient, we start by strengthening them on the critical paths, which is the real foundation of a migration without nasty surprises.
The typical process looks like this: we update the Ruby version in an isolated environment, rerun the whole test suite, fix the few warnings or gem incompatibilities that come up, check the application in a staging environment identical to production, then deploy. Nothing goes to production until each step has been validated. It's methodical, predictable, and with no service interruption for your users.
This is exactly the kind of work we take on at a fixed price: taking an aging application, putting its Ruby engine back on a supported version, and setting off again on a healthy footing. If you're wondering which version your platform is running on today, and what it would take to bring it up to date, take a look at our maintenance and upgrade offer, or browse our resources to dig deeper into the subject. An up-to-date engine means a platform that's safer, faster, and something you can build on for years to come.