Upgrading a Rails app that’s been running for years can feel like open-heart surgery. You know it needs to be done, but one wrong move could bring down production, break critical features, or cause customer downtime.

At Rails Fever, we’ve seen it all — apps stuck on Rails 4.2, dependencies frozen in time, or CI pipelines that haven’t run in years. Over the years, we’ve built a repeatable system for upgrading safely without guesswork.

This is our Rails Upgrade Express, the same framework we use for every client upgrade.

Step 1: Start With an Audit

Every upgrade starts with discovery. Before touching a single file, we run a Rails Tech Audit — a deep scan of the app, gems, dependencies, and hosting setup.

We look for:

The audit gives us a complete map of risks and dependencies. For example, one client’s app had a background job system still running on delayed_job from 2015. Another had a gem using deprecated ActiveRecord callbacks. Without spotting these early, an upgrade would have failed halfway.

Once we understand the landscape, we build a migration plan that clearly outlines:

This plan becomes our blueprint.

Step 2: Build Confidence With Tests

An upgrade is only as safe as your ability to verify it works. That’s why the next step is improving or rebuilding the test suite.

If an app already has tests, we run them under the current Rails version and note what’s failing. For apps with poor coverage, we add critical path tests — covering sign-ups, logins, payments, and key business flows.

These tests become our safety net. They catch regressions before they ever hit production.

For one SaaS client, we wrote 30 new system tests using RSpec and Capybara before touching the Rails version. That gave us instant feedback on whether the upgrade broke anything.

No matter the app’s age, automated tests are non-negotiable. Without them, you’re flying blind.

Step 3: Upgrade in Controlled Stages

Once the test suite is solid, we perform the upgrade in stages, not all at once.

We upgrade Rails and Ruby versions incrementally to avoid big-bang surprises. Each minor version bump gets its own commit, with the tests run in CI after each step.

Here’s a simplified breakdown of how a multi-version upgrade might look:

  1. Upgrade Ruby to a supported version
  2. Update Rails from 5.2 → 6.0 → 6.1 → 7.0
  3. Replace deprecated gems and APIs
  4. Run database migrations carefully
  5. Rebuild assets (Webpacker → Importmap or jsbundling)
  6. Test everything under the new environment

We call this the “no skipped stops” rule. Even if it’s tempting to jump straight from Rails 5 to Rails 7, we don’t. Each version introduces changes that need to be addressed in order.

This incremental approach reduces risk and makes it easier to identify the exact change that breaks something.

Step 4: Stage Before You Ship

Before rolling out to production, we deploy the upgraded app to a staging environment that mirrors production as closely as possible — same database type, same background job workers, same caching layer.

In staging, we invite the client’s team to test core user flows. We monitor logs, background jobs, and metrics. We also run performance comparisons between old and new versions.

This step helps catch subtle issues like time zone bugs or encoding mismatches that automated tests might miss.

Only when staging runs clean for several days do we prepare for the production rollout.

Step 5: Rollout With a Rollback Plan

A safe upgrade isn’t just about what goes right — it’s about preparing for what could go wrong.

For every deployment, we have a rollback strategy ready. That means:

When the switch happens, we deploy during low-traffic hours and monitor logs and uptime dashboards closely for the first 24 hours.

In one case, a client’s upgrade exposed a subtle bug in their mailer preview. Within minutes, we rolled back, fixed the dependency, and redeployed — zero downtime for users.

That’s what we mean by “safe.”

Step 6: Communicate Every Step

Upgrades can be stressful, especially for non-technical founders. That’s why communication is part of our process.

We send regular progress updates — what’s been done, what’s next, and any blockers. During staging and rollout, we maintain real-time Slack or email communication so the client knows exactly what’s happening.

This transparency builds trust and keeps surprises to a minimum.

The Result: Modern, Stable, and Future-Ready

When the dust settles, the app runs faster, safer, and on a supported version of Rails. Developers can add features confidently again. Founders can stop worrying about security patches.

For example, one client’s app went from Rails 5.0 to 7.1 in three weeks. Their deploy time dropped by 40%, and their CI pipeline ran twice as fast after cleanup.

A safe upgrade isn’t just about the framework. It’s about restoring confidence in your software.

Final Thoughts

Legacy Rails apps aren’t a liability — they’re assets that need care. With a structured process, upgrades don’t have to be painful or risky.

At Rails Fever, our goal is simple: make sure your app keeps running while getting better with every release.

If you’re sitting on an old Rails app that’s starting to show its age, now’s the time to plan your next upgrade. We can help you do it safely.

Need help with Rails maintenance? We offer comprehensive Rails Care Plans for ongoing support, technical audits to assess your current state, and Rails upgrades to keep you current. View our pricing plans to find the right fit for your needs.

Schedule a consultation or email to discuss your Rails needs.