A Rails upgrade isn't a side job. It takes a strong engineer, and in most companies the person who can do it is at the center of development. Hand them the upgrade, and feature work stops by exactly that much. In many teams, that's two months. Chihaya takes on those two months.
No skipping. One step at a time,
with tests passing before each next step.
None of these get better on their own. The longer they sit, the fewer options remain and the harder the fix becomes.
Rails ships fixes only for the latest few series. The moment you fall outside them, a discovered vulnerability gets no official fix. Your choices become patching it yourself or ignoring it.
The gem you want requires a newer Rails and won't install. You can't keep up with payment or SDK updates. New development tools and AI assistants assume an environment you don't have.
Nobody can predict where things will break, so nobody dares. The more someone knows, the better they understand the risk. "Don't touch it while it works" becomes the default.
If the upgrade breaks things, you find out when users write in. Upgrading without tests is, in practice, a live experiment on production.
A railway doesn't fail all at once. The rails wear a little, the ballast settles. Then, however much you want to go faster, the track won't allow it. The trains keep running. They just get slower, bit by bit, until that speed becomes normal and the passengers no longer notice.
The same thing happens to a Rails app left on an old version.
Outside the supported series, a discovered vulnerability gets no official fix. You keep running in a state you know is unsafe.
The tooling that accelerates development only ships in newer versions. Stay on the old one and those gains pass you by.
New libraries assume a recent Rails. Your toolbox shrinks, and time goes into reinventing wheels.
Each one is a small delay. But they add up, and what falls is the speed at which business ideas become product. Because it happens gradually, nobody inside sees it. You notice when you compare yourself to a competitor, or when a new hire points it out.
Ruby on Rails is exactly that railway. Kept in good repair, it carries business ideas into working software astonishingly fast. That is what the framework was built to do. The slowness isn't the rails' fault. It's that nobody has had the time to maintain them.
So we maintain the track while the trains keep running.
What hurts about an upgrade isn't the work itself. It's who has to do it.
An upgrade can only be entrusted to a strong engineer.
And in most companies, that person is at the center of development.
Reading the blast radius, isolating what broke, deciding whether to fix or work around it: none of this is possible without following the framework's behavior and the app's structure at the same time. It can't be handed to someone part-time. So when you look inside the company, you land on your best engineer.
The gap they leave becomes a gap in feature development. In many teams, two months. From the business side, that isn't a technical task. It's a decision to stop the business growing for two months.
* Two months varies widely with the version gap, the size of the app, and test coverage. We give a real estimate after the assessment.
Not "just upgrade it." Our scope runs through to leaving you in a state that lasts after the upgrade.
First, find out where you are.
Versions, gem dependencies, test coverage, CI, deployment environment. We identify where the bottlenecks will be and give you a path and an estimate.
Which versions to go through, and how far.
The latest isn't always the right answer. We weigh it against your business plans and decide how far to go this time, in a shape that can be released in stages.
One version at a time, with tests passing.
We put the scaffolding tests in place first, then upgrade one version at a time. Each step is confirmed before the next, so problems stay easy to isolate.
Not upgrade and walk away.
An upgrade isn't a one-time job. Leave it and things slowly slow down again. With ongoing maintenance, the next upgrade never gets as big as this one.
Built around one priority: don't stop the business.
We ask about the size of the app, versions, test coverage, and release frequency. Access to the repository lets us give a much more concrete estimate.
Which versions to go through, and how far to upgrade this time. How to avoid collisions with feature work running in parallel. We settle these before starting.
Every fix the assessment surfaces becomes a ticket, without exception. The total volume of work is visible before we start, and the schedule estimate follows from it. We never set off without seeing the end.
If tests are thin, we first make it possible to notice breakage. Not everything, but the paths the business can't afford to lose come first.
Tickets that can go in on the current version get done first. Each becomes a small PR, folded into your normal releases and shipped to production. Every one is small, so any problem is quick to revert. The diff on upgrade day shrinks accordingly.
We upgrade one version at a time and pass the tests at each step. Configuration stays pinned to the old version's defaults, so the framework's behavior doesn't change. Move the version and the behavior together, and when something breaks you can't tell which caused it.
Now the pinned settings are switched to the new defaults, one at a time. We verify after each change, so if anything happens the cause is obvious immediately. Doing them all at once is not faster.
We stay with you through the production release. It doesn't end there: we hand over the remaining issues and what the next version will bring. Ongoing maintenance is also an option.
Upgrading Rails alone doesn't get you a working app. We take on the surroundings too.
Replacing deprecations, following breaking changes, applying new defaults
Keeping up with the Ruby version Rails requires. Current Rails needs Ruby 3.2 or later
Resolving dependencies, replacing unmaintained gems, updating bundler itself
Adding tests as scaffolding, so breakage gets noticed
Setting up CI to support the upgrade. It becomes the safety net for every upgrade after this one
Keeping AWS and other runtime environments and build settings in step. If it can't ship, it doesn't count
This work needs two things: a long history with Rails, and the ability to talk in business terms. We bring both.
We've lived through what the framework changed and how, in real time. Which versions break what is experience for us, not documentation.
Upgrade problems usually surface outside the framework. Being able to isolate the surrounding issues is what keeps the work from stalling.
Volume work like diff investigation and replacements is done with AI tooling built into the process. We get speed without adding headcount, so you can start small.
"Why now" and "how far this time" don't stay in technical language. Translating them into something the business can decide on is our core job.
It varies widely with the version gap, the size of the app, and whether there are tests, so we don't promise a timeline without an assessment. We start with an assessment and an estimate, and you decide from there.
For the same reason, we don't have a fixed price list. After the assessment we give you a quote together with the scope. Once you decide how far to go, the cost follows, so start by telling us where you are.
We plan on the basis that it won't. Rather than switching everything over at once, we break the work into pieces that can be released separately. If downtime is unavoidable, we explain why and for how long in advance, and you decide.
That's actually where many of our engagements start. In that case we begin by adding tests. Not exhaustive coverage, but the paths the business can't afford to lose, so that breakage gets noticed first.
We don't recommend jumping. When something breaks, you can't tell which change caused it. It looks like the long way round, but going one step at a time with tests passing at each step gets you there faster in the end.
We'll take it from there. Knowing how far you got and where it stalled makes the assessment faster. Where the work done so far can be used, we use it.
We can, but we generally recommend keeping them separate. Mixing an upgrade with feature changes makes it hard to isolate what broke. Finish the upgrade first, then proceed as a separate release. It's safer.
Which version you're on and how long it's been there. Even that much lets us give you an initial read.
It's fine to get in touch while you're still deciding whether to upgrade at all.