Most upgrade work is sold as a rate and a rough estimate, which puts the risk of the unknown on you. That is why it overruns. The cost of a Rails 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.
We sell it as two fixed prices, and the first one exists to make the second one honest. The assessment finds those things first. It is underwriting rather than a sales step, and it is why we can hold a fixed price afterwards.
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 agreement is with Reid Morrison Inc., a Florida corporation.
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. Structured to satisfy PCI DSS 12.3.4 by name. 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 31 August 2026. PCI DSS references are to v4.0.1; v4.0 was retired on 31 December 2024.
The guarantee
If the assessment concludes you should not do this work, or should not do it with us, you pay nothing. We would rather tell you that in week two than discover it in month four, and it means there is no incentive to manufacture scope.
Step two: the upgrade, at a fixed price
Quoted from the assessment findings, phase by phase, before any of it starts.
- 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.
- 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.
- A review clause that stops the delivery clock when your reviewer is unavailable, rather than quietly consuming the schedule.
- Liability capped at fees paid, and the AI-tooling disclosure written into the statement of work rather than left for you to discover.
Where the work happens is your choice: our own managed machine, your Anthropic tenancy, or a virtual desktop you supply, on which your source code is never downloaded at all. Whichever applies is named in the statement of work rather than promised in a meeting, and each costs something. How we work with your code.
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.
Where this extends
Rails is where we start, because the end-of-life 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.
If that describes something you are carrying, the first conversation is the same one.
What we do not do
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.
We also do not staff a team onto your project. One named engineer does the work, from the assessment through to the last phase, which is the trade this practice makes deliberately.
How it starts
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.
From there: a video call to confirm scope and the forcing event, a short agreement, and two weeks.