Job rails-7-to-8-1-upgrade · revised 11 October 2026
Move one Rails 7.0–7.2 app to Rails 8.1 with its key flows tested
Take one Rails 7.0, 7.1 or 7.2 app to Rails 8.1 one minor version at a time, on the Ruby each step supports. Tests and five named business flows pass on a staging copy before your release.
You might be seeing
- Your Ruby version has reached end of life
- The official Rails maintenance page lists only series your app is not on
- A gem update you need will not install on your current Rails or Ruby
No passwords, keys, card details or admin invites needed to start.
What usually happened
The app runs Rails 7.0, 7.1 or 7.2, which the official maintenance page no longer lists for fixes, and its Ruby may be near or past end of life. Rails documents upgrading one minor version at a time with the test suite as the guide, and each step changes defaults and behaviour that a green run does not fully cover. Taking three steps and a Ruby change in one jump on an app with thin tests risks broken sign-ins, a changed cache format and background jobs that behave differently in tests than in production. Ruby and Rails also constrain each other: a published compatibility table recommends an older Ruby for Rails 7.0 than for 7.1 and later, so Ruby is not simply moved to its newest version first.
Who it’s for: An engineering lead or founder whose Rails 7 app carries the business and whose team has no spare weeks for a framework upgrade.
Usually starts when: The Rails maintenance page lists only the 8.1 and 8.0 series for fixes, the app's Ruby has reached end of life, or a gem or host now needs a newer Rails or Ruby than the app has.
The result: The app runs Rails 8.1 on a Ruby that Rails 8.1 supports. The existing test suite and up to five named business flows pass on a staging copy, each minor step has been taken and tested in turn, and you hold a release plan that your site holder can follow and reverse.
Check whether this job fits
Five short questions. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
Find the exact Rails version
Ask whoever holds the code to run this read-only search in a copy of the project folder.
grep -E "^ rails \(" Gemfile.lockLook for: A version beginning 7.0, 7.1 or 7.2. A version beginning 6 or older needs a separate assessment.
Find the Ruby version
Run this in a copy of the project folder, or read the host's settings page.
ruby --versionLook for: The Ruby version. Rails 8.1 needs 3.2.0 or newer, and Ruby 3.2 is already end of life. Your current Rails minor decides how new a Ruby you can use first, so we set the order at scoping.
What you get
- The changed application code, Gemfile and lockfile as a pull request or patch series, one commit per Ruby or Rails minor step
- The test results for each step, naming the Ruby and Rails versions it ran on, and the list of deprecation warnings, each fixed or accepted by you in writing
- A release plan with the order of changes, a note on the cache format change (and on any cache-backed session store), and the reverse steps
Included
- One Rails app on 7.0, 7.1 or 7.2 with one primary database and a runnable test suite
- The Ruby upgrade that the target needs: Rails 8.0 and 8.1 require Ruby 3.2 or newer, and Ruby 3.2 is already end of life, so the final Ruby is agreed at scoping, normally 3.4 unless a gem blocks it
- Ruby and Rails moved in alternating steps: Ruby is first raised to the newest version your current Rails minor supports (for a Rails 7.0 app that is below the normal final target), then each Rails minor is taken in turn and Ruby is raised again wherever the new minor allows, ending on the agreed final Ruby
- Each minor step in turn, 7.0 to 7.1, 7.1 to 7.2, 7.2 to 8.0 and 8.0 to 8.1 as needed, with the tests run, deprecation warnings read and the Ruby and Rails versions recorded at every step
- The framework-defaults files that the update task creates, enabled one by one and then removed, with the load-defaults setting moved to the target
- A staging smoke check of every route and queued job we can list, and deeper before-and-after checks of five named business flows
Not included
- Rails 6 or older apps: the path is longer and starts with a different inventory
- Replacing Webpacker or another JavaScript build, which is a separate job
- New features, a redesign, a move of database engine or a change of host
- Deploying to production, which stays with your site holder
- Rewriting a gem that has no release for Rails 8.1 and no maintained replacement
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
On the agreed Ruby, installing from the lockfile succeeds with Rails 8.1 and the app's own test suite finishes with the same tests passing as the recorded baseline, or each difference is explained in writing and accepted by you
Evidence: Install log and test output for the baseline and the final state
Every minor step from the starting series to 8.1 has its own recorded test run and list of deprecation warnings, each warning fixed or accepted in writing
Evidence: One result file per step, in the order the steps were taken
In every step's result file the Ruby version meets the minimum Ruby the Rails upgrade guide gives for that Rails series, is no newer than the Ruby the compatibility table named in the plan recommends for it, and the last step runs on the agreed final Ruby
Evidence: The Ruby and Rails versions in each result file, beside the guide's minimum and the table row used
The app boots with eager loading on in a production-like environment, every route we listed returns its documented status on staging, and each of the five named flows completes before and after with no new error
Evidence: Route status table, boot log, and screenshots or redacted records for the five flows
The release plan states whether the cache, or a cache-backed session store, is shared between servers on different releases and gives the two-deploy rollout of the 7.1 cache format if so, and the reverse steps are rehearsed on staging
Evidence: The release plan and the staging rehearsal log
Sign-off. You review the step-by-step results, the five flows and any untested route before your site holder makes the release. A green test run alone does not prove every business rule still holds.
If it fails. If the agreed acceptance checks do not pass, you do not pay and you keep our findings, the step results and the reverse steps.
When it fits, and when we stop
It fits when
- Gemfile.lock shows Rails 7.0, 7.1 or 7.2
- The app's tests can run on a copy with no real payments, email or customer data
- You can name up to five business flows and provide a test account for each
- A person on your side can review the change and an authorised site holder can release it
- Every gem in the lockfile has a release that supports Rails 8.1 or a replacement you accept
We stop and tell you if
- A required gem has no release for Rails 8.1 and nothing maintained can replace it without a rewrite
- There is no test suite and the owner will not accept a written list of flows that were checked by hand instead
- The app can only be exercised with live payment cards or regulated data
- A database change in the path cannot be rehearsed on a copy or cannot be reversed without a separate plan
- The app is still on Rails 6 or older, or the Ruby version cannot be found
What could go wrong
Keep the previous release, its Ruby and its lockfile available. Before release agree a database snapshot, and treat each schema change in the path as reversible only if it was reversed in a rehearsal on staging. If a live check fails after writes resume, the old release is redeployed only after any records written since the release have been reconciled; a snapshot alone would discard them.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| A framework default changes behaviour the tests do not cover | Defaults are enabled one at a time, each with the suite re-run and the affected flow checked, and any default left off is listed with the reason. |
| The new 7.1 cache format is switched on at release while servers still on the old release read the same cache | The Rails guide advises leaving the cache format unchanged on the first deploy and enabling the 7.1 format on a later one; the release plan says whether the app shares a cache, or a cache-backed session store, between releases and sets the two deploys. |
| Ruby is raised to a version the current Rails minor does not support | Each step pairs a Ruby with a Rails minor that meets the Rails guide's minimum Ruby and is no newer than the compatibility table recommends, and the pair is recorded in the step's results. |
| Staging sends real email or changes real records | Use sanitised data, captured mail and payment test mode only. |
A second reviewer checks every change to sign-in, payments, background jobs, caching and the framework-defaults choices, and re-runs one named flow from the handover notes alone.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Restore a copy in an isolated environment on the current Ruby and Rails, record the baseline test result and name the five flows with their expected results
- Raise Ruby to the newest version your current Rails minor supports, moving to that minor's newest patch release first if the app is on an early patch that does not run on the newer Ruby, and re-run the suite after each change
- Take each Rails minor step in turn: change the version, run the update task and review each diff, enable the new framework defaults one at a time, run the suite and read the deprecation warnings; then raise Ruby again if the new minor supports a newer one, until the agreed final Ruby is reached
- Smoke-test every route and queued job we can list on staging with outgoing email captured, and deeply test the five named flows before and after
- Independent review of authentication, payment, cache and background-job changes and of the framework-defaults decisions
- Hand over the changes, the evidence and the release and reverse steps; your site holder releases
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Hosting, platform and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
Discuss a monthly service that keeps the app on supported Ruby and Rails versions and runs the next version in CI.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- The Rails project publishes its own upgrade guide: get the tests passing, move to the newest patch of your minor, fix deprecations, then step to the next minor. If your team has the time and a good test suite, following it yourselves is a sound choice. guides.rubyonrails.org
- Staying on a series that no longer gets fixes is possible but leaves you without upstream security fixes; the maintenance page lists which series are covered. rubyonrails.org
Questions
Why not jump straight from 7.0 to 8.1?
The Rails guide recommends moving one minor version at a time so deprecation warnings point out what to fix. We take each step in turn and record the test result, which also shows where a problem started.
Why not move Ruby straight to 3.4 first?
Because Rails 7.0 is not recommended on the newest Ruby: a published compatibility table recommends Ruby 3.3 for Rails 7.0 and 3.4 from 7.1. So Ruby and Rails are raised in turn, each to the newest version the other supports at that step, and every step records the pair it ran on.
Will you change my hosting or database?
No. This job changes the app's Ruby, Rails and the code that depends on them. A host move or database engine change is a separate job.
My app is on Rails 6. Can you still help?
Yes, but not as this fixed job. Start with the inventory and plan, which covers the longer path and what must change first.
Do you release it for us?
No. Your site holder releases it under your accounts after reviewing our staging evidence and the reverse steps.
Send an enquiry
Send us
- The Rails and Ruby versions, from Gemfile.lock or your host's settings page
- The names of any gems you know are pinned or patched, but not private code
- Whether the JavaScript is built with Webpacker, jsbundling, importmap or the asset pipeline
- The five business flows that matter most and what happens if they break
Later, once you agree
- A controlled copy of the source and Gemfile.lock with secrets removed, through the agreed company-controlled secure handoff
- A sanitised database snapshot or fixtures, and a test account for each named flow
- Instructions to run the test suite and a note of any services it expects
- Your site holder available to review the plan and make the release
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You own the code, accounts, keys and the live system. We prepare the change from an authorised copy, with outgoing email captured and payments in test mode, and a separate reviewer checks it. Your site holder releases it under your accounts. We never ask for passwords or the production secret key in the first enquiry.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “rails-7-to-8-1-upgrade” as the subject.