Rails Upgrade Consultant for Production Ruby on Rails Apps
Upgrading a live Rails application is rarely just a version bump. I help SaaS teams plan, de-risk, and execute Ruby on Rails upgrades — including dependency review, framework defaults, Sidekiq and Redis compatibility, deployment planning, and rollback preparation.
Remote Rails upgrade consulting for teams in the US, UK, Europe, Canada, Australia, and Singapore.
This page is for teams running an older Rails app in production
Most of the Rails upgrade work I take on looks similar: a Rails 5, Rails 6, or Rails 7 app that has been running for years, carries old gems and custom patches, has uneven test coverage, and runs real customer traffic. The team knows the upgrade needs to happen — they just can't afford to break production while doing it.
- Running Rails 5, Rails 6, or Rails 7 and falling behind
- Production risk is the real blocker, not the code change
- Old or unmaintained gems in the Gemfile
- Limited or unreliable test coverage on critical paths
- Sidekiq and background jobs in the upgrade path
- Redis, caching, and session/cookie concerns
- Unclear deployment and rollback story
- Original senior Rails developer has left the team
Why teams upgrade Rails
Most teams don't decide to upgrade Rails because they want to chase the newest version. They upgrade because staying still is starting to cost more than moving — in security exposure, in dependency drift, and in the time the product team loses to working around old code.
- The current Rails version is old or no longer receiving security patches
- Security vulnerabilities and dependency updates are getting harder to apply
- Technical debt is slowing the team down on otherwise routine work
- Ruby, Rails, and gem compatibility is becoming risky to leave unmanaged
- Production behavior is harder to predict as the version gap widens
- The team needs to keep shipping product work while the upgrade is planned safely
A good Rails upgrade service exists to modernize legacy Rails applications without interrupting product work — the upgrade runs alongside the roadmap, not instead of it.
Rails upgrade paths I can help with
Most engagements fall into one of these upgrade paths. The shape of the work is similar across versions — what changes is which framework defaults, gems, and runtime behaviors carry the most risk.
Rails 6 → Rails 7
Rails 6 to Rails 7 upgrade
- Zeitwerk, Webpacker → importmaps / jsbundling / cssbundling decisions
new_framework_defaults staged enablement across 7.0 and 7.1- ActiveStorage, ActionMailer, and ActiveRecord behavior changes
- Gem dependency cleanup before crossing the version
Rails 7 → Rails 8
Rails 7 to Rails 8 readiness
- Ruby version compatibility and bump planning
- Rails 8 framework defaults reviewed and staged
- Solid Queue / Solid Cache / Solid Cable considerations against your existing Sidekiq and Redis setup
- Deprecations and behavior changes that hit production code
Rails 5 → Rails 6/7
Rails 5 to Rails 6 or Rails 7 upgrade
- Ruby version path (often 2.5 / 2.6 → 3.x) sequenced before Rails
- Zeitwerk autoloading migration and constant resolution issues
- Long dependency chains: Devise, Sidekiq, Paperclip, Rails-Settings, etc.
- Step-by-step version bumps instead of one large jump
Cross-cutting
Ruby, gems, and framework defaults
- Ruby version compatibility across the upgrade window
- Gemfile audit and dependency cleanup
- Framework defaults and config changes between versions
- Digest, hash, session, cookie, and signed-ID behavior changes
Start with a Rails Upgrade Audit
For most teams, the right first step is not the upgrade itself — it's a focused audit. The Rails Upgrade Audit gives you a clear picture of what the upgrade actually involves on your codebase, where the production risk lives, and what sequence makes sense before any code is changed.
- Current Rails and Ruby version review, with the realistic target versions
- Gemfile and dependency risk review — what is safe, what needs to be replaced, what is abandoned
- Test coverage risk review on the paths that matter most in production
- Deprecated APIs and framework defaults review (
new_framework_defaults and related config)
- Sidekiq and background job compatibility against the target Rails and Ruby versions
- Redis, caching, session, and cookie risk areas (digest and serializer changes between versions)
- Deployment and rollback plan tailored to your release process
- Suggested upgrade sequence — one version at a time, or staged where it's safer
- Estimated complexity, effort range, and concrete next steps
The audit is usually the first engagement. If you decide to move forward, the same plan becomes the basis for the hands-on upgrade work.
Common Rails upgrade problems I see
These are the patterns that come up on most Rails upgrade calls. If any of them sound familiar, an audit is usually the fastest way to get unstuck.
- The upgrade was started months ago and got stuck halfway
bundle update keeps producing dependency conflicts- Tests are missing, slow, or no longer trusted
new_framework_defaults changes aren't well understood- Production behavior is hard to reproduce in development
- Sidekiq, Redis, caching, mailers, or ActiveStorage might break and nobody's sure where
- The senior Rails developer who knew the app has left
- The team is hesitant to deploy because the rollback story is weak
What the engagement looks like
Most projects start with the Rails Upgrade Audit — a short, focused review of the codebase, Gemfile, framework defaults, background jobs, caching, and deployment flow. From there, I either hand back a written plan your team executes, or I stay on and do the upgrade work with you: staged version bumps, framework defaults enabled in order, dependency cleanup, and a deployment and rollback plan that fits how you ship.
What you get
Concrete deliverables, not a slide deck.
- A written Rails upgrade plan specific to your app
- Gem and dependency notes — what to replace, what to keep, what to drop
- Framework defaults and config review with a staged enablement order
- Sidekiq, Redis, caching, and ActiveStorage risk notes
- Deployment and rollback checklist for the upgrade release
- Hands-on upgrade work alongside your team where it's useful
- Clear next steps your team can own after the engagement
This is a good fit if
- You run an existing Ruby on Rails app in production
- You're on Rails 5, Rails 6, or Rails 7 and need to move forward
- Test coverage on critical paths is partial or unreliable
- You use Sidekiq, Redis, caching, or ActiveStorage
- You need senior Rails upgrade help without hiring full-time
- You want a practical Rails upgrade — not a rewrite
Why work with SparkRails?
I work directly on production Rails codebases, not just audit slides. My focus is reducing upgrade risk before touching the main branch — dependencies, framework defaults, background jobs, caching, deployment, rollback, and the parts of the app that are hardest to test locally.
Senior, independent, remote. No team to staff, no hand-offs — the person scoping the upgrade is the person writing the code.
Planning a Rails upgrade?
Send a short note with your current Rails version, target Rails version, Ruby version, the biggest concern on your mind, whether the app has tests, and whether it uses Sidekiq, Redis, caching, or ActiveStorage. I'll reply with the most sensible next step — usually whether a Rails Upgrade Audit makes sense first.
Request a Rails Upgrade Audit