Rails 7.2 stopped receiving security patches on 9 August 2026. Rails 8.0 follows on 7 November 2026, and after that Rails 8.1 is the only series still receiving them. Ruby 3.2 went end of life on 1 April 2026.
If you are assessed against PCI DSS, SOC 2, HIPAA or ISO 27001, that is not a preference about upgrades. It is a control with a number attached, and an assessor who will ask you about it.
The trap most teams find halfway through
Old Rails versions impose a maximum Ruby version, not just a minimum. Rails 6.0 caps at Ruby below 3.0. Rails 5.2 caps at below 2.7. Every supported Rails release requires Ruby 3.2 or later.
So a company on Rails 6.0 or earlier cannot upgrade Ruby without first upgrading Rails, and cannot upgrade Rails without first upgrading Ruby. No single upgrade resolves it, and the gap widens on both axes at once. Teams routinely scope one axis, start work, and discover the other.
See the exact path your versions force, including the days each has gone unpatched and the controls it implicates.
Three ways to answer the finding
Step one: the Remediation Assessment
Two weeks of reading your application rather than talking about it. No hourly billing, no change orders inside the fixed scope, and no surprise at the end.
The cost of an upgrade is dominated by things nobody can see from outside: an abandoned gem with no maintained successor, framework internals that have been monkey patched, a test suite with 8% meaningful coverage, an application that will not boot on a fresh machine. The assessment finds those first. It is underwriting rather than a sales step, and it is why we can hold a fixed price afterwards.
What you get
The deliverable is the compliance-ready upgrade plan, in one document your senior management can approve.
A component inventory with support status. Every language runtime, framework and dependency, with its end-of-life date and current support state. This is the inventory PCI DSS 6.3.2 asks for.
The remediation plan, written for senior-management approval. Written to the requirements of PCI DSS 12.3.4, for your senior management to approve and your assessor to evaluate. This is the deliverable most teams cannot produce themselves, and the one that makes the invoice easy to justify internally.
A framework-mapped risk register. Each finding tied to the specific control it implicates, rather than to a general statement about technical debt.
The upgrade path across both axes. Ruby and Rails sequenced together, with the blocking dependency analysis for each hop. Old Rails versions cap the Ruby version you can run, so the two are locked together and have to be planned jointly. Most teams scope one axis and discover the other mid-project.
A test coverage and safety net gap analysis. Coverage measured rather than reported, the effort required to reach a safe level, and how the test work will be delivered and reviewed.
Error and flaky-test baselines. Thirty days of production error history and a repeated run of your suite, both recorded and acknowledged in writing as the pre-existing state. This protects you as much as us: it is the difference between a genuine upgrade regression and a bug that was always there.
A blocked dependency report. Abandoned gems, forks required, patched framework internals. This is where fixed-price bids go to die, and finding it here is the entire point.
Fixed prices for each phase that follows, valid 90 days.
The controls this speaks to
Which of these apply depends on the frameworks you are assessed against.
| Framework | Control | What it requires |
|---|---|---|
| PCI DSS 4.0.1 | 12.3.4 |
Review at least every 12 months confirming each component still receives vendor security fixes. Where it does not, a remediation plan approved by senior management is required. |
| PCI DSS 4.0.1 | 6.3.3 |
Critical and high-security patches installed within one month of release. An unsupported version cannot receive them. |
| PCI DSS 4.0.1 | 6.3.2 |
Inventory of bespoke and custom software, and the third-party components incorporated into it. |
| SOC 2 | CC7.1 |
Detection of susceptibility to newly discovered vulnerabilities. |
| SOC 2 | CC6.8 |
Controls over unsupported software and patch service levels. |
| HIPAA | 45 CFR 164.308(a)(1)(ii)(A)-(B) |
Risk analysis and risk management. Documented awareness of an unpatched component without action is the exposure. |
| HIPAA | 45 CFR 160.404 |
Penalty tiers scale by culpability. Documented awareness moves you toward willful neglect. |
| ISO 27001:2022 | Annex A 8.8 |
Management of technical vulnerabilities. |
Citations verified 8 September 2026. PCI DSS references are to v4.0.1; v4.0 was retired on 31 December 2024.
If the assessment concludes you should not do this work, or should not do it with us, you pay nothing.
Step two: the upgrade, at a fixed price
Quoted from the assessment findings, phase by phase, before any of it starts.
- No feature freeze. Your application is tested against its current
dependencies and the target ones at the same time, in your own CI, for as long
as the upgrade runs. Your team keeps shipping while it happens. The second
Gemfile.lockis deleted when the last hop lands and CI goes back to a single run. Most teams assume an upgrade means stopping, and that assumption is usually what deferred it. - Single-version hops. Each one ships to production and soaks before the next begins, so a problem traces to one change rather than to a six-month merge. It also means the work can pause between hops without leaving the application half-migrated.
- Test coverage raised first, and delivered as one test-only pull request with no production code in it, so your engineers can review it as a unit instead of one distraction at a time.
We do not publish upgrade prices. The honest number depends on what the
assessment turns up, and a published range would only invite everyone to expect
the bottom of it. Anyone quoting an upgrade without reading your
Gemfile.lock is guessing.
The terms that apply to every engagement, from the review clause to the liability cap, are on how an engagement works.
Where this extends
Rails is where we start, because the clock is loudest there: every series below Rails 8.0 has already stopped receiving security patches, and 8.0 itself stops on 7 November 2026. The model is not Rails-specific. It fits any source-code upgrade, migration or maintenance backlog where the finding says unsupported software and the fix is engineering rather than a policy memo.
We remediate software so that an auditor stops flagging it. We do not render compliance opinions, issue certifications, or sign anything an assessor relies on. Your assessor decides whether a control is met. Our job is to remove the condition that created the finding, and to hand you the documentation that proves when it was removed.
Who this is for
Mid-market companies in a regulated scope, weighted toward SaaS, healthcare, insurance and payments, running business-critical Rails applications on unsupported versions, with something forcing the timeline: an audit date, an enterprise deal blocked on a security review, a penetration test finding, or a specific unpatched CVE.
Send us your Gemfile.lock. One file, with no application source code in
it. It carries your exact Rails version, your Ruby version and every dependency
with its version, which means the first real conversation is about your actual
stack instead of a generic pitch. It is shareable under a one-page NDA if you
need one.