Rails Upgrade and Maintenance: A Business Owner's Guide

A Rails upgrade moves your application from an old version of Ruby on Rails to a version the Rails team still supports. Support matters because of security patches. As of this writing, each Rails version receives bug fixes for about one year and security patches for about two years after release. When that window closes, newly discovered security holes in your version stay open forever. If your business runs on an aging Rails app, you have three honest options. Upgrade it step by step. Keep it patched and professionally maintained where it stands. Or accept the risk with open eyes.

This guide is for the person who owns that decision, in plain language. I write Rails for a living, and my company operates production Rails applications every day. One of them is a 2019-era Rails 6.1 application with live paying users. We keep that app patched and running in production right now. So the advice below comes from doing the work, and I will tell you when doing nothing is the reasonable call.

Rails Versions and the Support Window, in Plain Words

Ruby on Rails is the framework your application is built on. Think of a framework as the foundation and plumbing of the building. The Rails team releases new versions every year or so, and each version has a limited support life. While a version is supported, the team ships Rails patches. A patch is a small fix released when someone finds a bug or a security hole. Your developers apply the patch, restart the app, and the hole closes. The whole process usually takes hours, not weeks.

As of this writing, the policy is roughly this: bug fixes for about a year after a version ships, and security patches for about two years. The exact dates are published on the official Rails site. The business translation is simple. An app on a version from four or five years ago receives no patches at all. Nobody is watching the door.

This is not unique to Rails versions. Every framework works this way, and Rails is better than most. Rails has been maintained continuously since 2004, and large companies like Shopify and GitHub run on it and fund its upkeep. An unsupported version is not a Rails problem. It is a parked-car problem. The car still runs. The recalls just stopped applying to it.

The Real Risk of Staying on an Old Version

The first risk is unpatched CVEs. A CVE is a publicly cataloged security vulnerability. When a Rails CVE is announced, the fix ships for supported versions only. Attackers read the same announcements you do, and they scan the internet for apps that never got the fix. If your app faces the public internet and holds customer data, this risk compounds every year. A breach of a small company's app is not a headline. It is an insurance claim, a lawyer, and some very hard emails.

The second risk is quieter: the ecosystem moves on. Rails apps depend on gems, which are packaged pieces of shared code. Gem authors eventually drop support for old Rails versions. One day a routine change fails because a gem you rely on no longer installs cleanly with your version. Hosting platforms retire old Ruby versions on the same schedule. The app did not change, but the ground under it did.

The third risk is people. Good Rails developers can choose their projects, and many decline work on a ten-year-old codebase with no tests. The ones who accept charge more, rightly. Every year you wait, the pool of willing hands shrinks and the hourly rate climbs. Owners often discover this at the worst moment, when the one developer who knew the app leaves.

What a Rails Upgrade Engagement Actually Looks Like

A competent upgrade is boring on purpose. The official Rails upgrade guide says to move one version at a time, and every serious firm follows it. Here is the shape of the work, so you can judge any proposal you receive.

First comes an audit. Someone reads the codebase, lists the app's Rails and Ruby versions, counts the gems that will break, and measures test coverage. Test coverage means automated checks that prove the app still behaves correctly after a change. If coverage is thin, writing tests for the workflows that make you money is step one, before any version changes. Skipping this step is how upgrades break invoicing on a Tuesday.

Then come the Rails version upgrades themselves, stepwise. From 5.2 you go to 6.0, then 6.1, then 7.x, then onward. Each jump gets its own testing and its own deploy. Each step is small enough to roll back. The app keeps running in production the whole time. What you should not accept is a big-bang rewrite, where a team rebuilds everything on the newest version and swaps it in months later. Rewrites of working systems fail often enough that we wrote about the alternative in our guide to legacy modernization without a yearlong rewrite.

What Rails Upgrade Consulting Costs

There are specialist firms that do almost nothing but Rails upgrade consulting, and the good ones are worth knowing about. As of this writing, specialist consultancies bill roughly $150 to $250 per hour in the US market. A single major version jump on a mid-sized application commonly lands in the five figures, and a multi-version climb on a large app can pass six. Offshore rates run lower, with the usual tradeoffs in oversight and time zones. Treat any fixed quote given before an audit as a guess.

