Rails 6 shipped in August 2019. Rails 8 shipped in late 2024. Between them sit four years of changes: Zeitwerk, Trilogy, Propshaft, Solid Cache, Solid Queue, the deprecation of Sprockets, shifts in default configuration, and three Ruby major-minor bumps.

You cannot jump Rails 6 to Rails 8 in one step. The official Rails upgrade guides are unambiguous: move one minor at a time. That is not advice you can skip — the internal deprecation warnings only fire at each version, and skipping a minor means silently carrying forward broken assumptions that will surface as weird runtime errors two releases later.

This guide lays out the full path, version by version, with the specific things to check at each step.

The Path

From Rails 6.0 or 6.1, the route to Rails 8 goes:

6.0 → 6.1 → 7.0 → 7.1 → 7.2 → 8.0

That is five upgrade steps if you are starting on 6.0, four if you are starting on 6.1. Each step should be its own branch, its own PR, and its own deploy to production. Do not batch them.

Ruby version bumps are separate steps and should happen between Rails upgrades, not alongside them.

Before You Start: Baseline Health

Nothing about this guide works if your current Rails 6 app is in bad shape. Before step one:

If any of those are false, fix them first. The Rails 6-to-8 jump has enough surface area on its own; attempting it on a brittle base turns it into a multi-month disaster.

Stage 0: Rails 6.0 to Rails 6.1

Skip this stage if you are already on 6.1.

Rails 6.1 is the easier half of the 6.x line. The key changes:

Ruby requirement: Ruby 2.5+, but you should be on Ruby 3.0 or newer before moving to Rails 7.

The common landmines:

Update Gemfile, run bundle update rails, run tests, fix what breaks, run rails app:update, review the config diff, deploy.

Stage 1: Rails 6.1 to Rails 7.0

This is the largest single jump on the path and the one most likely to eat a week of developer time. Rails 7.0 introduced a major shift in frontend tooling and forced Zeitwerk adoption.

Ruby requirement: Ruby 2.7.0 minimum, but upgrade to Ruby 3.0 or 3.1 before this stage. Rails 7.0 on Ruby 2.7 is possible but awkward — many gems have moved on.

The major surface areas:

The common landmines:

Run rails app:update carefully. Diff the generated changes against your existing configs. Reject the asset pipeline changes if you are not ready to migrate Webpacker or Sprockets yet.

Expect this stage to take 2-5 engineer-days on a mid-sized app.

Stage 2: Rails 7.0 to Rails 7.1

Rails 7.1 is a polish release. Most apps make this jump in a day or two.

Ruby requirement: Ruby 2.7+, but 3.1 or later is strongly recommended.

The major surface areas:

The common landmines:

rails app:update, review config diffs, run tests, deploy. Short stage.

Stage 3: Rails 7.1 to Rails 7.2

Rails 7.2 was specifically designed as the on-ramp to Rails 8. Almost everything that will land in 8 has a migration path in 7.2.

Ruby requirement: Ruby 3.1.0 minimum. If you are still on Ruby 3.0 here, upgrade Ruby first.

The major surface areas:

The common landmines:

This is a short stage on most apps. A day or two.

Critical checkpoint: at the end of Stage 3, you are on Rails 7.2 with Ruby 3.1+. This is the known-good platform to launch Rails 8 from. Do not skip it even if you are tempted to fast-forward.

Stage 4: Ruby Upgrade Before Rails 8

Rails 8 requires Ruby 3.2.0 minimum, and recommends Ruby 3.3 or newer. (See our post on the minimum Ruby version for Rails 8 for the source citations.)

Before attempting the Rails 8 bump, upgrade Ruby:

Skipping this — bumping Ruby and Rails in the same PR — is the single most common way to turn a boring upgrade into a bisecting nightmare.

Stage 5: Rails 7.2 to Rails 8.0

If you have been disciplined through the previous stages, this is usually the shortest stage of the whole project.

Ruby requirement: Ruby 3.2.0 minimum, 3.3 or 3.4 recommended.

The major surface areas:

The common landmines:

For the detailed step-by-step of this specific stage, see our Rails 7.2 to Rails 8 upgrade guide.

Gem Ecosystem: Audit at Every Stage

Major Rails versions break gems. At each stage, expect to:

Bundler’s error messages during bundle update rails are usually informative. Read them carefully rather than reflexively running bundle update --all to “fix” them.

Test Strategy Across the Upgrade

A four-stage Rails upgrade is a test-suite-intensive project. A few patterns that pay off:

Expected Timeline

On a mid-sized Rails 6 app (50-100 models, a few thousand specs, moderate gem complexity):

Total: 2-4 engineer-weeks of focused work, plus staging bake time between each stage. Spread over a couple months with normal feature work, that is a quarter.

Apps with unusual gem stacks, heavy custom middleware, or hand-rolled autoloading can easily double that. Apps with excellent test coverage and clean conventions can finish faster.

When to Bring in Help

Rails 6 to Rails 8 is a real project. Teams that succeed at it usually have one of:

If none of those are true, the upgrade tends to stall out at Stage 1 or Stage 2, the app sits in a half-upgraded state on a branch, and the project quietly dies. We have seen this many times.

Looking at a Rails 6 to Rails 8 upgrade and want a partner who has done it repeatedly? Our Rails Upgrade Express handles the full path on a fixed timeline, including the intermediate Ruby bumps. For apps that need a structural assessment first, the Rails Tech Audit produces a stage-by-stage plan you can execute internally or hand to us. See also our Rails 7.2 to Rails 8 step-by-step guide for the last leg of the journey.

Schedule a consultation or email to plan your Rails 6 to Rails 8 upgrade.