Rails 7.0 EOL Is Coming — Here's Your Upgrade Checklist

Rails 7.0 reaches end-of-life on June 1, 2026. After this date, there will be no more security patches for the 7.0 series. If you're still on 7.0, every new CVE becomes a critical risk with no official fix.

Upgrading Rails doesn't have to be painful. Here's a step-by-step checklist to get from 7.0 to 7.1 (or 8.0) with minimal disruption.

Phase 1: Preparation (4-6 weeks before)

• Audit your dependencies. Run bundle outdated and check each gem's compatibility with Rails 7.1. Pay special attention to gems that use C extensions or monkey-patch Rails internals.
• Review deprecation warnings. Run your test suite with Rails.application.config.active_support.deprecation = :raise to catch all deprecations. Fix them before attempting the upgrade.
• Check your Ruby version. Rails 7.1 requires Ruby 3.1+. If you're on an older Ruby, upgrade that first.
• Increase test coverage. If your coverage is below 80%, invest in filling gaps before you start the upgrade. You'll need those tests to catch regressions.

Phase 2: The Upgrade (1-2 weeks)

• Create a dedicated branch. Never upgrade on main. Create a branch and give yourself room to experiment.
• Update the Rails gem. Change gem 'rails', '~> 7.0.0' to '~> 7.1.0' and run bundle update rails.
• Run the upgrade task. Use rails app:update to walk through configuration changes. Review each diff carefully before accepting.
• Run your test suite. Fix failures one by one. Common issues include changes to Active Record query behavior, autoloading with Zeitwerk, and SSL defaults.
• Test critical paths manually. Automated tests don't catch everything. Walk through your core user flows in development.

Phase 3: Validation (1 week)

• Staging deployment. Deploy to staging and run integration tests against a production-like environment.
• Performance benchmarking. Compare response times and memory usage before and after the upgrade.
• Security review. Verify that new security defaults are applied. Rails 7.1 includes stricter CSRF protection and improved SSL configuration.
• Team sign-off. Get confirmation from QA, product, and ops before the production deployment.

Phase 4: Production Deployment

• Deploy during low traffic. Schedule the deployment for a window with minimal user impact.
• Monitor closely. Watch error rates, response times, and background job queues for the first 48 hours.
• Have a rollback plan. Know exactly how to revert the deployment if something goes wrong.

Don't Wait Until It's Too Late

The teams that handle upgrades successfully start planning months in advance. If you don't have the internal bandwidth to manage this upgrade, consider bringing in experienced Rails maintenance engineers who have done it dozens of times before.