AI is changing this math. An AI coding agent can do the mechanical share of an upgrade: updating configuration, fixing deprecated calls, adjusting gem versions, and running the test suite after every change. Ours is named Leonardo, he writes Rails code all day, and the people supervising him ship Rails daily. The senior human still owns the judgment calls, and the tests still gate every deploy. The mechanical hours shrink. That is most of the bill. When you compare vendors, ask how they use AI and who stands behind its output. We wrote a longer buyer's guide in how to choose a Ruby on Rails development company.

Rails Maintenance: What a Retainer Covers

An upgrade gets you current. Rails maintenance keeps you there, and for most owners a monthly retainer is the right vehicle. A real maintenance retainer covers four things. Security patches applied within days of release, not quarters. Routine gem and Ruby updates, so no single update is ever scary again. Monitoring and backups that someone actually checks. And a small budget of development hours for fixes and minor features, so the app improves instead of merely surviving. As of this writing, market retainers for this scope generally run from several hundred to a few thousand dollars per month, depending on the app's size and how much change you want each month.

This is work we do on our own fleet. The 2019-era Rails 6.1 application I mentioned above has live paying users who log in and run their business on it. We keep it patched and running in production while newer software gets built around it. The unglamorous truth about maintenance is that when it works, nothing happens. No breach, no outage, no emergency invoice. You are buying the absence of a very bad week.

Maintenance is also the honest on-ramp to bigger goals. Once an app is current and tested, connecting it to the rest of your systems gets cheap. Many of our maintenance clients' first request afterward is wiring the app to their accounting or CRM system, which is its own discipline. We covered it in our guide to API and software integration services.

When Staying on an Old Version Is Actually Fine

Not every old app needs an upgrade this quarter, and a vendor who says otherwise is selling. An internal tool that runs on your office network, holds no customer data, and faces no internet exposure can often stay put for years. The risk of an unpatched CVE drops sharply when attackers cannot reach the app at all. If the app is stable, the team that uses it is happy, and the one dependency that matters still installs, doing nothing is a defensible decision. Write the decision down, revisit it yearly, and keep verified backups.

The calculation flips when any of these become true: the app is reachable from the public internet, it stores customer or payment data, the business depends on it daily, or you can no longer find developers willing to touch it. Two of those describe most of the aging Rails apps we are asked to look at. If yours qualifies, the cheapest time to act is now, because the gap only widens. Start with an assessment, not a contract. Our services team will tell you honestly which of the three options fits, including the do-nothing one.

Frequently Asked Questions

How long does a Rails upgrade take?

One version jump on a small, well-tested app can land in a week or two. A multi-version climb on a large app with no tests takes months, because writing tests comes first. The honest answer arrives after an audit, which takes days. Be wary of any firm that quotes a timeline before reading your code.

How long are Rails versions supported?

As of this writing, each Rails version receives bug fixes for about one year and security patches for about two years after release. The Rails core team publishes the exact end-of-support dates for every version on the official Rails site. After the window closes, newly found security holes in that version are never fixed.

Can we skip versions and jump straight to the newest Rails?

The official Rails upgrade guide recommends moving one minor version at a time, and experienced firms follow it. Each version's deprecation warnings tell you what to fix before the next jump. Skipping versions hides those warnings and turns many small, safe steps into one large, risky one. The stepwise path is usually faster in practice because less time goes to debugging mysteries.

What does Rails maintenance cost per month?

As of this writing, market retainers generally run from several hundred to a few thousand dollars per month. Scope drives the number: patch response time, monitoring, backup checks, and how many development hours are included. A useful retainer names response times in writing. Compare that cost against one emergency incident with an unmaintained app, which routinely exceeds a year of retainer fees.

Is our old Rails app safe if only employees use it?

Often, yes, for a while. An app with no public internet exposure and no customer data carries far less risk on an old version, because attackers cannot reach it. The decision should still be deliberate: write it down, keep verified backups, and revisit it every year. The moment the app faces the internet or holds customer data, patching stops being optional.

Should we upgrade our Rails app or rewrite it from scratch?

Upgrade, in almost every case where the app still does its job. A stepwise upgrade keeps the business running and keeps every change reversible. Rewrites of working systems routinely run over budget and quietly drop features the old app handled. A rewrite makes sense mainly when the underlying data model no longer matches the business at all.