Rails and Ruby upgrades
Move an old Rails application to current Rails and Ruby step by step, without a rewrite and without stopping feature work. We start with a fixed-price roadmap.
Why upgrades stall
Most Rails applications we see are not behind because nobody cared. They are behind because the upgrade never fit into a sprint. Every month the gap grows: gems drop support for the old version, security fixes stop arriving, and new developers do not want to work on Rails 5.
The fix is rarely a rewrite. It is a plan, done in steps small enough to merge on a normal working day.
How we work
- Roadmap. We run your test suite against the target Rails and Ruby versions, read the deprecation warnings and the Gemfile, and list every blocker: gems with no compatible release, monkey patches on Rails internals, code that relies on behaviour that changed. You get a written plan with an order of work and an estimate.
- Dual boot. We set the application up to boot on both the current and the next version, so the work can land in your main branch while you keep shipping.
- Small pull requests. One deprecation or one gem per pull request, reviewed by your team. Nothing is merged that you have not seen.
- Switch over. When the suite is green on the new version, we switch the default and remove the old path. Then the next step starts.
Why us
We live closer to the edge than most teams. Japan Voyage, our own product, runs in production on Ruby master, the development branch of Ruby, rebuilt nightly. When master changes something, we find out the same week, often by breaking our own deploy first.
We also work on Ruby itself. Sampo Kuokkanen has merged changes into ruby/ruby (String fast paths, test fixes), ruby/spec and JRuby, and speaks at Ruby conferences in Japan and Taiwan. Reading the Ruby changelog is part of the job, not research we do for your project.
We wrote up one upgrade in detail: moving a Rails 8.1 application from Ruby 3.4 to 4.0 (in Japanese).
What you get
- A written roadmap with every blocker, before you commit to the full project
- Small pull requests your team can review, not one large branch
- An application that deploys at every step
- Notes on what changed and why, so your team can do the next upgrade without us
Pricing
Prices in US dollars, before tax. A price marked "from" is the minimum; we agree a fixed price before we start, and invoices in yen are fine.
Upgrade roadmap
$1,500
fixed price, about one week
We read the code, run the test suite against the target versions and write down every blocker, with an order of work and an estimate. Yours to keep even if someone else does the upgrade.
Upgrade
from $3,000
fixed quote after the roadmap
For small and medium applications. We carry out the plan in small pull requests your team reviews and merges, and the application stays deployable at every step.
Keep current
from $300
per month
Each new Rails and Ruby release applied within weeks, gems kept up to date, deprecations fixed before they turn into errors.
Frequently Asked Questions
- Our application is on Rails 4 or 5. Is that too old?
- No. We go one version at a time (5.2, 6.0, 6.1, 7.0 and so on), because each step has its own deprecations and a smaller step is easier to review. Old versions mostly mean more steps, not a rewrite.
- Do we have to stop building features during the upgrade?
- No. We work in small pull requests against your main branch and use dual booting, so the application runs on both the old and the new version while the work is in progress.
- We have few tests. Can you still upgrade?
- Yes, but the roadmap will say where the gaps are, and the first part of the project is usually adding tests around the code the upgrade touches. Upgrading without them moves the risk to production.
- Can you upgrade Ruby as well as Rails?
- Yes, and often that is the harder half. We run our own production application on Ruby master, so we see breaking changes in Ruby months before a release.
Tell us about your project
Send a few lines about your application and what you need. We reply within two business days, in English or Japanese, with next steps and a rough estimate.
Other services
Ruby on Rails development
Small, well-defined Rails work at a fixed price: a first version of a new application, one feature, a fix, or monthly maintenance.
Feature or fix: from $1,000
Code audit and second opinion
An outside review of your Rails codebase, or of a proposal you have been given, written up in plain language so you can decide what to do next.
Second opinion: $500
JRuby and Java integration
Run Rails on the JVM, call Java libraries from Ruby, or embed Ruby in a Java system. We contribute to JRuby itself, so we can fix the problem where it starts.
JRuby assessment: from $2,000
Spinel: compile Ruby to native binaries
Spinel is Matz's new ahead-of-time compiler: it turns a subset of Ruby into a standalone native binary. We contribute to it, and we can tell you whether your code fits.
Feasibility study: $2,000