Can you upgrade Rails without taking our application offline?

Yes, zero-downtime upgrades are our standard approach. We use blue-green deployments or rolling updates so the old version handles traffic while the new version starts up. Database migrations are written to be backward-compatible so both versions can run simultaneously during the cutover window.

How do you handle gem compatibility issues during Rails upgrades?

We audit every gem in your Gemfile for version compatibility with the target Rails version before starting. Gems with breaking changes get updated or replaced with maintained alternatives. Abandoned gems get forked and patched if no replacement exists. The dependency resolution happens upfront so there are no surprises mid-upgrade.

What Rails versions do you upgrade from and to?

We handle upgrades from Rails 4.2 through Rails 7+, including multi-version jumps. We upgrade one major version at a time (4 to 5, then 5 to 6, then 6 to 7) because skipping versions introduces compounding compatibility issues. Each version increment is a tested, deployable milestone.

Do you also handle Ruby version upgrades?

Yes. Rails upgrades often require Ruby version bumps, and we handle both together. Ruby version changes affect all gems in your application, not just Rails, so we test the full dependency tree. We also address any Ruby syntax deprecations and performance improvements available in the newer version.

Ruby on Rails Upgrades That Don't Break Your Business

Zero-downtime migrations from legacy Rails versions to modern, secure, high-performance applications. Trusted by startups, enterprises, and everything in between.

Timeline: 4-8 weeks
Team: Rails lead, BE, SRE/DevOps, QA, Sec reviewer
Typical stack: Ruby 3.2/3.3 with YJIT; Rails 7.x (Zeitwerk); Puma 6; PostgreSQL ≥13; strong_migrations; pgbouncer; OpenTelemetry; Datadog/New Relic/Grafana

What you get

Upgrade plan: Ruby X→Y, Rails A→B; gem audit and shim strategy
Dual-boot enabled; green path proven in staging with traffic replay
Zero-downtime migrations via strong_migrations / gh-ost / pt-osc; backout path
CI/CD hardening: matrix builds (old/new), contract tests, flaky-test quarantine
Observability pack: pre/post p95, p99, error budgets, Slow Query log reports
Performance fixes: N+1 elimination; index strategy, partitioning; cache keys
Security hardening: Brakeman, bundler-audit/Snyk, CSP/HSTS, CSRF, session store, key rotation
Cost controls: puma worker math, pgbouncer, env-specific pool sizes, object store offload
Cutover runbook: canary %, health gates, 'abort switch,' rollback <10 min
Post-go-live hypercare (2-4 weeks) with SLO watch

Outcomes

Same-day cutovers with dual-boot and safe migrations (no freeze)
Zero critical CVEs at release; dependency policy enforced in CI
p95 down ≥ 30% on named hot paths; error rate not worse
Deploy frequency ≥ daily with automatic canary and rollback
Infra and DB cost reduced 20-40% with YJIT, caching, pool tuning

Selected work

450K LOC migrated. Zero downtime.

Rails 3 to 7 for a top-10 telehealth provider: 450K LOC, 2.5M patient records, 14 months, and 15,000 daily clinical users never noticed. Test coverage 35% → 85% caught 847 regressions; passed SOC 2 Type II during the migration.

Rails · PostgreSQL · AWS · HIPAA

2.4M transactions/day upgraded. Zero downtime.

Rails 6.1 to 7.1 for a fintech API. p95 1.8s → 680ms, 18 CVEs eliminated, PCI-DSS compliance maintained through the dual-boot migration.

Rails · PCI-DSS · Dual-boot

How we approach it

Dual-Boot

When:: Monolith with active feature work
Tradeoffs:: Longer timeline (6-8 weeks), more CI complexity, but zero feature freeze
Best for:: Teams shipping 20+ PRs/week, high-traffic apps, SaaS platforms

Blue-Green

When:: Clean cutover, strict rollback SLA (<10 min)
Tradeoffs:: Requires 2x infrastructure temporarily, simpler CI setup
Best for:: High-availability systems, financial services, enterprise SaaS

In-Place + Canary

When:: Small teams, lower traffic, faster timeline
Tradeoffs:: Higher risk, requires reliable monitoring and alerting
Best for:: Startups, MVPs, low-complexity apps (<50K LOC)

Where teams use it

Finance & Fintech

SaaS Platform Upgrade (Rails 6.1 → 7.1)

Upgraded fintech API serving 2.4M transactions/day. Zero downtime, p95 from 1.8s → 680ms. PCI-DSS compliance maintained throughout. 18 CVEs eliminated.

Retail & E-Commerce

E-commerce Monolith Upgrade (Rails 5.2 → 7.1)

Black Friday-ready Rails upgrade for 800K SKU catalog. 55% memory reduction enabled downsizing from 24 to 14 dynos. $86k annual savings.

Healthcare & MedTech

HIPAA-Compliant Patient Portal (Rails 4.2 → 7.1)

Multi-version Rails upgrade with audit trail preservation. BAA compliance maintained. Zero data loss during dual-boot migration.

What we need from you

Codebase + Gemfile.lock, production configs, deploy scripts
Current perf/security reports; SLOs; infra costs; DB stats (pg_stat_statements)
Release calendar and downtime constraints
List of critical user journeys and SLAs
Access to CI/CD, observability, error tracking, DB consoles

Proof points

All tests passing in both Rails versions
CVE count → 0 at release; SBOM generated
p95 latency improved ≥30% on defined endpoints
Rollback proven <10 minutes; blue-green cutover report

Built for procurement

Source code and test suite audit with deprecation inventory
Zero-downtime deployment with rollback SLA (<10 min)
All tests passing in both Rails versions before cutover
CVE remediation with SBOM (CycloneDX format)
Performance SLA: ≥30% p95 improvement on defined endpoints
IP ownership: upgraded codebase and gem shims under work-for-hire
Fixed-price with milestone payments (30/40/30)
30 days post-cutover support included

Compatibility

Protocols

Rails 4.x → 7.x
Rails 5.x → 7.x
Rails 6.x → 7.x
Ruby 2.7 → 3.3

Message brokers

Sidekiq
Resque
DelayedJob
ActiveJob

Formats

Heroku
AWS (ECS/EC2)
Render
Fly.io
Bare Metal
Docker/K8s

Systems

PostgreSQL
MySQL/MariaDB
Redis
Memcached
Devise
Pundit
CanCanCan
ActiveAdmin
RSpec
Minitest
Webpacker → Vite
Sprockets → Propshaft